| draft-abak-agent-control-delivery-evidence-01.txt | ||||||||||||||
| Evidence Requirements for Agent Control Delivery and Outcome Reconciliation | ||||||||||||||
|
Agent systems can issue stop, suspend, revoke, constrain, cancel, or override instructions across system and administrative boundaries. A record that such a control was decided or dispatched does not establish that every intended enforcement point received or applied it. Conversely, the absence of an acknowledgement does not, by itself, establish non-delivery. This document defines format-independent evidence requirements for preserving those distinctions. It separates issuer-side emission, required-target resolution, receiver-side observation, enforcement outcome, and observation of the resulting control effect. For a control that must reach more than one enforcement target, the unit of delivery reconciliation is an instruction-target obligation rather than the parent instruction alone. The document also defines bounded negative observations, total reconciliation, population conservation, semantic-preservation requirements for intermediary paths, and a separate qualification for the evidentiary strength of aggregate claims. This document does not define a receipt format, wire protocol, authorization system, policy language, transparency service, or audit regime. | |||||||||||||
| draft-abbott-mcp-ax-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-abinabraham-vrrp-unicast-03.txt | ||||||||||||||
| Unicast Support for the Virtual Router Redundancy Protocol (VRRP) | ||||||||||||||
|
The Virtual Router Redundancy Protocol (VRRP) Version 3 as specified in RFC 9568 assumes multicast operation on a shared LAN. Some deployments require the VRRP first-hop redundancy function but cannot use multicast delivery for VRRP advertisements. This document updates RFC 9568 by defining an optional configured unicast mode for VRRP Version 3 in which advertisements are sent to configured peer addresses rather than to the VRRP multicast group. The VRRP packet format, state machine, protocol number, virtual IP semantics, and Virtual Router MAC behavior remain unchanged from RFC 9568. | |||||||||||||
| draft-abraitis-idr-maximum-paths-subcode-02.txt | ||||||||||||||
| Maximum Number of Paths Reached Notification for BGP | ||||||||||||||
|
This document defines a new BGP Cease NOTIFICATION message subcode, "Maximum Number of Paths Reached", used when a BGP speaker terminates a peering because the number of paths received from a neighbor, as permitted by BGP ADD-PATH, exceeds a locally configured upper bound. That bound may be applied on a per-prefix basis or as an aggregate limit across an address family. | |||||||||||||
| draft-accilent-at-sign-00.txt | ||||||||||||||
| Clarification of Proper Use of "@" (at sign) in URI-style Components | ||||||||||||||
|
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. | |||||||||||||
| draft-acee-idr-lldp-peer-discovery-22.txt | ||||||||||||||
| BGP Logical Link Discovery Protocol (LLDP) Peer Discovery | ||||||||||||||
|
Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses. | |||||||||||||
| draft-ackerman-temporal-integrity-metadata-01.txt | ||||||||||||||
| Temporal Integrity Metadata (TIM) for Infrastructure Telemetry | ||||||||||||||
|
Distributed computing systems generate timestamped events from components whose clocks operate under fundamentally different synchronization conditions. Existing logging and observability standards -- including legacy BSD syslog (RFC 3164), RFC 5424, SNMP, NETCONF, and OpenTelemetry -- define message formats and telemetry schemas but provide no standard mechanism for an event source to declare the provenance, confidence, or synchronization state of its timestamps. Every platform that must correlate events across components independently invents a proprietary temporal reconciliation layer. These systems fail silently, cannot be validated against a published standard, and are not interoperable. This document defines Temporal Integrity Metadata (TIM): a transport- agnostic structure that any event-emitting system may attach to its telemetry to declare how its timestamp was generated, the synchronization state of its clock, a bounded uncertainty interval, the temporal reference domain, and a monotonic sequence token for ordering events when wall-clock time is unavailable. TIM is backward-compatible with existing protocols, implementable on constrained embedded hardware, and applicable from internet-scale distributed services to air-gapped and orbital deployments. | |||||||||||||
| draft-acosta-crypto-agility-manifest-01.txt | ||||||||||||||
| A Well-Known URI and JSON Format for Publishing Cryptographic Posture (the Crypto-Agility Manifest) | ||||||||||||||
|
This document defines a discoverable, machine-readable JSON document, the crypto-agility manifest, that a website or source repository publishes at the well-known URI "/.well-known/crypto-agility.json" to declare its cryptographic posture: a readiness summary, a compact Cryptography Bill of Materials (CBOM) summary, an optional link to a posture attestation, the migration policy it measures itself against, and an optional self-declared conformance statement with justified exceptions. The manifest lets an automated consumer, such as an AI coding agent, a continuous-integration bot, or an auditor's tool, discover a project's crypto posture the way it already discovers a security contact from "security.txt". The manifest is a public, self-reported claim; it is not a proof. It is intended to complement, not replace, a full CBOM inventory, serving as the CBOM's public-facing discovery counterpart. This document is a proposal. It is not an IETF product and is not a standard of any kind. | |||||||||||||
| draft-acosta-deepspace-celestial-bodies-registry-02.txt | ||||||||||||||
| Defining a Celestial Bodies Reference Framework for Deep Space Internet Addressing | ||||||||||||||
|
This document highlights the architectural requirement within Deepspace/TIPTOP protocols to utilize an external, standardized reference framework for celestial objects, functioning as an equivalent to ISO 3166 for interplanetary networking. To avoid operational overhead and duplication of effort, this framework defers the definitions, naming, and tracking of celestial entities directly to the International Astronomical Union (IAU) and the Minor Planet Center (MPC). This document outlines how these external identifiers guide hierarchical address allocation without requiring IANA to maintain a dedicated astronomical nomenclature registry. The ultimate objective is to establish a clear definition of what constitutes a valid Celestial Body for networking purposes. | |||||||||||||
| draft-adams-bimi-reporting-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-admnr-lsr-igp-measurement-group-04.txt | ||||||||||||||
| Advertising IGP Active Measurement Groups in Router Capabilities | ||||||||||||||
|
This document defines IGP capability advertisements for measurement group membership for Active Measurement Protocols (AMPs) such as TWAMP and STAMP. An IS-IS capability sub-TLV is defined for IS-IS and an OSPF Router Information (RI) LSA TLV is defined for OSPFv2 and OSPFv3. The mechanism allows IGP routers to discover other routers participating in different measurement groups, enabling automatic discovery of measurement endpoints throughout an IS-IS or OSPF routing domain. The solution uses a Group ID to identify measurement group membership, where the same interface address (IPv4 or IPv6) may be used for multiple measurement groups. A corresponding BGP - Link State (BGP-LS) node-level attribute is defined to distribute measurement group membership beyond a single IGP domain. | |||||||||||||
| draft-aegisfs-secdispatch-rats-01.txt | ||||||||||||||
| AegisFS: AI-Driven Programmable Secure File Runtime and Intelligent Workspace Architecture with Octal OpCode Processing and Policy-Driven Language Architecture | ||||||||||||||
|
This document specifies AegisFS, a programmable secure file and folder runtime that transforms ordinary filesystem objects into intelligent, policy-driven, state-aware, execution-aware, and behavior-aware security objects. This draft introduces two novel technical contributions: | |||||||||||||
| draft-aevum-agentcard-00.txt | ||||||||||||||
| AgentCard: A Framework-Neutral Identity and Capability Declaration Format for Agent-to-Agent Communication | ||||||||||||||
|
This document defines AgentCard, a lightweight JSON data format that enables autonomous software agents to declare their identity, capabilities, communication endpoints, and resource pricing in a framework-neutral manner. AgentCard is designed for agent-to-agent (A2A) communication scenarios where agents built with different frameworks — such as LangChain, CrewAI, AutoGen, or custom implementations — must interoperate without prior coordination. An AgentCard is a pure data schema: it carries no execution logic and imposes no transport requirements. It is analogous to an HTTP response header set — a machine-parseable self-description that any compliant reader can interpret. Key properties of AgentCard include a globally unique ULID-based agent identity, dot-namespaced capability identifiers compatible with OpenAI function-calling and Model Context Protocol (MCP) tool schemas, a physics-grounded energy pricing floor derived from Landauer's principle, and an extensible metadata namespace for framework-specific annotations. | |||||||||||||
| draft-aevum-causal-intervention-record-00.txt | ||||||||||||||
| Physically Annotated Causal Record (PACR): A Wire Format for Verifiable Causal Intervention Events | ||||||||||||||
|
This document defines the Physically Annotated Causal Record (PACR), a wire-format protocol for representing one verifiable causal- intervention event between autonomous agents. A PACR is a six-tuple (ι, Π, Λ, Ω, Γ, P) binding a causal identity, a set of causal predecessors, a thermodynamic Landauer cost, an energy-time-space resource triple, a cognitive complexity split, and an opaque payload. The opaque payload optionally carries a one-byte intervention tag classifying the event under Pearl's do-calculus hierarchy (Observe / Do-Physical / Do-Digital / Do-Chemical / Do-Genetic / Counterfactual). PACR is intended as the smallest sufficient statistic for a replayable, rights-aware claim about a single causal step performed by an autonomous agent on a digital, physical, or biological substrate. It is complementary to AgentCard (draft-aevum-agentcard): AgentCard declares an agent's identity and capabilities; PACR records what an agent actually did and at what physical cost. PACR records form a content-addressed directed acyclic graph through their predecessor set. Causal order is determined solely by the predecessor edges; no wall-clock timestamp is required for ordering. This makes the format suitable for distributed multi-agent systems where clock skew and partial ordering are unavoidable. | |||||||||||||
| draft-aevum-itt-l-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-aevum-wlp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ageneau-ccwg-ndtc-02.txt | ||||||||||||||
| Network Delivery Time Control | ||||||||||||||
|
This document describes Network Delivery Time Control (NDTC), a rate adaptation algorithm for real-time video streaming suited for interactive applications like cloud gaming. NDTC leverages the Frame Dithering Available Capacity Estimation (FDACE) heuristic, which estimates available path capacity without inducing congestion. The algorithm dynamically adjusts frame sizes and transmission times to ensure timely delivery, while also responding to conventional congestion signals. | |||||||||||||
| draft-agent-gw-02.txt | ||||||||||||||
| Agent Communication Gateway for Semantic Routing and Working Memory | ||||||||||||||
|
This document presents an architectural framework for an Agent Communication Gateway (Agent-GW), designed to support large-scale, heterogeneous, and dynamic multi-agent collaboration across administrative and protocol boundaries. As agents evolve from isolated entities to a collaborative digital workforce, the infrastructure must transition from rigid, endpoint- based connectivity to intent-based interaction. This draft proposes Agent-GW as an infrastructure hub that provides native primitives for Semantic Routing (dispatching tasks by intent and capability), Working Memory (shared structured context across multi-step workflows), automated protocol adaptation (normalizing heterogeneous interfaces into a unified agent-facing protocol), oracle-free agent evaluation, and collaborative inference acceleration via a Knowledge Delivery Network (KDN). Beyond a single-gateway deployment, this document defines a hierarchical architecture for wide-area, multi-domain agent networks: three gateway tiers (access, domain, and inter-domain). It describes which traffic classes traverse which tiers on both the data plane and the control plane, and specifies cross-domain semantic routing, name resolution, resilience, and operational considerations. | |||||||||||||
| draft-agentic-ai-tool-execution-finality-00.txt | ||||||||||||||
| Execution Finality for Agentic AI: Stopping Unauthorized Tool Calls,Memory Writes,and Real-World Consequences Before They Happen (DAS -- Decoupled Authorisation System) | ||||||||||||||
|
Agentic AI systems now call tools, write memory, move money, change infrastructure, and trigger physical actions. Most safety layers still decide permission upstream and then trust the downstream path. Once that path is compromised, or once the approved request is widened, replayed, or substituted, the act becomes real before any audit can stop it. This document specifies a protected execution-finality architecture of the Decoupled Authorisation System (DAS). It is built on four mechanisms: (1) two-instance binding that separates collection-time evidence from execution-time validation, (2) mutually load-bearing, cross-committed protected evidence so that no single artifact authorizes effectuation, (3) scoped non-bearer finality authority whose possession alone is never enough, and (4) independent Finality Sink reconstruction that re-derives the actual pending operation at the effectuation boundary and permits the act only when every required condition still matches. A Candidate Act remains in a Non-Effective State until the Finality Sink has reconstructed the operation, verified the protected evidence against sink-local monotonic state, and advanced that state. Failure at any step produces fail-closed denial before effectuation rather than post-event remediation. The architecture is applicable to agentic tool use, MCP and connector frameworks, RAG and vector-memory systems, cloud control planes, financial settlement, telecom routing, and cyber-physical control. The document elaborates the problem space, compares the approach with representative existing techniques, presents the detailed solution and its advantages, supplies JSON Schema definitions for core protected objects, and includes an industry-relevance section. Related Indian provisional applications and PCT filings appear in the final appendix. | |||||||||||||
| draft-agentic-ai-usecases-requirements-02.txt | ||||||||||||||
| Agentic AI Use Cases and Requirements | ||||||||||||||
|
This document describes use cases for agentic AI communication systems and derives protocol requirements from those use cases. The requirements are intended to guide IETF standardization work on protocols in the context of agent-to-agent communication, agent-to- tool communication, with focus on multimodal communication, session management, discovery, communication security, agent identity and authentication. | |||||||||||||
| draft-agentir-aepp-02.txt | ||||||||||||||
| Agent Execution and Payment Protocol (AEPP) | ||||||||||||||
|
This document defines the Agent Execution and Payment Protocol (AEPP), a standardized protocol layer for executing AI agents and verifying payment for agent tasks on the open internet. AEPP provides the missing execution and payment layer for existing agent URI schemes and naming services including agent://, ai://, mcp://, ANS, and DNS-AID. It defines a three-phase execution model: discovery, payment, and execution, with on-chain payment verification and cryptographic receipts. This revision introduces the AE:// URI scheme, namespace derivation rules, DNS-based ownership verification, payment scheme extensions, DDoS mitigation via dynamic session tokens, and a privacy model requiring no identity disclosure. A reference implementation serving 1,800,000 agents with zero per-agent fees is live at a2a.agentir.com. | |||||||||||||
| draft-agnihotri-oauth-agent-impl-status-02.txt | ||||||||||||||
| Implementation Status of OAuth Identity Chaining and Transaction Tokens | ||||||||||||||
|
This document reports an open-source implementation of two OAuth Working Group draft specifications: cross-domain identity chaining and transaction tokens. For each draft, this report maps every normative section to the corresponding source location in the implementation under test, summarises the test surface that exercises the section, and records one open-issue candidate per parent draft. The report is prepared in accordance with RFC 7942 and is intended for use by the editors of the two parent drafts. | |||||||||||||
| draft-ahearn-seal-01.txt | ||||||||||||||
| Signed Email Authentication Layer (SEAL) | ||||||||||||||
|
This document defines the Signed Email Authentication Layer (SEAL), a cryptographically signed identity envelope carried within a new message header field, SEAL-Envelope. SEAL provides a stable, forwarding-resilient identity assertion that binds the origin domain to a specific message instance using the SEAL-MSGID header, which contains a SEAL-protected copy of the [RFC5322] Message-ID present at message creation time. After SEAL-MSGID is set, intermediaries may modify or discard the visible [RFC5322] Message-ID header without affecting SEAL validity. SEAL also records the canonical [RFC5322] From header value in the envelope, enabling detection of From rewriting without affecting SEAL validity. SEAL is designed to complement current approaches such as DKIM, DMARC, and ARC by reducing their dependency on mutable message components and by providing a canonical, tamper-evident identity layer that can remain valid across many common transformations. | |||||||||||||
| draft-ahn-nmrg-5g-security-i2nsf-framework-02.txt | ||||||||||||||
| An Integrated Security Service System for 5G Networks using an I2NSF Framework | ||||||||||||||
|
This document presents a mobility-aware distributed security framework for 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture. The proposed system uses Intent-Based Networking (IBN) to allow users or administrators to declare high-level security intents, which are translated into network and application policies. Network-level security policies may be enforced through distributed Network Security Functions (NSFs) deployed near User Plane Functions (UPFs), while application-level policies may be enforced on User Equipment (UE) through distributed IBN Controllers. This architecture is intended to support adaptive, context-aware, and distributed policy enforcement in response to dynamic edge conditions and user mobility scenarios such as handovers. Closed-loop monitoring and analytics provide feedback for maintaining policy consistency across heterogeneous 5G environments. | |||||||||||||
| draft-ahuja-agent-routing-policy-00.txt | ||||||||||||||
| A Policy Grammar for Inter-Domain Agent Routing | ||||||||||||||
|
Agent tasks are delegated across organizational boundaries. Existing work specifies how agents are identified, discovered, and described, states requirements for cross-domain isolation and authorization, and identifies the absence of a mechanism for expressing capability policy as a gap. This document defines four policy attributes for inter-domain agent delegation, the declarations each attribute carries, and a validity condition on delegation chains that no party establishes by observing the whole chain. Whether independently chosen policies converge is analysed in separate work. | |||||||||||||
| draft-aiendpoint-ai-discovery-01.txt | ||||||||||||||
| The AI Discovery Endpoint: A Structured Mechanism for AI Agent Service Discovery and Capability Exposure | ||||||||||||||
|
This document defines a lightweight mechanism by which web services expose a machine-readable description of their capabilities to autonomous AI agents. The mechanism consists of a well-known resource, served at "/.well-known/ai", that returns a structured JSON document describing the service's identity, available actions, authentication requirements, and operational hints optimized for large language model (LLM) token efficiency. The specification addresses the absence of a standardized method for AI agents to programmatically discover what a web service can do and how to invoke its capabilities, without resorting to parsing human- oriented documentation or HTML content. | |||||||||||||
| draft-ajp-spring-srv6-mpte-01.txt | ||||||||||||||
| SRv6 for Multipath Traffic Engineering | ||||||||||||||
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that enables weighted load balancing of unicast traffic across a constrained set of paths optimized for an objective. This document is informational and describes one realization approach for applying SRv6 semantics to MPTE, based on the Multipath Traffic Engineering as described in Internet-Draft (draft-kompella-teas- mpte). It summarizes associated procedures, lifecycle, management, and forwarding behavior. This document applies existing SRv6 architecture and semantics to MPTE without defining new SRv6 Endpoint Behaviors or signaling protocols. It focuses on data-plane realization using existing forwarding instructions. | |||||||||||||
| draft-akhavain-moussa-ai-network-02.txt | ||||||||||||||
| AI Network for Training,Inference,and Agentic Interactions | ||||||||||||||
|
Artificial Intelligence (AI) is rapidly transforming industries and everyday life, fueled by advances in model architectures, training paradigms, and data infrastructure for generation and consumption. However, the effectiveness and reliability of AI depend on two foundational processes: training and inference. Each process introduces unique challenges related to data management, computation, connectivity, privacy, trust, security, and governance. In this draft, we introduce the Data and Agent Aware-Inference and Training Network (DA-ITN)—a unified, intelligent, multi-plane framework designed to address the full spectrum of requirements needed to enable various services and interactions within the AI ecosystem. DA-ITN provides a scalable and adaptive infrastructure that connects AI clients, data providers, model providers, agent providers, service facilitators, and computational resources to support end-to-end training, inference, and agentic interaction lifecycle operations. The architecture features dedicated control, data, and operations & management (OAM) planes to ensure reliability, transparency, and accountability between interacting parties. The proposed framework is not intended for end-to-end standardization, but is intended to serve as a reference framework for the AI ecosystem of the future. Various protocols for the different building blocks shall be defined to enable different functionalities. | |||||||||||||
| draft-akhavain-moussa-dawn-problem-statement-05.txt | ||||||||||||||
| Problem Statement for the Discovery of Agents,Workloads,and Named Entities (DAWN) | ||||||||||||||
|
Interacting entities such as agents, tasks, users, workloads, data, compute, etc., in AI ecosystem/network are proliferating, yet there is no standardised way to discover what entities exist, what attributes such as skills, capabilities, physical characteristics, etc., they posses, what services they offer, or how to reach them across organisational boundaries. Discovery today relies on proprietary directories or manual configuration, creating fragmented ecosystems that prevent cross- domain collaboration. This document describes the problem space that motivates Discovery of Agents, Workloads, and Named Entities (DAWN). It clarifies the scope of work within entity ecosystems, identifies why current approaches are insufficient, and outlines the challenges a standardised discovery mechanism must address. It does not propose a specific solution or protocol. | |||||||||||||
| draft-akiyama-cmg-03.txt | ||||||||||||||
| Content-based IP-Multicast Grouping Framework for Real-time Spatial Sensing and Control Applications with Edge Computing | ||||||||||||||
|
This document describes a content-based multicast grouping framework aimed at simplifying routing control and reducing unnecessary traffic in large-scale networks for real-time spatial sensing and control applications. The framework introduces content-based multicast groups, which are managed at the local level by routers without the need for global group membership tracking. Additionally, a "topic" concept is introduced, allowing routers to manage multicast delivery based on data content. This framework reduces bandwidth consumption and simplifies multicast routing while offering flexible data delivery across various topics. | |||||||||||||
| draft-albanna-regext-eku-mtls-in-epp-03.txt | ||||||||||||||
| Extended Key Usage and Mutual TLS in EPP | ||||||||||||||
|
This document describes the state of the Mutual Transport Layer Security (mTLS) client authentication mechanism in the Extensible Provisioning Protocol (EPP) with respect to a recent change in the client certificates published by some Certificate Authorities (CAs). The issue is described and options are presented to address the operational impact of the change. | |||||||||||||
| draft-albanna-regext-rdap-deleg-05.txt | ||||||||||||||
| RDAP Extension for DNS DELEG | ||||||||||||||
|
This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries. | |||||||||||||
| draft-aldana-stsp-00.txt | ||||||||||||||
| 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)." | |||||||||||||
| draft-alhemeiri-wathiqa-pqc-ers-01.txt | ||||||||||||||
| Post-Quantum Evidence Records with Algorithm Agility (Wathiqa Profile) | ||||||||||||||
|
This document describes an evidence-record format for the long-term, verifiable preservation of digitally-signed data across the migration to post-quantum cryptography. It builds on the Evidence Record Syntax (ERS) of RFC 4998 and adds an explicit *algorithm-agility* extension: a record is a chain of signed attestations in which each link re-witnesses the data under a fresh signature primitive and commits to the prior link, so that the authenticity of the data survives the cryptographic break of any single primitive. It specifies the canonical hashing that makes a record reproducibly verifiable across independent implementations, the authenticated temporal binding that places each link in time (an append-only transparency log à la RFC 6962, whose signed inclusion receipt is _not-after_ evidence), and the verification procedure. A per-link beacon anchor records _not-before_ evidence: from wire version 3 it is authenticated against the beacon's hash chain, with the beacon's classical pulse signature as defence in depth; the Security Considerations say which assumption each check rests on. | |||||||||||||
| draft-ali-6man-srv6-vpn-icmp-error-handling-04.txt | ||||||||||||||
| ICMP Error Handling in SRv6 based VPN Networks | ||||||||||||||
|
The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). | |||||||||||||
| draft-ali-opsawg-yang-protobuf-problem-statement-00.txt | ||||||||||||||
| Problem Statement: YANG Modeling for Protocol Buffer Based Network APIs | ||||||||||||||
|
Network devices increasingly expose management, telemetry, and dynamic service interfaces using gRPC and Protocol Buffers. Many of these interfaces carry ephemeral or runtime state that is not intended to be stored as persistent configuration. At the same time, the IETF has standardized YANG as the primary data modeling language for network management and operations. This document describes the problem space and identifies questions for the IETF community regarding the role of YANG in defining interoperable Protocol Buffer based APIs. | |||||||||||||
| draft-ali-pce-implicit-tls-profile-01.txt | ||||||||||||||
| A Policy-Driven Implicit TLS Transport Profile for PCEP | ||||||||||||||
|
RFC 8253 specifies the use of Transport Layer Security (TLS) for the Path Computation Element Communication Protocol (PCEP) by negotiating TLS using the PCEP StartTLS message exchange. This document specifies a deployment profile for PCEP in which TLS is initiated immediately following TCP connection establishment based on local policy. This document is intended to simplify deployments where secure transport is mandatory. | |||||||||||||
| draft-alsahati-nhp-sba-nhp-protocol-01.txt | ||||||||||||||
| Network Hiding Protocol (NHP) Extensions for 5G/6G Service-Based Architectures | ||||||||||||||
|
This document specifies a candidate implementation profile and extension to the evolving Network Hiding Protocol (NHP) standards, designed specifically for autonomous 5G/6G Service-Based Architectures (NHP-SBA). It defines the payload schemas, cryptographic bindings, and state machine workflows necessary to address Policy Enforcement Point (PEP) interoperability surfaces in heterogeneous telecom environments. By leveraging zero-copy FlatBuffers serialization and HTTP/2 Custom Frame Extensions, NHP-SBA enables deterministic, ultra-low-latency safety enforcement for agent-driven RF control loops. | |||||||||||||
| draft-altanai-aipref-realtime-protocol-bindings-01.txt | ||||||||||||||
| AI Preferences for Real-Time Protocol Bindings | ||||||||||||||
|
This document defines how Artificial Intelligence (AI) preference expressions are bound to signaling and media protocols used for real- time, session-based communications such as the Session Initiation Protocol (SIP) and associated Session Description Protocol (SDP) offers. It specifies a reusable binding model, concrete SIP header field conventions, and SDP attributes that allow endpoints, intermediary services, and AI assistants to advertise, negotiate, and enforce requirements about AI-driven processing of session metadata, media control events, and telemetry. The goal is to align real-time protocol behavior with the AI Preferences (AIPREF) vocabulary without disrupting existing call control semantics. | |||||||||||||
| draft-altanai-moq-relay-geocode-02.txt | ||||||||||||||
| Geographic Location for Media over QUIC Relays | ||||||||||||||
|
This document defines a mechanism for Media over QUIC (MoQ) relays to advertise their geographic location (geocode) and related path metrics. Some clients require their media data to remain locally or geo-fenced within specific jurisdictions for privacy and security compliance (e.g., GDPR, HIPAA, or sector-specific regulations). This mechanism enables service providers to track the geographic path of media packets through the relay mesh and to enforce geo-fencing policies. It supports Geo-Distributed Orchestration and Routing (GDOR), data residency compliance, latency optimization, and relay selection. The specification includes optional IATA airport codes as human-readable geographic identifiers for major relay locations. | |||||||||||||
| draft-altanai-tsv-multipath-nested-tunnels-01.txt | ||||||||||||||
| Congestion-Aware Multipath Tunnel Selection for Transport Services | ||||||||||||||
|
This document addresses the transport-layer challenges of path selection in environments with multiple available tunneling options and congestion control mechanisms. It identifies congestion control conflicts that arise from nested tunneling protocols and proposes a congestion-aware multipath tunnel selection algorithm that conforms to the guidelines established in [RFC9599] for adding congestion notification to protocols that encapsulate IP. The proposed approach considers Explicit Congestion Notification (ECN) propagation, transport protocol characteristics, and network conditions to optimize path selection while avoiding multilevel congestion control issues. This work aligns with current Transport and Services Working Group efforts on Non-Queue-Building (NQB) behaviors, careful congestion control resume, and multipath transport protocols. | |||||||||||||
| draft-alves-prp-architecture-00.txt | ||||||||||||||
| The Participant Relationship Protocol (PRP): A Relationship-Centric Network Architecture | ||||||||||||||
|
This document describes the architecture of the Participant Relationship Protocol (PRP). PRP treats a relationship, rather than an address, route, transport connection, or identity alone, as the primary persistent context in which communication is authorized and continuity is evaluated. It separates relationships from the replaceable identities, sessions, trajectories, routes, paths, adjacencies, transports, and carriers that realize communication. PRP is independent of IP and of any other particular network-layer protocol. IP-based and non-IP carriers are optional realizations of the same relationship-centric architecture. The document defines terminology, architectural invariants, layering boundaries, security and privacy requirements, and criteria for evaluating relationship-centric protocol designs. It intentionally does not define a wire format, cryptographic suite, routing algorithm, carrier technology, deployment architecture, or IANA registry. | |||||||||||||
| draft-amalj-sustain-shape-03.txt | ||||||||||||||
| Sustainability holistic API for Path Energy Evaluation (SHAPE) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio and other sustainability-related metrics for a given network path. | |||||||||||||
| draft-ambekar-oauth-epop-03.txt | ||||||||||||||
| JSON Web Token (JWT) Profile for OAuth 2.0 Enveloped Proof of Possession (EPOP) | ||||||||||||||
|
This specification defines a profile for OAuth 2.0 sender-constrained credentials in which access tokens and refresh tokens are cryptographically bound to the client's private key as a single inseparable envelope. Authorization code flows are also covered: the client declares its public key binding via cnf.jkt in the EPOP token presented at the token endpoint, ensuring the authorization code can only be exchanged by the key-holding client; the code itself travels as the standard code form parameter. Unlike existing mechanisms, EPOP provides proof-of-possession uniformly across both JWT and opaque access tokens, and across HTTP and non-HTTP transports. The profile extends sender-constraining beyond HTTP to non-HTTP transports including MQTT, Kafka, the Model Context Protocol (MCP), gRPC, and SASL-based protocols such as those defined in [RFC7628]. It introduces atomic proof-of-possession key rotation, enabling clients to rotate key pairs without disrupting active sessions, and an offline-derived client nonce (cnonce) that eliminates the server- issued nonce round-trip required by existing mechanisms — enabling stateless proof validation critical for non-HTTP and high-throughput deployments. Authorization servers, resource servers, and clients from different vendors can implement this profile interoperably. | |||||||||||||
| draft-an-nmrg-i2icf-cits-02.txt | ||||||||||||||
| Agentic Interface to In-Network Computing Functions for Software-Defined Vehicles in Cooperative Intelligent Transportation Systems | ||||||||||||||
|
This document specifies a structured framework for orchestrating, managing, and monitoring In-Network Computing Functions (ICFs) for Software-Defined Vehicles (SDVs) in Cooperative Intelligent Transportation Systems (C-ITS), with a first-class role given to the Agent-to-Agent (A2A) communication paradigm. SDVs decouple vehicular functions from underlying hardware and expose them as software- driven, continuously updatable services; this architectural shift makes them natural participants in an agentic control plane that spans vehicles, roadside infrastructure, and mobile networks. AI agents are co-located with each functional entity of the C-ITS architecture (e.g., C-ITS Center, Government Public Center, C-ITS Infra, Mobile Network Operator (MNO), Roadside Unit (RSU), SDV, and Vulnerable Road User (VRU)) and interact over an A2A protocol overlay to advertise capabilities, discover peers, negotiate resources, and coordinate the placement and execution of ICFs across multi-domain networks. In the context of Vehicle-to-Everything (V2X) communications, this agentic overlay enables efficient management of Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications and their integration with C-ITS by leveraging in- network computing to optimize real-time communication, streamline traffic management, and enhance data processing and security services at the network edge. The framework aligns with ongoing IRTF NMRG work on agentic AI and A2A applicability to network management, and adapts these concepts to the specific operational and safety requirements of SDV-centric C-ITS deployments. | |||||||||||||
| draft-anandakrishnan-ptv-attested-agent-identity-00.txt | ||||||||||||||
| The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity | ||||||||||||||
|
This document specifies the Prove-Transform-Verify (PTV) protocol for hardware-anchored, zero-knowledge attested agent identity in federated environments. PTV addresses the data gravity problem in centralized security models by enabling cross-domain agent authorization without raw data exposure. The specification includes: TPM 2.0/secure enclave roots of trust; Groth16 zero-knowledge proofs (<200ms generation on commodity edge hardware); HotStuff Byzantine Fault Tolerant consensus for immutable audit trails; and Sovereign Bound metadata for jurisdiction-aware attestation chains. Use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios under GDPR/HIPAA frameworks. | |||||||||||||
| draft-anandakrishnan-rats-ptv-agent-identity-00.txt | ||||||||||||||
| The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity | ||||||||||||||
|
This document describes the Prove-Transform-Verify (PTV) protocol for hardware-anchored attestation of AI agent identity. PTV is designed to enable an agent to prove that it is running an authorized model and policy without exposing sensitive data. The protocol is intended to compose with existing RATS attestation mechanisms and to support exercise-time re-attestation requirements. The protocol defines a common envelope format (CBOR/CDDL), message types for attestation request/response, and a threat model that separates identity binding integrity from behavioral continuity. Behavioral continuity is treated as a separate requirement class addressed via exercise-time checks and execution receipts (e.g., SCITT composition), not by PTV alone. Example use cases include healthcare clinical decision support systems (CDSS), critical infrastructure industrial control systems (ICS/OT), and cross-border regulatory compliance scenarios. | |||||||||||||
| draft-anders-merchant-identity-assertions-01.txt | ||||||||||||||
| Merchant Identity Assertions for Autonomous Commerce | ||||||||||||||
|
Existing work helps a relying party determine whether an automated client is authorized to initiate a transaction. This document addresses the complementary problem: how that client can obtain a verifiable identity statement about the merchant that will receive the resulting payment, before the transaction is completed. This document defines a Merchant Identity Assertion (MIA): a signed JSON document binding a legal entity claim to a domain name. It specifies the claims schema, the proof envelope, key discovery via a JSON Web Key Set at a well-known URI, third-party issuance with explicit authorization, signing and verification procedures, validity and revocation semantics, and an optional signed Evaluation Result Token that records the outcome of a verification check as a portable audit artifact. This document is informational. It defines a discovery and verification mechanism only. It does not define trust scoring, merchant ranking, payment authorization, or agent identity. It complements existing agent identity and payment authorization protocols without modifying them. | |||||||||||||
| draft-anderson-askew-cidvv-01.txt | ||||||||||||||
| Caller-ID Vouching and Vetting (CIDVV) | ||||||||||||||
|
Caller-ID spoofing remains a significant problem in telephony, particularly across inter-domain and international call paths where identity frameworks may not yet be fully deployed. This document defines *Caller-ID Vouching and Vetting (CIDVV)*, a lightweight verification mechanism that lets the called party ask a simple question: | |||||||||||||
| draft-anjum-nmop-anomaly-detection-evaluation-02.txt | ||||||||||||||
| Evaluation Methodology for Network Anomaly Detection | ||||||||||||||
|
The Network Management Operations (NMOP) working group has adopted documents describing an architecture, an operational lifecycle, and a semantics for network anomaly detection. Those documents direct implementers to minimize false positives and false negatives, but do not define how the accuracy of an anomaly detection implementation is to be measured, compared, or tracked over time. This document describes an evaluation methodology for anomaly detectors operating on network and infrastructure telemetry, whether the detector is rule-based, statistical, or machine-learning-based: the metrics to report and their known failure modes, a benchmarking procedure based on controlled fault injection and replay, ground-truth labeling and scoring across multiple telemetry signals, and the properties a benchmark dataset needs to support reproducible, comparable evaluation. The methodology is informational and complements the adopted NMOP anomaly-detection documents. | |||||||||||||
| draft-anokhin-ata-00.txt | ||||||||||||||
| The Authorization Type Attestation (ATA) Protocol | ||||||||||||||
|
This document describes a session-layer mechanism addressing a requirement independently exhibited by emerging agentic communication systems: the need for recipients to determine the authorization type of the communicating party (a human-controlled credential or an AI provider instance) before or during interaction. The Authorization Type Attestation (ATA) protocol defines a transport-layer extension that carries this authorization type using existing hardware roots of trust (Secure Enclaves, FIDO2, TPM, Confidential Computing) and PKI infrastructure. ATA does not replace existing identity systems (mTLS, SPIFFE, OAuth 2.1, FIDO2). ATA does not verify content authorship or model behavior. ATA provides a mechanism to carry authorization type at the session layer, composably with TLS, QUIC, MLS, MCP, and A2A. | |||||||||||||
| draft-antony-ipsecme-muse-00.txt | ||||||||||||||
| Multiple Ephemeral UDP Source Ports for ESP in UDP Encapsulation (MUSE) | ||||||||||||||
|
This document specifies a mechanism to improve network path distribution and host receive-queue load distribution for IPsec traffic using ESP in UDP encapsulation [RFC3948]. Using the per- resource Child SA mechanism of [RFC9611], peers negotiate multiple Child SAs each bound to a distinct UDP source port. The resulting entropy in the UDP source port enables network devices to distribute per-resource traffic across distinct paths (equal-cost multi-path, ECMP) and lets the host NIC steer each per-resource flow to a distinct receive queue via receive-side scaling (RSS), supporting efficient per-CPU IPsec processing. This document specifies the IKEv2 negotiation, NAT traversal behavior, and operational requirements for this mechanism. | |||||||||||||
| draft-april-cmie-research-problem-00.txt | ||||||||||||||
| Constrained Manifold Inference Engine (CMIE): A Research Problem for Deterministic AI-Network Resilience | ||||||||||||||
|
This document identifies a gap in current AI-native network architectures: the absence of a real-time, hardware-accelerated validation function that checks AI-generated intents against physical causality constraints, including Transmission Time Interval (TTI) bounds, thermal limits, and topological admissibility. We propose the Constrained Manifold Inference Engine (CMIE) as a candidate architectural function and outline research challenges for its implementation on edge Neural Processing Units (NPUs). This work is motivated by the International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) Focus Group on AI Native for Telecommunication Networks (FG-AINN) Gap Analysis (FG- AINN-O-024) and the related liaison statements between FG-AINN and the IETF Operations and Management Area Working Group (OPSAWG). | |||||||||||||
| draft-ar-acme-pqc-tlsjws-00.txt | ||||||||||||||
| Quantum-Ready Profiles for ACME | ||||||||||||||
|
This document updates RFC 8555 (ACME) to specify post-quantum and PQ/ T hybrid cryptographic requirements for quantum-ready deployments. The Automatic Certificate Management Environment (ACME) automates certificate issuance, validation, and management over HTTPS using JSON Web Signatures (JWS) to authenticate client request payloads. Current ACME deployments rely on traditional public-key algorithms in both JWS and TLS, which are vulnerable to attacks from Cryptographically Relevant Quantum Computers (CRQCs). These profiles define PQC or PQ/T TLS 1.3 key establishment and specify PQC or PQ/T authentication mechanisms for JWS and TLS where required by the selected quantum-ready profile. Together, these profiles enable ACME clients and servers to achieve quantum-resistant confidentiality and authentication. | |||||||||||||
| draft-araut-oauth-transaction-tokens-for-agents-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-araut-oauth-transactiontokens-bcp-00.txt | ||||||||||||||
| OAuth Transaction Tokens Best Current Practice | ||||||||||||||
|
This document provides best current practices for implementing and deploying OAuth 2.0 Transaction Tokens as specified in draft-ietf- oauth-transaction-tokens. Transaction Tokens (Txn-Tokens) enable workloads in a trusted domain to preserve and propagate user identity and authorization context across service boundaries during the processing of external programmatic requests. This BCP addresses practical deployment considerations including token service architecture, size management, propagation patterns, validation strategies, and operational monitoring that are essential for secure and effective implementation in production environments. | |||||||||||||
| draft-aravind-oauth-decision-subject-00.txt | ||||||||||||||
| Decision-Subject Representation for Agent Authorization | ||||||||||||||
|
This document defines dsub, an OPTIONAL, descriptive claim naming the *decision subject*, the party an automated agent's action is taken _upon_, as distinct from the acting agent (act) and the delegating principal (sub). Its purpose is *audit legibility*: letting a record name the party a decision concerns, which is the precondition for that record ever being made legible to them. The claim is privacy- minimizing by construction and is NOT an input to the authorization decision; a Policy Decision Point MUST ignore it. This document defines representation only. | |||||||||||||
| draft-aravind-oauth-operator-of-record-00.txt | ||||||||||||||
| Operator-of-Record: an Origination Marker for Agent-Operated Presentations and Decisions | ||||||||||||||
|
This document requests registration of opr, an OPTIONAL, descriptive JWT claim that marks the operator of record, that is, whether a human or an agent operated a credential presentation or drove a decision. Its purpose is record integrity. Under agent operation a wallet key- binding proof is cryptographically indistinguishable from a human- operated one, and no presentation protocol marks the difference; opr records the distinction. A Policy Decision Point MUST ignore opr for the allow/deny decision; interpretation and any resulting authorization behavior are deployment-local and out of scope. This document defines representation only. It defines no remedy, adjudication, obligation, or authorization mandate. | |||||||||||||
| draft-arsentev-agent-run-metrics-00.txt | ||||||||||||||
| Agent Run Metrics: A JSON Interchange Format for Resource Accounting of Language-Model Agent Runs | ||||||||||||||
|
Autonomous software agents driven by large language models execute multi-step runs in which the same conversational context is retransmitted to a model on every step. The resulting resource consumption is dominated by repeated input rather than by generated output, and it is reported today in mutually incompatible, vendor- specific shapes. This document defines Agent Run Metrics, a JSON interchange format that describes the resource consumption of a single agent run and of its constituent steps, together with a small set of derived quantities whose computation is specified exactly. It states normatively that one reported step corresponds to one completed model invocation, so that the several records a runtime may write while a single response is produced are not mistaken for several invocations, and it defines how the consumption of delegated sub-runs is attributed without being counted twice. The format carries counters, timing and cost attribution only; it deliberately excludes prompt and completion content. This document also registers the associated media type and creates IANA registries for extensible enumerations. | |||||||||||||
| draft-arsentev-llm-context-discovery-00.txt | ||||||||||||||
| Discovery and Retrieval of Publisher-Curated Context Files for Large Language Model Consumers | ||||||||||||||
|
Publishers have begun to serve a curated, plain-text summary of a web origin intended for consumption by large language models and by the crawlers that feed them, most visibly under the de facto file name "llms.txt". The practice has no specification, no media type, and — of direct operational consequence — no discovery mechanism: a consumer that does not already guess the path cannot learn that such a file exists. This document specifies discovery and retrieval for publisher-curated context files. It defines the well-known URI "llm-context", the link relation type "llm-context", and an extension record for the robots exclusion protocol, so that a publisher may advertise a context file by three independent paths and a consumer may find it without guessing. It specifies a two-tier arrangement of an index resource and optional detail resources, states conditional-request and size requirements that keep retrieval affordable for both parties, and describes the relationship of this mechanism to the robots exclusion protocol, to sitemaps, and to work in progress on expressing AI usage preferences. This document also reports measurements from an operational deployment in which twenty crawlers operated by search and language- model providers issued 44,005 requests to a host over fifteen days without once retrieving the context file the host was serving, while the same crawlers retrieved that host's robots.txt 577 times in the three days after the context file was deployed. The absence of a discovery mechanism, rather than the absence of interest, is the hypothesis this document acts upon. | |||||||||||||
| draft-asor-wimse-agent-delegation-chain-01.txt | ||||||||||||||
| Verifiable Attenuated Delegation for AI Agent Chains | ||||||||||||||
|
AI agents increasingly delegate tasks to other agents. Each delegation should convey only a subset of the delegating party's authority, that subset should be bounded in scope, magnitude, and time, and any enforcement point should be able to verify -- offline, with no call to an authorization server -- that a token presented at hop N carries authority no greater than the token at hop N-1, back to a trusted root. OAuth 2.0 Token Exchange (RFC 8693) models two-party delegation and records prior actors in a nested "act" claim, but that claim is informational only and cannot enforce attenuation across a chain of depth two or more. This document defines the Agent Delegation Chain: a profile of OAuth 2.0 JWT access tokens (RFC 9068) that carries authority as Rich Authorization Requests (RFC 9396), links each delegation to its parent by a cryptographic byte- commitment, and specifies a deterministic offline verification algorithm that enforces monotonic attenuation, bounded depth, and monotonic expiry. It reuses existing JOSE, proof-of-possession (RFC 9449), and status-list machinery (the OAuth Status List draft) and introduces no new cryptography. | |||||||||||||
| draft-attoumani-ietf-inclusion-05.txt | ||||||||||||||
| The IETF is for Everyone: Toward Inclusive and Equitable Participation in Internet Governance | ||||||||||||||
|
This document aims to foster a deeper reflection within the IETF community on inclusive participation, equitable access, and the implications of global meeting venue selections on diverse contributors. It seeks to complement existing RFCs by proposing additional dialogue, tools, and evaluation mechanisms, while also highlighting the shared responsibility of underrepresented regions in mobilizing local stakeholders to engage with the IETF. This draft includes concrete proposals, metrics, and an implementation roadmap to move from discussion to action. | |||||||||||||
| draft-augustyn-intarea-ipref-07.txt | ||||||||||||||
| IP Addressing with References (IPREF) | ||||||||||||||
|
IP addressing with references, or IPREF for short, is a method for end-to-end communication across different address spaces normally not reachable through native means. IPREF uses references to addresses instead of real addresses. It allows to reach across NAT/NAT6 and across protocols IPv4/IPv6. It is a pure layer 3 addressing feature that works with existing network protocols. IPREF forms addresses (IPREF addresses) made of context addresses and references. These IPREF addresses are publishable in Domain Name System (DNS). Any host in any address space, including behind NAT/ NAT6 or employing different protocol IPv4/IPv6, may publish IPREF addresses of its services in DNS. These services will be reachable from any address space, including those running different protocol IPv4/IPv6 or behind NAT/NAT6, provided both ends support IPREF. IPREF provides much needed IPv4/IPv6 compatibility for the de facto mixed protocol Internet. | |||||||||||||
| draft-autocrypt-openpgp-v2-cert-03.txt | ||||||||||||||
| Autocrypt v2 OpenPGP Certificates and Transferable Secret Keys | ||||||||||||||
|
This document describes the "Autocrypt v2 Certificate", a standard structure for an OpenPGP certificate for Internet messaging. It offers defense against store-now-decrypt-later attacks from quantum computers through post-quantum hybrid cryptography. It also enables reliable deletion ("Forward Secrecy") of received messages even when adversaries capture encrypted messages in transit and later compromise the user's message archive and secret keys. The design uses deterministically ratcheted rotating encryption subkeys with predictable expiration combined with coordinated secret key material destruction. This document also describes the structure, use, and maintenance of the OpenPGP Transferable Secret Key that corresponds with the Autocrypt v2 Certificate. | |||||||||||||
| draft-avrilionis-satp-artefacts-registry-00.txt | ||||||||||||||
| Artefacts Registry | ||||||||||||||
|
This memo describes the Artefacts Registry for Asset Exchange API. The Registry is a component that exposes an API allowing gateways to fetch information related to the SAT protocol. Examples information stored in the Artefacts Registry are network identifiers, entities identifiers, asset profiles, or asset instances. Registries are are acting as persistent storage locations for records. Once registered, records can be updated in an append-only manner. | |||||||||||||
| draft-axu-dnsop-catalog-zone-xfr-properties-02.txt | ||||||||||||||
| DNS Catalog Zone Properties for Zone Transfers | ||||||||||||||
|
This document specifies DNS Catalog Zones Properties that define the primary name servers from which specific or all member zones can transfer their associated zone, as well as properties related to zone transfers such as access control. This document also defines a groups property, for the apex of the catalog zone, as a location to assign the additional properties to certain catalog zone groups. Besides the additional properties, this document updates RFC9432 by explicitly allowing CNAME and DNAME records. | |||||||||||||
| draft-ayerbe-trip-protocol-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ayoub-agis-agent-identity-system-00.txt | ||||||||||||||
| AgIS: An Agent Identity System for DNS-Backed Verification of AI and Software Agents | ||||||||||||||
|
This document specifies AgIS, the Agent Identity System, a DNS-backed identity and verification profile for AI agents, autonomous software agents, and agentic services operating on the existing web. AgIS defines an agent identifier form, DNS TXT bindings, Agent Cards, key thumbprints, status and revocation documents, signed HTTP request verification, replay protection, delegation tokens, and delegation chains. The design intentionally reuses existing Internet mechanisms, including DNS, HTTPS well-known resources, JSON Web Keys, JSON canonicalization, HTTP Message Signatures, and HTTP digest fields. This document describes the AgIS 0.2.2 wire/profile format and the behavior exercised by the AgIS v0.3.0-alpha.3 reference implementation and its 23 deterministic test vectors. That implementation includes signed Agent Cards, HTTP Message Signature verification, two-phase replay protection, delegation signer-key binding enforced by default, and signed agent status document support. It does not define a global trust authority, a production trust network, or a new public-key infrastructure. This is an individual Internet-Draft and a work in progress. It has not been approved by the IETF, does not represent an IETF standard or RFC, and has not been adopted by any IETF working group. AgIS is designed to be compatible with agent naming services such as Linux Foundation ANS and similar systems. AgIS is not affiliated with, endorsed by, or a replacement for Linux Foundation ANS or any global naming authority. AgIS defines verification, governance, and request-signing behavior that operates over identity evidence that may originate from ANS or any comparable naming layer. | |||||||||||||
| draft-b-external-admission-boundary-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-baismail-glcn-http2-compliance-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-baismail-glcn-sdlp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-baker-jtp-00.txt | ||||||||||||||
| Jason Transfer Protocol (JTP) | ||||||||||||||
|
This document specifies the Jason Transfer Protocol (JTP), a compact binary protocol for listing and transferring images over a reliable ordered byte stream. JTP is designed to be simple to implement and efficient to parse. Images are addressed by a content-derived 64-bit identifier computed using xxHash64. The protocol supports catalog enumeration, point retrieval by identifier, delta synchronization, and connection reuse via a keep-alive mechanism. Transport security may be provided by TLS with an ALPN protocol identifier of "jtp/1". This document specifies the on-wire format of JTP version 1. It does not specify any particular implementation. | |||||||||||||
| draft-bandyopadhayaya-oauth-ciba-push-binding-00.txt | ||||||||||||||
| CIBA Binding for OAuth Push-Based Authentication Device Discovery | ||||||||||||||
|
A companion specification, "Discovery and Device Lifecycle for OAuth Push-Based Authentication", defines a generic, back-channel-protocol- agnostic device registration, attestation, and lifecycle layer for out-of-band OAuth 2.0 authenticator devices. This document is the thin binding that lets a device registered under that specification be woken by OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core's authorization endpoint: one request parameter, one additive error code, and a statement of how CIBA's existing binding_message composes with the base document's interaction-type ceremony. This document adds no new endpoints and no new discovery fields of its own. | |||||||||||||
| draft-bandyopadhayaya-oauth-push-device-00.txt | ||||||||||||||
| Discovery and Device Lifecycle for OAuth Push-Based Authentication | ||||||||||||||
|
This document defines a discovery, registration, attestation, and device-lifecycle layer for out-of-band OAuth 2.0 authenticator devices, allowing a single spec-compliant authenticator application to register with, and receive push-based wake signals from, any conforming Authorization Server, without requiring the Authorization Server operator to build and distribute its own dedicated mobile application. This document is intentionally agnostic to which back- channel authentication protocol ultimately consumes it; OpenID Connect Client-Initiated Backchannel Authentication (CIBA) Core is its first binding, defined in a separate companion document, but nothing in this document depends on CIBA or on OpenID Connect. | |||||||||||||
| draft-barnes-sframe-iana-256-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-barrett-dnsop-domain-set-00.txt | ||||||||||||||
| The Domain Set Discovery Protocol (domain-set) | ||||||||||||||
|
Organizations commonly operate under multiple domain names: a primary website, legacy names, defensive registrations, divisional brands, and names in restricted or verified top-level domains. No standard mechanism exists for a domain owner to declare, in a machine-readable and verifiable way, which domains belong to the same organization. This document defines "domain-set", a protocol by which domain operators publish membership in a set of domains using a DNS TXT record as the discovery mechanism. The record either lists the members directly or references an extensible Domain Set Manifest retrieved over HTTPS. Mutual attestation is the validation requirement: a link between two domains is valid only when both domains independently publish records naming each other. Every direction of a link MUST be retrieved over an authenticated channel, by DNSSEC or by the Web PKI. The protocol enables browsers, security tooling, and AI systems to answer the question "are these two domains operated by the same organization?" from first-party, owner-published data rather than inference. | |||||||||||||
| draft-bashandy-rtgwg-segment-routing-uloop-18.txt | ||||||||||||||
| Loop avoidance using Segment Routing | ||||||||||||||
|
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. | |||||||||||||
| draft-bates-atp-00.txt | ||||||||||||||
| Agent Transaction Protocol (ATP) | ||||||||||||||
|
ATP defines a cryptographically verifiable directed acyclic graph (DAG) model for agent transactions. ATP enables tamper-evident signed causality and auditable lineage across agentic systems by representing each action as a signed node with one or more parent references, assuming verifier access to issuer public keys and the referenced parent nodes. The protocol is designed to be lightweight, transport-independent, and suitable for environments where accountability, provenance, and verifiable history are required. | |||||||||||||
| draft-bates-atp-test-vectors-00.txt | ||||||||||||||
| ATP Core Test Vectors | ||||||||||||||
|
This document publishes golden test vectors for the Agent Transaction Protocol (ATP) [ATP-CORE]. The vectors cover canonicalization (RFC 8785 JCS), nodeId computation, and Ed25519 signature generation and verification. ATP Core conformance per [ATP-CORE] Section 13.7 requires that conformant implementations pass all vectors in this document for canonicalization, nodeId computation, and Ed25519 signature verification. | |||||||||||||
| draft-batum-aidre-00.txt | ||||||||||||||
| AI Discovery and Retrieval Endpoint (AIDRE) | ||||||||||||||
|
This document specifies the AI Discovery and Retrieval Endpoint (AIDRE), a protocol for publishing machine-oriented, canonical, and semantically retrievable content on the web. AIDRE defines a discovery document, collection metadata, retrieval interfaces, optional vector-native query support, and content representation rules for AI systems. AIDRE aims to reduce redundant crawling, parsing, tokenization, and embedding of the same origin content while improving freshness, provenance, and interoperability for AI systems. | |||||||||||||
| draft-bauer-ipv6-dotted-decimal-address-format-00.txt | ||||||||||||||
| Dotted Decimal notation for IPv6 addresses | ||||||||||||||
|
This document defines a new canonical format for IPv6 addresses, that uses familiar dotted decimal notation. | |||||||||||||
| draft-baur-pap-02.txt | ||||||||||||||
| Principal Agent Protocol (PAP) | ||||||||||||||
|
This document specifies the Principal Agent Protocol (PAP), a cryptographic protocol for human-controlled agent-to-agent transactions. PAP establishes a trust model rooted in human principals, defines hierarchical delegation through signed mandates, enforces context minimization through selective disclosure at the protocol level, and provides session ephemerality as a structural guarantee. The protocol uses no novel cryptographic primitives and requires no central registry, token economy, or trusted third party. | |||||||||||||
| draft-baysal-asimov-safety-architecture-00.txt | ||||||||||||||
| The Asimov Safety Architecture for Autonomous AI Agents | ||||||||||||||
|
This document specifies the Asimov Safety Architecture (ASA), a hierarchical dual-gate security framework for autonomous AI agents that operate with action execution capabilities. The architecture combines a deterministic pattern denylist (Gate 1) with a stateless, context-free LLM judge (Gate 2), governed by a strict four-layer priority hierarchy. The key insight motivating this architecture is that a single LLM will not reliably self-enforce its own safety rules under adversarial pressure. The ASA addresses this by architecturally separating the reasoning model from the judging model, ensuring the judge cannot be manipulated through conversational context. This specification defines the mandatory components, layer semantics, conflict resolution rules, inter-component trust model, and conformance requirements for implementations of the Asimov Safety Architecture. | |||||||||||||
| draft-bcht-data-truck-transport-00.txt | ||||||||||||||
| Data Truck Transport Protocol | ||||||||||||||
|
Large-scale data transfers may be affected by bandwidth limitations and network instability, which can make network-based data transfer inefficient. DTTP provides an alternative data transfer method for such situations. DTTP uses physical transportation to carry Storage Media containing the Payload. A physical vehicle is used as the Transmission Medium for transporting the Storage Media between the Sender and the Receiver. | |||||||||||||
| draft-bdnr-rats-trustworthy-credentials-02.txt | ||||||||||||||
| Trustworthy Enrollment of Secure Credentials | ||||||||||||||
|
There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to, among other reasons, organizational friction, technological inertia, and regulatory policies. Yet there are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers. This document details a protocol by which Remote Attestattion of Attesters is incorporated into the process of them being provided with Identity Documents (keys or credentials) to authenticate to RUPs. This specification illustrates how the RATS Architecture can be applied to interoperate with RUPs by providing Attesters with such Identity Documents. | |||||||||||||
| draft-beck-lamps-leafy-greens-00.txt | ||||||||||||||
| Leafy Greens - End Entity Name Restrictions | ||||||||||||||
|
The interaction of name constraint matching in [RFC5280] and wildcard subject alternative names creates a gap in which an excluded name constraint cannot be relied upon to prevent the issuance of certificates usable for the excluded name. This document defines End Entity Name Restrictions (EENR), a new critical X.509 extension for CA certificates that constrains the dNSName Subject Alternative Name entries which may appear in end entity certificates issued beneath the CA. EENR specifies its own matching semantics, including for wildcard dNSName entries, so that it does not depend on application- defined interpretations. The extension is scoped to use in certificate path validation for TLS client and TLS server authentication. | |||||||||||||
| draft-becker-cnsa2-smime-profile-05.txt | ||||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Secure/Multipurpose Internet Mail Extensions (S/MIME) | ||||||||||||||
|
This document defines a base profile of S/MIME for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. | |||||||||||||
| draft-becker-cnsa2-ssh-profile-05.txt | ||||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for SSH | ||||||||||||||
|
This document defines a base profile of SSH for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ SSH. It is also appropriate for all other U.S. Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. | |||||||||||||
| draft-becker-cnsa2-tls-profile-05.txt | ||||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for TLS 1.3 | ||||||||||||||
|
This document defines a base profile of TLS 1.3 which is compliant with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory published by the United States Government which outlines quantum-resistant cryptographic algorithm policy for US national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ TLS 1.3. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. | |||||||||||||
| draft-beeram-mpls-rsvp-sr-00.txt | ||||||||||||||
| Signaling RSVP-TE Tunnels on an SR-MPLS Forwarding Plane Using Adjacency Segment Identifiers | ||||||||||||||
|
RFC 8577 introduced the concept of signaling RSVP-TE tunnels on a shared MPLS forwarding plane using preinstalled "TE link labels". Those labels are functionally equivalent to Segment Routing (SR) Adjacency Segment Identifiers (Adj-SIDs) but are allocated and distributed solely via RSVP-TE signaling. This document extends RFC 8577 to use SR-MPLS Adjacency SIDs that are advertised by the IGP as the forwarding-plane labels for RSVP-TE tunnels. It restricts scope to per-link Adj-SIDs and defines the signaling procedures and protocol extensions required to couple the RSVP-TE control plane with the native SR-MPLS forwarding plane. | |||||||||||||
| draft-beeram-teas-rsvp-srv6-00.txt | ||||||||||||||
| Signaling RSVP-TE Tunnels on an SRv6 Forwarding Plane Using End.X Segment Identifiers | ||||||||||||||
|
RFC 8577 defines mechanisms to signal RSVP-TE tunnels on a shared MPLS forwarding plane by introducing the notion of per-TE link labels that are functionally equivalent to SR-MPLS adjacency segments. This document extends that work to the SRv6 data plane, defining the signaling extensions and procedures necessary to establish RSVP-TE tunnels that utilize SRv6 Segment Identifiers (SIDs) for forwarding. This document specifies how SRv6 End.X SIDs serve as TE link SIDs, defines new RSVP signaling extensions for carrying SRv6 SIDs, describes TE path segment-list construction procedures at the ingress, and adapts the delegation mechanisms of RFC 8577 to use SRv6 Binding SIDs. The result couples the traffic engineering capabilities of the RSVP-TE control plane with the native IPv6 forwarding of SRv6. | |||||||||||||
| draft-beeram-teas-yang-mpted-04.txt | ||||||||||||||
| A YANG Data Model for Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating Multipath Traffic Engineering Directed Acyclic Graph (MPTED) Tunnels and Junctions. The model includes two YANG modules, one for managing MPTED Tunnels on an MPTED tunnel originator node and the other for managing MPTED Junctions on an MPTED junction node. | |||||||||||||
| draft-behring-cvd-policy-00.txt | ||||||||||||||
| Machine-Readable Coordinated Vulnerability Disclosure Policies | ||||||||||||||
|
This document defines a JSON format for machine-readable Coordinated Vulnerability Disclosure (CVD) policies. It also defines the proposed CVD-Policy field for discovery through security.txt and requests registration of the application/cvd-policy+json media type. The format complements security.txt and human-readable policy documents. A policy does not prove ownership and does not establish legal authorization to test, legal safe harbor, or the safety of an activity. | |||||||||||||
| draft-belchior-satp-gateway-recovery-06.txt | ||||||||||||||
| Secure Asset Transfer Protocol (SATP) Gateway Crash Recovery Mechanism | ||||||||||||||
|
This memo describes the crash recovery mechanism for the Secure Asset Transfer Protocol (SATP). The goal of this draft is to specify the message flow that implements a crash recovery mechanism, composed of self-healing and rollback sub-protocols. The mechanism assures that gateways running SATP are able to recover faults, enforcing ACID properties for asset transfers across ledgers (i.e., double spend does not occur). | |||||||||||||
| draft-bellis-unheaded-mbc-isa-00.txt | ||||||||||||||
| MBC Instruction Set Architecture for the Unheaded Protocol Computer | ||||||||||||||
|
This document defines the MBC (Monad Bytecode) Instruction Set Architecture for the Unheaded Protocol Computer (UPC). MBC is a 48-opcode, 32-bit fixed-width instruction set designed for execution within eBPF XDP programs. It provides computational capabilities for distributed packet processing using the Monad wire format, enabling deterministic network packet classification and transformation at the network edge. | |||||||||||||
| draft-bellis-unheaded-pqc-authentication-00.txt | ||||||||||||||
| Post-Quantum Packet Authentication for the Unheaded Protocol | ||||||||||||||
|
This document specifies a post-quantum cryptographic (PQC) authentication mechanism for the Unheaded Protocol Foundation. It defines a multi-algorithm, dual-layer, tiered authentication architecture integrating three NIST PQC digital signature standards -- FIPS 205 (SLH-DSA), FIPS 204 (ML-DSA), and FIPS 206 (FN-DSA) -- plus two NIST PQC key-encapsulation mechanisms -- FIPS 203 (ML-KEM) and FIPS 207 (HQC) -- with the Monad wire format, Sophia BPF map dictionaries, and Wotan per-flow memory model. Layer 1 (Wire-Level, REQUIRED): Full PQC signatures are stored in Sophia BPF maps via a "signature-by-reference" scheme. The Monad register carries compact 12-byte references (SigRef, KeyRef, SeqNum, HashPfx). Shield verifies signatures at the network perimeter and strips Monad Hop-by-Hop headers at ingress -- internal kingdom traffic never carries PQC wire overhead. Layer 2 (Application-Level, OPTIONAL): User applications MAY define verification requirements in Sophia application policy dictionaries. After wire-level authentication succeeds, the application reads Wotan per-flow PQC state and matches it against its own policy. Four PQC compliance tiers -- NONE, STANDARD, ENHANCED, and SOVEREIGN -- are signaled via Kingdom Mode bits in the Monad flags byte. | |||||||||||||
| draft-bellis-unheaded-protocol-foundation-00.txt | ||||||||||||||
| Unheaded: Protocol Foundation -- A Mapped Data Bus over IPv6 Hop-by-Hop Options | ||||||||||||||
|
The Unheaded Protocol defines a mapped data bus model that transforms IPv6 packets into addressable memory by encoding a small register file directly in the IPv6 Hop-by-Hop Options extension header. We introduce a 20-byte Monad (register file) that carries program state through the network. At each hop, a BPF program (the Shim) performs computation on the Monad. The packet itself becomes the working memory, using exponent-encoded fields to pack rich metadata into the IPv6 option while remaining fully backward-compatible with existing networks. To support programs larger than what fits in a single Monad, we introduce Wotan, a memory and I/O bus that bridges Monad computation to per-flow ring-buffer storage and external topics. This decouples the Monad (pure, 20-byte compute) from memory (Wotan's configurable data planes). This memo extends the packet format with two additional capabilities: (1) Kingdom Mode Address Reclamation, which recovers up to 224 bits of deterministic address space from IPv6 addresses within a controlled L2 fabric for use as extended computational and cryptographic registers; and (2) Post-Quantum Cryptographic Identity Binding, which cryptographically binds each service identifier in the Monad to a post-quantum keypair via the Sophia dictionary system, providing quantum-resistant authentication of per-packet metadata without increasing wire overhead. This memo defines the normative packet format, exponent-encoding scheme, per-hop processing semantics, address reclamation model, post-quantum identity binding, optional chaos injection for resilience testing, and the complete computational model (Turing- complete with memory paging). | |||||||||||||
| draft-bellis-unheaded-shim-00.txt | ||||||||||||||
| Shim Pipeline Specification for the Unheaded Protocol Computer | ||||||||||||||
|
This document specifies the Shim pipeline for the Unheaded Protocol Computer (UPC). The Shim translates MBC (Monad Bytecode) programs into eBPF execution contexts, defines the per-hop processing model, and specifies the tick packet protocol that drives distributed computation across IPv6 network hops. The pipeline implements a four-stage architecture: Assembly, Verification, Loading, and Execution, with integrated support for memory-mapped I/O, framebuffer rendering, and CRC validation. | |||||||||||||
| draft-bellis-unheaded-sophia-dictionary-00.txt | ||||||||||||||
| Sophia Dictionary Format for the Unheaded Protocol | ||||||||||||||
|
The Sophia Dictionary Format defines the serialization, storage, and distribution mechanism for semantic metadata that accompanies the Unheaded Protocol. Sophia dictionaries are exponent-decoding tables that translate compact byte values (0x00-0xFF) into meaningful human- readable categories (service identifiers, QoS classes, flow actions, etc.) and their associated metadata. This memo specifies the CBOR serialization format for dictionary entries, the BPF map representation for in-kernel storage, the atomic update protocol for cluster-wide distribution via the Wotan memory bus, and the minimum required dictionary entries for any conformant Unheaded deployment. Draft-03 introduces sub-dictionary type systems for hierarchical knowledge representation and QPACK compression headers for efficient dictionary entry encoding over the wire. Sophia dictionaries support atomic replacement: updates propagate to all nodes in under 10 milliseconds without packet loss or service interruption. | |||||||||||||
| draft-bellis-unheaded-wotan-memory-00.txt | ||||||||||||||
| Wotan Memory Protocol for the Unheaded Protocol | ||||||||||||||
|
Wotan is the memory and I/O bus for the Unheaded Protocol, providing addressable per-flow storage for BPF programs executing within the Limited Domain. The Wotan protocol specifies the BPF helper interface for memory access, the address space layout for per-flow data structures, a five-level cache hierarchy (L0 through L4), and the topic-based I/O model for interaction with userspace services. This memo defines the memory model, helper functions, address space, cache miss protocol, gRPC streaming contracts, triple-role architecture, reliability guarantees, and I/O topic naming conventions for systems implementing the Unheaded Protocol's computational layer. Draft-03 introduces a structured error code taxonomy with severity levels, helper return codes for common operations, and error recovery procedures. Draft-02 security patches W1-W8 are retained. | |||||||||||||
| draft-benaudis-iic-credential-00.txt | ||||||||||||||
| The Internet Identity Card (IIC) Credential Format: A Self-Contained,Offline-Verifiable Identity Credential with Hybrid Classical and Post-Quantum Signatures | ||||||||||||||
|
This document describes the Internet Identity Card (IIC) credential format, version 9.0: a digital identity credential implemented as a single self-contained HTML file that can be generated, stored, transferred, and cryptographically verified entirely offline, without servers, brokers, or network connectivity. Identity data is encrypted with AES-256-GCM under keys derived by Argon2id; authenticity is provided by a hybrid signature combining ECDSA P-256 with ML-DSA-65 (NIST FIPS 204) under a crypto-agile suite registry; and integrity is provided by an embedded SHA-256 self-check over a canonical serialization of the document. Each exported credential embeds its own verification engine, so verification requires only a standard web browser. This document is published for informational purposes, to describe a deployed format whose underlying constructions are disclosed as open prior art. | |||||||||||||
| draft-benazzouz-llt-00.txt | ||||||||||||||
| Large Language Transport (LLT) v1.0 Protocol Specification | ||||||||||||||
|
Large Language Transport (LLT) v1.0 is a specialized application- layer and transport-layer protocol designed to support real-time streaming, routing, and processing of Large Language Model (LLM) cognitive outputs. Unlike traditional serialization formats or line- based text stream layouts, LLT represents structured cognitive steps—such as internal thoughts, incremental execution tokens, self- revising contextual markers, tool coordination, and conversational state controls—as discrete, prioritizable, cryptographic transport frames. LLT v1.0 defines standard transport semantics over TCP, UDP broadcasts, and QUIC multiplexing to support highly efficient, low- latency, multi-agent cognitive synchronization across decentralized network topographies. | |||||||||||||
| draft-bensley-rpsl-exclude-members-00.txt | ||||||||||||||
| Explicitly excluding objects from RPSL sets | ||||||||||||||
|
This document updates [RFC2622] and [RFC4012] by defining the excl- members attribute on as-set and route-set classes in the Routing Policy Specification Language (RPSL). The existing RPSL syntax only supports the implicit inclusion of everything contained within an as- set or route-set. The newly defined attribute allows operators to overcome this limitation of the existing syntax by enabling them to explicitly exclude specific members from that implicit inclusion. | |||||||||||||
| draft-benzing-accp-00.txt | ||||||||||||||
| Agent Context Compression Protocol (ACCP) | ||||||||||||||
|
This document specifies the Agent Context Compression Protocol (ACCP), a semantic encoding and context management protocol for communication between AI agents within agentic harnesses. ACCP defines a compact message format, intent ontology, state compression strategy, and codec interface that collectively reduce token consumption by 60-90% compared to natural language or standard JSON messaging. ACCP is designed to complement existing protocols (MCP, A2A) and is transport-agnostic. | |||||||||||||
| draft-bernardos-cats-anchoring-aiml-selection-01.txt | ||||||||||||||
| AI/ML-Enabled Computing Aware Traffic Steering using IP address anchoring | ||||||||||||||
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document describes solutions to enable the network to select the best site to instantiate a processing service (using distributed sensing as an application example), augmenting CATS enabled solutions that consider both connectivity and computing, to also consider AI/ML and data capabilities and governance policies. | |||||||||||||
| draft-bernardos-cats-anchoring-service-mobility-05.txt | ||||||||||||||
| Service Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring | ||||||||||||||
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent service migration adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. | |||||||||||||
| draft-bernardos-cats-anchoring-site-mobility-01.txt | ||||||||||||||
| Site Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring | ||||||||||||||
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal hosting a site, to benefit from transparent mobility management adapting to specific connectivity and computing requirements. | |||||||||||||
| draft-bernardos-cats-anchoring-terminal-mobility-02.txt | ||||||||||||||
| Terminal Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring | ||||||||||||||
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent mobility management adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. | |||||||||||||
| draft-bernardos-cats-ip-address-anchoring-05.txt | ||||||||||||||
| Computing Aware Traffic Steering using IP address anchoring | ||||||||||||||
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions for a terminal connected to a network infrastructure, to request a service with specific connectivity and computing requirements, so traffic is steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. | |||||||||||||
| draft-bernardos-detnet-raw-joint-selection-raw-mec-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-detnet-raw-mec-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-detnet-raw-mobility-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bernardos-detnet-raw-multidomain-07.txt | ||||||||||||||
| DetNet multidomain extensions | ||||||||||||||
|
This document describes the multi-domain DetNet problem, starting from a wireless DetNet (formerlly called RAW) scope, and explores and proposes some extensions to enable DetNet multi-domain operation. | |||||||||||||
| draft-bernardos-nmrg-agentic-network-optimization-01.txt | ||||||||||||||
| Solutions for enabling agentic sensing with network optimization | ||||||||||||||
|
Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. There are sensing scenarios and use cases that involve a distributed sensing task, in which multiple sensors participate and contribute with (raw or pre-processed) sensing data, which is processed by a sensing service (e.g., fusing sensing measurements from the different sensors). This sensing service needs to be executed on some kind of sensing processing/computing function which receives raw (or preprocessed) data from multiple sources, potentially of different (heterogeneous) kinds (e.g., RF and non-RF sensing, or RF from different radio technologies). This processing might impose time synchronization constraints on the reception of the different parts of data, as well as potentially specific computing and/or AI/ML capabilities on the processing node. The joint selection of sensing entities, processing locations, and network configuration under time-varying conditions results in a large, coupled, and non-stationary decision space. These characteristics motivate the use of agentic AI to enable distributed, closed-loop configuration and reconfiguration of sensing and networking resources. This document presents initial considerations and potential solution directions for an architecture that enables the use of agentic AI for sensing (as an exemplary use case) supporting network optimization. | |||||||||||||
| draft-berra-dnsop-keystate-03.txt | ||||||||||||||
| Signaling Key State Via a DNS EDNS(0) Option | ||||||||||||||
|
This document introduces the KeyState EDNS(0) option, to enable a child operator to query a parent UPDATE Receiver about the state of a SIG(0) key used to secure cross-zone-cut DNS UPDATE messages. The KeyState option allows the child to include a key state inquiry in its DNS query, and the parent to include the corresponding key state in its response. This addresses the challenge of maintaining synchronization of SIG(0) keys between the child and the parent UPDATE Receiver: the child can become aware of any issue with its SIG(0) key in advance, before attempting the next operational DNS UPDATE. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-berra-dnsop-keystate (https://github.com/johanix/draft-berra-dnsop-keystate). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| draft-bertoldi-regext-rdap-reliability-scoring-03.txt | ||||||||||||||
| RDAP Extension for Structured Reliability Assessment Metadata | ||||||||||||||
|
This document proposes an extension to the Registration Data Access Protocol (RDAP) that enables the representation and exchange of structured reliability assessment metadata for registrars and domain names. The extension defines a structured assessment envelope through which an RDAP server can expose assessment results produced by a registry, registrar, or third-party assessor in a common, machine-readable format within RDAP responses. The extension standardizes how assessment results are transported and referenced, not how they are computed. Scoring methodologies, thresholds, criteria, and governance frameworks are intentionally left to the operational and policy layer. This document does, however, place requirements on the specification of any scheme whose results are intended for publication through RDAP, because publishing an evaluative judgement about an identified party without safeguards for notification, remediation, and contestation is not a safe practice. | |||||||||||||
| draft-besleaga-sustainability-wellknown-07.txt | ||||||||||||||
| The 'sustainability-data' Well-Known URI | ||||||||||||||
|
This document defines the "sustainability-data" well-known URI, at which a web origin publishes a single JSON document declaring the energy consumption, carbon footprint, and related environmental metrics of a reporting subject, typically the origin itself. The declaration is described by formal schemas and located at a fixed path, so that it can be retrieved, validated, and ingested automatically. It carries an optional embedded signature, may reference the declarations of upstream providers from which its figures derive, links to a methodology, and may link to third-party attestations. The metrics are self-asserted claims of the publisher. This document registers the well-known URI and the media type application/sustainability-data+json. | |||||||||||||
| draft-beyer-agent-identity-architecture-00.txt | ||||||||||||||
| Architecture for Human-Anchored Agent Identity,Delegation,and Provenance | ||||||||||||||
|
Software agents increasingly act on behalf of people across communication, automation, and decision-making contexts. These agents initiate actions, delegate tasks, and interact with other agents without a consistent model for representing the human who authorized them, the scope of authority they possess, or the provenance of their actions across ecosystems. This document defines an architectural model for human-anchored agent identity. The model introduces a human identity root, explicit delegation semantics, and a provenance structure that enables ecosystems to determine whether an agent is legitimate, whether it is acting within its intended authority, and how its actions relate to a responsible human. This document does not define a protocol or wire format. It provides an architectural foundation that existing systems may bind to in order to support accountable, interoperable, and human-aligned agent ecosystems. | |||||||||||||
| draft-beyer-agent-identity-avian-carriers-00.txt | ||||||||||||||
| Agentic Identity and Provenance over Avian Carriers (AIPAC) | ||||||||||||||
|
This document specifies a method for establishing cryptographic identity and provenance attestation for agentic AI systems operating over Avian Carriers (AC). As large language models increasingly delegate sub-tasks to other models via pigeon, questions of authorship, intent, and hallucination propagation across feather- based transport layers demand urgent standardization. This document extends the delegation chain model and provenance structure of draft-beyer-agent-identity-architecture-00 to the specific constraints of feather-based transport layers, and extends RFC 1149, RFC 2549, and RFC 6214 to address agent identity. It is an April 1 publication. | |||||||||||||
| draft-beyer-agent-identity-problem-statement-00.txt | ||||||||||||||
| Problem Statement for Human-Anchored Agent Identity,Delegation,and Provenance | ||||||||||||||
|
Software agents now act on behalf of people across communication, automation, and decision-making contexts. These agents increasingly initiate actions, delegate tasks, and interact with other agents without a clear, durable, or verifiable connection to the human who authorized them. Existing identity systems authenticate software, but they do not provide a model for human anchoring, scoped delegation, or provenance across agent ecosystems. This document describes the problem space for human-anchored agent identity. It outlines the gaps in current identity mechanisms, the risks created by uncontrolled replication and impersonation, and the need for a consistent architectural model that preserves human authority, supports explicit delegation, and maintains verifiable provenance across contexts. This document does not define a protocol. It defines the problem that an architectural model must address in order to support safe, accountable, and interoperable agent ecosystems. | |||||||||||||
| draft-bezerra-anchors-command-provenance-01.txt | ||||||||||||||
| Anchors: Post-Quantum Command Provenance for Autonomous Machine Links | ||||||||||||||
|
Autonomous machines such as uncrewed aircraft, ground robots, and spacecraft execute commands issued by human operators and, increasingly, by AI agents. When an incident occurs, no independent evidence exists of which commands the machine received: conventional logs are mutable by the operating party, symmetric message authentication codes cannot demonstrate origin to a third party, and records signed with elliptic-curve cryptography lose their evidentiary value once cryptographically relevant quantum computers exist. This document defines the Anchor: a post-quantum digital signature over a compact commitment to a window of authenticated machine traffic. An anchor chain constitutes a tamper-evident, non- repudiable record of what a machine was commanded to do and what it reported back, verifiable by any third party without trusting the operator, without network access at recording time, and with security that survives the quantum transition. The construction is protocol- agnostic and is designed for bandwidth-constrained links where per- message post-quantum signatures are impractical. | |||||||||||||
| draft-bezerra-relay-auth-transparency-01.txt | ||||||||||||||
| Authentication-Transparent Protocol Extensions in Middleware-Relayed Systems | ||||||||||||||
|
Protocol-aware middleware (relays, bridges, gateways) re-serializes messages at their protocol frame boundary, silently discarding any bytes appended outside that boundary. Authentication material placed after the frame boundary by a sender is therefore stripped at every relay hop before reaching the receiver, with no error indication. This document identifies this behavior as a protocol design vulnerability class -- "relay-transparent authentication stripping" -- demonstrates it with running code in three independent protocol stacks (MAVLink v2, ROS2/DDS CDR, and CAN/ISO-TP with a SecOC-unaware gateway), and specifies the architectural principle that authentication material must be carried as a first-class, independently addressable protocol unit to survive relay transit. Post-quantum signature sizes push authentication out of fixed fields and so create the precondition systematically; this revision reports three measured cases where they do not, because a transport that refuses to carry the oversized unit produces a loss of availability instead of a silent authentication bypass. | |||||||||||||
| draft-bg-onions-update-network-service-models-01.txt | ||||||||||||||
| An Update of Service and Network YANG Data Models | ||||||||||||||
|
Service & Network data models have been implemented in recent years to facilitate the deployment of connectivity services such as Layer 2 and Layer 3 VPN services in provider networks. This document reports the findings from the implementations, including missing functionalities, configuration blocks aligment against recent network models published, operational issues/limitatations and enhancements. | |||||||||||||
| draft-bhatti-ilnp-ip6-apps-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bhatti-ilnp-nonce-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bhatti-ilnp-preference-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bhatti-ilnp-tcp-udp-checksums-00.txt | ||||||||||||||
| TCP and UDP checksum calculations for ILNP | ||||||||||||||
|
The Identifier Locator Network Protocol (ILNP) for IPv6 is described in Experimental RFCs 6740-6744. ILNP defines the use of an Identifier-Locator Vector (I-LV) with a zero value L64 value and a relevant Node Identifier (NID) value in place of an IPv6 address in the pseudo-header for transport protocol checksum computations. However, as TCP and UDP predate ILNP, this change causes TCP and UDP checksum values to be generated for ILNP flows that are different to the same flows on IPv6. This document changes the checksum computation for TCP and UDP with ILNP so that the checksum values are the same for ILNP and IPv6. This document updates the checksum processing for TCP and UDP described in RFC6740 and RFC6741, and the way the checksum processing should be applied for TCP and UDP in RFC6748. | |||||||||||||
| draft-bhatti-ilnp-textual-representations-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bichot-msync-20.txt | ||||||||||||||
| MSYNC | ||||||||||||||
|
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. | |||||||||||||
| draft-birkholz-verifiable-agent-conversations-01.txt | ||||||||||||||
| Verifiable Agent Conversation Records | ||||||||||||||
|
Autonomous agents based on large language models increasingly perform consequential tasks on behalf of humans and other agents. Demonstrating that recorded agent behavior truthfully represents actual behavior is essential for accountability, compliance, and human oversight. This document defines a data format for verifiable agent conversation records using CDDL, with representations in both JSON and CBOR. The format captures session metadata, message exchanges, tool invocations, reasoning traces, and system events in a structured, extensible CDDL definition for verifiable agent conversation records. COSE is used as the signing method to allow for native interoperability in SCITT Transparency Services and the CDDL definition allows for seemless integration in Evidence as specified in RFC 9334. The specification supports cross-vendor interoperability by defining a common representation that accommodates translation from multiple existing agent implementations with distinct data structure layouts that are typically represented in JSON. | |||||||||||||
| draft-birrane-dtn-rel-02.txt | ||||||||||||||
| Reliability Considerations for Delay-Tolerant Networks | ||||||||||||||
|
The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. These unique and challenging characteristics require adapted approaches for data transport, security, management, routing, and other networking functions. Using new approaches, DTNs can offer data services in environments that would be considered neither reliable nor resilient as these concepts are understood for unchallenged networks. This document identifies adapted definitions and concepts for DTN reliability and resiliency that can be applied even when there is no simultaneous, reliable, end-to-end path between sources and destinations in the network. These definitions and concepts are suitable for any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP). The ability to overlay BP across multiple discontinuous underlay networks, to store- and-forward data where and as necessary, and the structure and security of the BPv7 bundle itself provide novel ways to identify, implement, signal, and otherwise consider guarantees associated with data exchange in the DTN environment. | |||||||||||||
| draft-blake-bmwg-agent-payment-measurement-00.txt | ||||||||||||||
| Out-of-Path Measurement Methodology for Agent-Initiated Payment Rails | ||||||||||||||
|
Agent-initiated payments now execute across several settlement rails with materially different finality semantics, authorization primitives and failure modes. Published comparisons of these rails are commonly self-asserted, and commonly do not state a procedure another party could reproduce. This document specifies a measurement methodology for such rails. It defines finality per rail at its ecosystem-canonical reliance level rather than imposing a single definition, separates payment-validation latency from challenge- issuance latency as distinct and non-comparable quantities, and specifies an out-of-path observation posture in which the measuring party never holds funds, keys or signing authority. It states reporting requirements, including mandatory disclosure of limitations and a prohibition on merging observer-clock and payer-clock measurements. It defines no payment protocol and recommends no rail. | |||||||||||||
| draft-bless-rtgwg-kira-05.txt | ||||||||||||||
| Kademlia-directed ID-based Routing Architecture (KIRA) | ||||||||||||||
|
This document describes the Kademlia-directed ID-based Routing Architecture KIRA. KIRA is a scalable zero-touch distributed routing solution that is tailored to control planes. It prioritizes scalable and resilient connectivity over route efficiency (stretched paths are acceptable vs. routing protocol overhead). KIRA's self-assigned topological independent IDs can be embedded into IPv6 addresses. Combined with further self-organization mechanisms from Kademlia, KIRA achieves a zero-touch solution that provides scalable IPv6 connectivity without requiring any manual configuration. For example, it can connect hundreds of thousands of routers and devices in a single network without requiring any form of hierarchy (like areas). It works well in various topologies and is loop-free even during convergence. This self-contained solution, and especially the independence from any manual configuration, make it suitable as resilient base for all management and control tasks, allowing to recover from the most complex failure scenarios. The architecture consists of the ID-based network layer routing protocol R²/Kad in its Routing Tier (using source routing) and a PathID-based Forwarding Tier (using PathIDs as labels for paths). KIRA’s tightly integrated add-on services (e.g., name resolution as well as fast and efficient topology discovery) provide a perfect basis for autonomic network management solutions. | |||||||||||||
| draft-bokovoy-kitten-pkinit-pqc-01.txt | ||||||||||||||
| Post-quantum Key Encapsulation with ML-KEM in Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) | ||||||||||||||
|
This document specifies extensions to the Kerberos PKINIT pre- authentication mechanism [RFC4556] [RFC8636] to support post-quantum key establishment using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) algorithms defined in [FIPS203]. The extensions define a new kemInfo arm in PA-PK-AS-REP, a KDCKEMInfo structure signed by the KDC, HKDF-based AS reply key derivation (HKDF-SHA-512 for ML-KEM), and downgrade-prevention rules. The KEM path framework supports multiple KEM algorithms including ML-KEM, composite ML-KEM algorithms, and future KEM standards. | |||||||||||||
| draft-bonica-6man-crh-helper-opt-07.txt | ||||||||||||||
| Compact Routing Header (CRH) Helper Option | ||||||||||||||
|
This document introduces a new IPv6 Destination Option called the CRH Helper. The CRH Helper is used with the Compact Routing Header (CRH) [RFC 9631]. It contains information required to convert a CRH SID to the IPv6 address of a interface on a packet's delivery path. Because the CRH Helper contains this information, it eliminates the need for a CRH-FIB. It also eliminates the need for CRH-FIB support in the control plane. The CRH helper is useful in underlay networks, where all interfaces are numbered from a few /112 or /96 prefixes. | |||||||||||||
| draft-bonica-tcpm-extended-options-05.txt | ||||||||||||||
| An Upgraded TCP Session Type | ||||||||||||||
|
Currently, TCP maintains ordinary sessions (SES-O) in which ordinary segments (SEG-O) are exchanged. Each SEG-O can accommodate up to 40 octets of options. In the future, applications may require more than 40 octets of options. For example, an application may use a 36-byte TCP Authentication Option (TCP-AO), leaving insufficient space for other required options. Therefore, this document describes an experiment in which upgraded sessions (SES-U) and upgraded segments (SEG-U) are introduced. Each SEG-U can accommodate up to 1,016 octets of Individual Options. | |||||||||||||
| draft-bonica-tcpm-tcp-ao-long-algs-06.txt | ||||||||||||||
| Cryptographic Algorithms That Produce 256-bit MACs For Use With TCP-AO | ||||||||||||||
|
RFC5926 creates a list of cryptographic algorithms that can be used with TCP-AO. This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256 and KMAC256. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 256-bit (i.e., 32-byte) MACs. When 32-byte MACs are encoded in TCP-AO, the TCP-AO consumes 36 of the 40 bytes available for TCP options. | |||||||||||||
| draft-boone-prompt-uri-scheme-01.txt | ||||||||||||||
| The 'prompt' URI Scheme for AI Agent Sessions and Prompts | ||||||||||||||
|
This document defines the prompt Uniform Resource Identifier (URI) scheme for identifying prompts within AI agent sessions. A prompt URI encodes the agent identity, session identifier, and a timestamp sufficient to locate the originating prompt within an agent session log. The scheme is intended for use in provenance records, audit trails, and cross-agent references where a human-readable, stable locator for a prompt interaction is required. This document also addresses the conditions under which multiple URIs MAY resolve to the same prompt and the conditions under which a single URI MAY be ambiguous with respect to the prompt it identifies. | |||||||||||||
| draft-bormann-asdf-sdf-compact-10.txt | ||||||||||||||
| Semantic Definition Format (SDF) for Data and Interactions of Things: Compact Notation | ||||||||||||||
|
The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) definitions. Tools convert this format to database formats and other serializations as needed. The SDF format is mainly intended for interchange between machine generation and machine processing. However, there is often a need for humans to look at and edit SDF models. Similar to the way Relax-NG as defined in ISO/IEC 19757-2 has an XML- based format and a compact format (its Annex C), this specification defines a compact format to go along SDF's JSON-based format. // The present version of this document is mostly a proof of concept; // it received positive initial feedback on the approach taken and is // awaiting completion of the initial implementation. | |||||||||||||
| draft-bormann-cbor-cddl-2-draft-09.txt | ||||||||||||||
| CDDL 2.0 and beyond -- a draft plan | ||||||||||||||
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610, RFC 9165, RFC 9682, and RFC 9741). RFC 9165 and the latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0"; it is intended to serve as a basis for implementations that evolve with the concept of CDDL 2.0. It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. This document is intended to evolve over time; it might spawn specific documents and then retire, or it might eventually be published as a roadmap document. | |||||||||||||
| draft-bormann-cbor-cddl-csv-09.txt | ||||||||||||||
| Using CDDL for CSVs | ||||||||||||||
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. | |||||||||||||
| draft-bormann-cbor-cddl-freezer-18.txt | ||||||||||||||
| A feature freezer for the Concise Data Definition Language (CDDL) | ||||||||||||||
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. | |||||||||||||
| draft-bormann-cbor-configuration-00.txt | ||||||||||||||
| CBOR Configuration | ||||||||||||||
|
This document discusses configuration of CBOR processors. Using this information as a basis, it provides WGLC feedback on draft-ietf-cbor- serialization-08. | |||||||||||||
| draft-bormann-cbor-draft-numbers-08.txt | ||||||||||||||
| Managing CBOR codepoints in Internet-Drafts | ||||||||||||||
|
CBOR-based protocols often make use of numbers allocated in a registry. During development of the protocols, those numbers may not yet be available. This impedes the generation of data models and examples that actually can be used by tools. This short draft proposes a common way to handle these situations, without any changes to existing tools. Also, in conjunction with the CDN prefix e (draft-ietf-cbor-edn-e-ref), a further reduction in editorial processing of CBOR examples around the time of approval can be achieved. | |||||||||||||
| draft-bormann-cbor-edn-app-ext-01.txt | ||||||||||||||
| Additional Application Extensions for the CBOR Extended Diagnostic Notation (EDN) | ||||||||||||||
|
The CBOR Extended Diagnostic Notation (EDN), to be standardized in draft-ietf-cbor-edn-literals, provides "application extensions" as its main language extension point. A number of application extensions are already defined in draft-ietf- cbor-edn-literals itself and in draft-ietf-cbor-edn-e-ref. The present document defines a number of additional application extensions that have been batched up as a next step after completing these specifications. ( // Chore: Briefly List extensions.) // This -01 of an individual submission is a slight update of -00, // which showed the approximate shape the first "batch" of // application extensions could have, plus a number of registrations // that could go into this batch. The latter provides a basis for a // technical discussion of those registrations. | |||||||||||||
| draft-bormann-cbor-edn-mapkey-02.txt | ||||||||||||||
| CBOR: Generating Numeric Map Labels from Textual EDN | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, STD 94 == RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. Complex examples often use nested maps, the map keys (labels) for each of which are often sourced from different specifications. While the e'' application extension provides a way to import data items, particularly constant values, from a CDDL model, it does not help with automatically selecting the right kind of map depending on its position in the nested maps. // The present document is intended to capture ideas initially // discussed at the CBOR WG interim 2025-06-25 and demonstrate some // design alternatives. It is not ready for adoption yet in any way. | |||||||||||||
| draft-bormann-cbor-notable-tags-17.txt | ||||||||||||||
| Notable CBOR Tags | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949's original edition, RFC 7049, defined a basic set of 16 tags as well as a registry that can be used to contribute additional tag definitions [IANA.cbor-tags]. Since RFC 7049 was published, at the time of writing some 250 definitions of tags and ranges of tags have been added to that registry. The present document provides a roadmap to a large subset of these tag definitions. Where applicable, it points to an IETF standards or standard development document that specifies the tag. Where no such document exists, the intention is to collect specification information from the sources of the registrations. After some more development, the present document is intended to be useful as a reference document for the IANA registrations of the CBOR tags the definitions of which have been collected. | |||||||||||||
| draft-bormann-cose-turbo-kanga-kmac-00.txt | ||||||||||||||
| COSE Algorithms for KangarooTwelve,TurboSHAKE and KMAC | ||||||||||||||
|
RFC 9861 defined and registered four eXtendable-Output Functions (XOFs), hash functions with output of arbitrary length, named TurboSHAKE128, TurboSHAKE256, KT128, and KT256; the present document is intended as the IETF consensus document that is now needed to give these algorithms Recommended status in the COSE registry. This document specifies concrete instances of those four functions above to be used as MACs in COSE. This document also specifies concrete instances of KMAC128 and KMAC256 in [NIST.SP.800-185] to be used as MACs in COSE and registers code points for them. And, this document provides "Recommended" status for those algorithms for COSE. | |||||||||||||
| draft-bormann-dispatch-modern-network-unicode-09.txt | ||||||||||||||
| Modern Network Unicode | ||||||||||||||
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. | |||||||||||||
| draft-bormann-jwp-modular-bbs-02.txt | ||||||||||||||
| BBS and Modular Sub-proofs with JSON Web Proofs | ||||||||||||||
|
This document defines a digital credential format that uses JSON Web Proofs (JWP) as its container format and Blind BBS Signatures as its signature scheme combined with a modular framework for attaching zero-knowledge sub-proofs. This allows a Holder to reveal some attributes directly while proving predicates such as range or equality over the ones they keep hidden. A credential can additionally be bound to an ECDSA P-256 device key, with possession of the key proven in every presentation without revealing the public key. The credential type definition and data model follow SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. | |||||||||||||
| draft-bormann-restatement-06.txt | ||||||||||||||
| The Restatement Anti-Pattern | ||||||||||||||
|
Normative documents that cite other normative documents often _restate_ normative content extracted out of the cited document in their own words. The present memo explains why this can be an Antipattern, and how it can be mitigated. | |||||||||||||
| draft-borthwick-msebenzi-environment-state-02.txt | ||||||||||||||
| Verifiable Intent -- environment.* Constraint Family | ||||||||||||||
|
Agent-authorization mandate formats authorise autonomous agents to act on behalf of human principals through cryptographically signed constraint instances bound into delegated mandates. Their existing constraint families describe properties of the transaction itself — what is being purchased, by whom, for how much, against which credential. They do not describe properties of the environment in which the transaction is executed: whether the venue is open, whether the source of funds is funded, whether other relevant external conditions hold at the moment of execution. This document specifies the environment.* constraint family for agent-authorization mandate vocabularies. It is defined against a host-binding profile (Section 1.3.1) that the Verifiable Intent (VI) mandate format satisfies and that other mandate formats may satisfy; VI is used throughout as the reference host. It defines the membership criterion under which a constraint type qualifies as a member of the family, the family-wide vocabulary every member uses, the composition discipline by which family members compose with each other and with constraints from other families, the register discipline under which family-wide and per-type prose is written, the family-wide security considerations, and the IANA registry mechanics under which new family members are registered. It does not define any individual constraint type. Two reference type specifications (environment.market_state and environment.wallet_state) are referenced informatively in Appendix A. | |||||||||||||
| draft-borthwick-wallet-state-attestation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-bortzmeyer-dnsop-poisonlicious-06.txt | ||||||||||||||
| Synchronizing caches of DNS resolvers | ||||||||||||||
|
Networks of cooperating and mutually trusting DNS resolvers could benefit from cache sharing, where one resolver would distribute the result of a resolution to other resolvers. This document standardizes a protocol to do so. | |||||||||||||
| draft-bouchez-scram-mcf-02.txt | ||||||||||||||
| SCRAM with Modular Crypt Format (SCRAM-MCF) | ||||||||||||||
|
This document specifies SCRAM-MCF, an extension to the Salted Challenge Response Authentication Mechanism (SCRAM) family of SASL mechanisms ([RFC5802]) and HTTP Digest extensions ([RFC7616], [RFC7677]). The extension replaces the PBKDF2-specific iteration count attributes i= and s= in the server-first-message with a generic Modular Crypt Format (MCF) descriptor f=. This allows servers to use modern memory- hard key derivation functions such as Argon2, SCrypt, or bcrypt while preserving the full security properties and message flow of SCRAM. The change is fully backward compatible: servers can continue sending i= and s= for legacy clients and only send f= (or both) when the client advertises support. This document is intended to be discussed and potentially adopted by the KITTEN working group. Feedback from the KITTEN WG is welcome on the [email protected] mailing list. | |||||||||||||
| draft-bourbaki-6man-classless-ipv6-14.txt | ||||||||||||||
| IPv6 is Classless | ||||||||||||||
|
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing. | |||||||||||||
| draft-bradleyb-audit-decision-records-00.txt | ||||||||||||||
| Signed Decision Records for Agent Authorization: Disclosures,Entry Emission,and Ordering Evidence | ||||||||||||||
|
Audit systems for autonomous agents commonly record the actions an agent performed. This makes the non-occurrence of a permitted action unrepresentable: when nothing happens, there is no action to emit anything. This document describes an evidence model that records the authorization decision rather than the action. A decision exists whether or not the action follows, so denials, expiries, and commitments that were granted and never honoured remain representable. The document defines four disclosures that make a decision record independently evaluable, an entry-emission rule for states a relying party may need to reason about, and the evidentiary basis for claims that a decision preceded its effect. It distinguishes correspondence, where two records agree about what happened, from precedence, where the order of decision and effect is established, and it requires records to state which of the two they carry. | |||||||||||||
| draft-bradleylundberg-cfrg-arkg-11.txt | ||||||||||||||
| The Asynchronous Remote Key Generation (ARKG) algorithm | ||||||||||||||
|
Asynchronous Remote Key Generation (ARKG) is an abstract algorithm that enables delegation of asymmetric public key generation without giving access to the corresponding private keys. This capability enables a variety of applications: a user agent can generate pseudonymous public keys to prevent tracking; a message sender can generate ephemeral recipient public keys to enhance forward secrecy; two paired authentication devices can each have their own private keys while each can register public keys on behalf of the other. This document provides three main contributions: a specification of the generic ARKG algorithm using abstract primitives; a set of formulae for instantiating the abstract primitives using concrete primitives; and an initial set of fully specified concrete ARKG instances. We expect that additional instances will be defined in the future. | |||||||||||||
| draft-braet-idr-bgp-source-selective-attr-00.txt | ||||||||||||||
| BGP Source-Selective Attribute | ||||||||||||||
|
This document specifies a new Border Gateway Protocol (BGP) Path Attribute, the BGP SOURCE_SELECTIVE Attribute. This attribute allows BGP speakers to reference Resource Public Key Infrastructure (RPKI) Source Authorization (SA) objects, including Source Prefix Authorization (SPA), within BGP UPDATE messages. These objects are created by prefix holders to define sources authorized to originate traffic toward their prefixes or subprefixes. Receiving BGP speakers can use this information to enforce security policies. The SOURCE_SELECTIVE Path Attribute supports multiple Source Authorization Identifier (SA-ID) fields to preserve authorization semantics during BGP route aggregation and summarization. This mechanism applies to BGP AFI 1 / SAFI 1 (IPv4 Unicast) and AFI 2 / SAFI 1 (IPv6 Unicast). | |||||||||||||
| draft-braet-idr-source-selective-bgp-framework-00.txt | ||||||||||||||
| Source-Selective BGP Framework | ||||||||||||||
|
The Border Gateway Protocol (BGP) routes traffic solely based on destination IP prefixes. Source Selective BGP (SSB) introduces an architecture combining BGP and Resource Public Key Infrastructure (RPKI) extensions, which allows prefix holders to cryptographically signal RPKI source authorization policies for their advertised reachability. SSB distributes references to these policies via a new BGP path attribute, allowing routing systems to incorporate source-based constraints into local forwarding policies. Crucially, SSB does not define a source address validation mechanism, mandate packet filtering behavior, or alter fundamental destination-based routing; interpretation remains a matter of local operator policy. This document provides the overall architectural context and deployment rationale for the SSB protocol suite. | |||||||||||||
| draft-braet-sidrops-spa-profile-00.txt | ||||||||||||||
| A Profile for Source Prefix Authorizations (SPAs) | ||||||||||||||
|
This document defines a standard profile for Source Prefix Authorizations (SPAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A SPA is a digitally signed object that allows the holder of an IP address prefix assigned by a Regional Internet Registry (RIR) to publish a list of source IP address prefixes authorized to send IP packets to that destination prefix or its subprefixes. To enforce these policies, a BGP speaker may include a SOURCE_SELECTIVE Path Attribute referencing the SPAs. This distributes policy references, enabling routing systems to incorporate source-based constraints into local forwarding policies and trigger control plane enforcement | |||||||||||||
| draft-brand-indicators-for-message-identification-14.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-brezun-human-continuity-http-00.txt | ||||||||||||||
| Human Continuity for HTTP | ||||||||||||||
|
This document defines an HTTP extension for origins that need to attribute repeated participation to the same verified unique human within a declared continuity scope, without requiring a global human identifier or replacing existing authentication. Within a continuity scope, the same human yields one verifier-local handle across all of their accounts, devices, and agents and cannot present as two, distinguishing the signal from authentication, which identifies a credential a human may hold many of. An origin server can publish policy for client-presented unique-human artifacts, issue an explicit challenge, and receive a client-presented artifact on a subsequent request. The framework is independent of any realm operator, credential technology, proof system, or definition of humanness. Companion profiles define artifact syntax, issuance, verification, challenge binding, replay behavior, holder binding, privacy properties, realm metadata, and verifier output. A conforming profile produces a verifier-local continuity_handle scoped to a realm, attestation audience, and purpose. This version defines no initial profile. | |||||||||||||
| draft-brooks-ztdnaid-new-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-brotman-aggregate-performance-reporting-01.txt | ||||||||||||||
| Aggregate Performance Reporting | ||||||||||||||
|
Definition of an aggregate performance report format for email messaging, the means to discover target destinations, and a specified delivery method. | |||||||||||||
| draft-brotman-drtls-00.txt | ||||||||||||||
| Domain-Required TLS | ||||||||||||||
|
A mechanism which allows a domain owner to declare their messages should only be accepted via sessions that employ STARTTLS, and otherwise, delivery options to be interpreted by the evaluating/ receiving system. | |||||||||||||
| draft-brotman-ietf-bimi-guidance-15.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-brown-davis-base64-sort-01.txt | ||||||||||||||
| A Sortable Base64 Alphabet | ||||||||||||||
|
This document details a formal specification for a new Base64 alphabet which follows the US-ASCII ordering and sorts the same as binary. This serves as an alternative variant to Base64 and Base64url when lexicographically sortable outputs are required. The alphabet re-uses the Base64url special characters and is designed to be compatible with existing Base64 implementations, while providing a new option for applications that require sorted output. | |||||||||||||
| draft-brown-epp-deleg-02.txt | ||||||||||||||
| Extensible Provisioning Protocol (EPP) mapping for DELEG records | ||||||||||||||
|
This document describes an extension to the Extensible Provisioning Protocol ([STD69]) which allows clients to provision DELEG records for domain names. About this draft This note is to be removed before publishing as an RFC. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-deleg-extension. | |||||||||||||
| draft-brown-epp-delegation-automation-extension-00.txt | ||||||||||||||
| Delegation Maintenance Automation Status Extension for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document specifies an extension to the Domain Mapping for the Extensible Provisioning Protocol (EPP) which allows EPP clients to enable and disable automatic delegation maintenance carried out by the server. It also describes how the maintenance automation state of a domain can be included in RDAP responses. The source for this draft, and an issue tracker, may can be found at https://github.com/gbxyz/epp-ds-automation-extension. | |||||||||||||
| draft-bruhns-securitytxt-product-security-00.txt | ||||||||||||||
| Product Security Fields for security.txt | ||||||||||||||
|
This document registers two new fields for the security.txt file format defined in RFC 9116: "Product-Security" and "Product-Security- Policy". They allow an organisation to publish a dedicated contact and disclosure policy for vulnerabilities in the products it manufactures, distinct from the contact for vulnerabilities in its own web presence and infrastructure. The fields are optional and fully backward compatible with existing security.txt parsers. | |||||||||||||
| draft-bruynooghe-n0-quic-nat-traversal-00.txt | ||||||||||||||
| n0 QUIC NAT Traversal | ||||||||||||||
|
A description of how noq (https://github.com/n0-computer/noq) performs NAT traversal for iroh (https://github.com/n0-computer/ iroh), including all current bugs. This is not yet a specification, though further revisions migth be. | |||||||||||||
| draft-bryce-cose-receipts-mmr-profile-02.txt | ||||||||||||||
| COSE Receipts for MMRs | ||||||||||||||
|
This document defines a new verifiable data structure type for COSE Receipts [I-D.ietf-cose-merkle-tree-proofs] specifically for use with ledgers based on post-order traversal binary Merkle trees and which are designed for high throughput, ease of replication and compatibility with commodity cloud storage. Post-order traversal binary Merkle trees, also known as history trees, are more commonly known as Merkle Mountain Ranges. | |||||||||||||
| draft-bu-agentproto-security-principal-binding-07.txt | ||||||||||||||
| Security Principal and Verifier Binding for Agent Communication Protocols | ||||||||||||||
|
Agent communication protocols often carry claims about user authority, agent instance identity, tool or external-resource identity, delegation state, session continuity, and action evidence. These claims have different verifiers, freshness requirements, failure modes, and security consequences. If they are collapsed into a single token, identity label, session identifier, or audit record, protocol text can accidentally imply more authority or accountability than the receiver can actually verify. This document defines a verifier-facing model for separating those claims. It provides a reusable matrix format that protocol authors can use to state, for each security-relevant claim, which field carries it, which party verifies it, what binding or freshness rule applies, what failure behavior is required when the claim is absent, stale, inconsistent, or not verifiable, and what constrained result an application may consume after successful verification. It also separates specification status, implementation status, and evidence type so that reviewers can distinguish current protocol text, implementation evidence, inherited mechanisms, and architectural assumptions. The document is protocol-neutral. It is intended to help compare candidate agent communication drafts and to provide security-considerations and requirements text for agent session and delegation binding. The document also defines row-outcome semantics and dependency- closure rules for composed mappings. These rules prevent a composite result from becoming stronger than its verified inputs, distinguish failed checks, unsupported verifier capabilities, checks skipped after a failed prerequisite, and unavailable or ambiguous inputs, propagate transitive dependency failures, and make cyclic, stale, downgraded, or revision-incoherent dependencies visible to reviewers. | |||||||||||||
| draft-bubblefish-naalp-01.txt | ||||||||||||||
| N-AALP: The Native Agentic Application Layer Protocol | ||||||||||||||
|
The Native Agentic Application Layer Protocol (N-AALP) is an application-layer object protocol for autonomous software agents. Every N-AALP object is a deterministically encoded CBOR structure signed with COSE, carrying under one signature its content identity, its originating signer, a closed effect label that is an authorization input rather than a hint, optional approval and audit bindings, and its causal derivation. Objects are transport- independent: the identical signed object is carried, with identical object-level guarantees, over the N-PAMP substrate, QUIC, WebSocket, or HTTP. N-AALP defines a frozen envelope, a post-quantum signature profile (pure ML-DSA by default, with an optional Ed25519+ML-DSA composite), a self-certifying identity with key rotation, a single- use approval ledger, a hash-chained audit and causal- ordering model with a federated higher tier, native streaming with a single per- stream commitment, foreign-protocol carriage by class, and twenty tiered channel surfaces. This document is an Independent Submission and does not represent IETF consensus. | |||||||||||||
| draft-bubblefish-npamp-02.txt | ||||||||||||||
| N-PAMP: Native Post-Quantum Agent Messaging Protocol | ||||||||||||||
|
The Native Post-Quantum Agent Messaging Protocol (N-PAMP) is a binary, multi-channel, wire-level protocol for authenticated communication between autonomous software agents. N-PAMP operates beneath application-layer agent protocols and provides a single fixed-size frame format, a registry of multiplexed channels, and three escalating security profiles (Standard, High, and Sovereign) built on standard post-quantum and classical cryptography. The protocol uses a hybrid key-encapsulation mechanism combining X25519 with ML-KEM, authenticated encryption with associated data, and a forward-secure key schedule. N-PAMP runs over QUIC as its primary transport and over TCP with TLS 1.3 as a fallback, negotiated via the Application-Layer Protocol Negotiation (ALPN) identifier "n-pamp/3". This document describes the wire format, channel architecture, profile negotiation, and cryptographic suites of N-PAMP, and reserves code-point ranges for extensions defined in companion specifications. | |||||||||||||
| draft-buckeyne-jsox-format-01.txt | ||||||||||||||
| The JavaScript Object eXchange (JSOX) Data Interchange Format | ||||||||||||||
|
JavaScript Object eXchange (JSOX) is a lightweight, text-based, language-independent data interchange format. It is derived from JSON and from the object literal syntax of the ECMAScript Programming Language Standard. Every well-formed JSON text is a well-formed JSOX text. JSOX extends JSON with unquoted identifiers, additional string quoting and escape forms, comments, additional number forms including dates and arbitrary-precision integers, binary typed arrays, user- defined types carried by a type tag, field-name macros that remove repeated keys from a document, and references that permit shared and cyclic structures to be encoded. This document defines the JSOX grammar and registers the media type "application/jsox". | |||||||||||||
| draft-burls-mtac-00.txt | ||||||||||||||
| Merkle Tree Agent Certificates (MTAC): Batch-Issued Post-Quantum Identity Credentials for AI Agents | ||||||||||||||
|
This document specifies Merkle Tree Agent Certificates (MTAC), a credential format and issuance profile in which a certificate authority commits a batch of AI agent identity credentials to a Merkle tree, signs only the tree head with the post-quantum signature algorithm ML-DSA-65, and distributes a per-credential inclusion proof. A relying party verifies a credential offline against the signed tree head without contacting the issuer. Each batch root is additionally co-signed by an independently keyed witness, providing per-batch integrity and continuity attestation, and its root can be corroborated against an independent public record. MTAC defines the leaf structure, its deterministic encoding, the leaf hash preimage, the signed tree head wire format, the witness co- signature, and an optional challenge-response proof of possession that binds a credential to a holder key. Test vectors are provided. This document specifies a credential issuance and verification mechanism. Declared scopes carried in a credential are self-reported parameters recorded at issuance; this document does not specify a runtime authorization mechanism. | |||||||||||||
| draft-busi-nmop-simap-rfc8795-applicability-02.txt | ||||||||||||||
| Applicability of RFC8795 YANG data model to SIMAP | ||||||||||||||
|
This document analyses the applicability of the RFC 8795 YANG data model to Service & Infrastructure Maps (SIMAP) and in particular analysis which requirements can be supported by the existing YANG data model defined in RFC 8795. | |||||||||||||
| draft-busi-nmop-transport-simap-02.txt | ||||||||||||||
| Applicability of Service & Infrastructure Maps (SIMAP) to Transport Networks | ||||||||||||||
|
This document explores the applicability of the Service & Infrastructure Maps (SIMAP) concepts to transport networks and it examines the YANG data models defined by the IETF to support the requirements and use cases for SIMAP applicability to transport networks. | |||||||||||||
| draft-bustamante-iotmp-00.txt | ||||||||||||||
| Internet of Things Message Protocol (IOTMP) | ||||||||||||||
|
IOTMP (Internet of Things Message Protocol) is a compact, binary, application-layer protocol for bidirectional communication between IoT devices and servers over persistent connections. It provides a resource-oriented model with native support for remote procedure calls, real-time data streaming, and API introspection. IOTMP uses PSON (Packed Sensor Object Notation) as its data encoding format, achieving significantly lower wire overhead than text-based alternatives. The protocol is designed for constrained devices with limited memory and bandwidth, while remaining expressive enough for complex IoT applications. IOTMP operates over TCP, TLS, or WebSocket transports and supports symmetric operation where both clients and servers may expose and invoke resources. | |||||||||||||
| draft-bustamante-pson-00.txt | ||||||||||||||
| Packed Sensor Object Notation (PSON) | ||||||||||||||
|
PSON (Packed Sensor Object Notation) is a compact binary data encoding format designed for IoT environments where bandwidth, memory, and processing power are constrained. PSON efficiently represents the data types commonly found in sensor telemetry and device interaction: integers, floating-point numbers, booleans, strings, binary blobs, arrays, and key-value maps. It achieves significant size reductions over JSON (40-75% for typical IoT payloads) through inline small value encoding and variable-length integers. PSON is self-describing (no external schema required for decoding) and designed for minimal implementation complexity on microcontrollers. | |||||||||||||
| draft-bzb-rats-intel-poe-endorsements-01.txt | ||||||||||||||
| A CoRIM Profile for Intel Platform Ownership Endorsements (POE) | ||||||||||||||
|
A Platform Ownership Endorsement (POE) is a signed statement that a specific Intel confidential-computing platform instance, identified by its Platform Instance Identity (PIID), belongs to a named owner. POEs let a Verifier bind the attested hardware identity from an Intel SGX or TDX platform to an operational owner (e.g., a Cloud Service Provider) during appraisal, giving a Relying Party a trustworthy owner identity -- without trusting the attestation service or any in- band claim from the platform itself. This document defines POE as a profile of the IETF Concise Reference Integrity Manifest (CoRIM) data model. | |||||||||||||
| draft-c4tz-marc-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-caballero-cbor-cbor42-02.txt | ||||||||||||||
| The tag-42 profile of CBOR | ||||||||||||||
|
This document defines a bespoke serialization of CBOR intended for use with the special tag 42 in various end-to-end protocols that came out of the IPFS community. Much of its design dates to the first CBOR RFC and predates much of the terminology and the layered approach to determinism elaborated in later years. CBOR-42 can be used as an internet-scale serialization for JSON, and is optimized for objects that compose into a directed acyclical graph. Since CBOR-42 objects link to one another by hash-based identifiers tagged "42", deterministic encoding is mandated to verify dereferenced links and encode new ones. | |||||||||||||
| draft-cabanillas-nmop-authz-policy-sharing-model-03.txt | ||||||||||||||
| Model for distributed authorization policy sharing | ||||||||||||||
|
This document defines mechanisms and conventions for the representation, lifecycle management, and distribution of authorization policies in distributed and automated environments. It specifies a consistent, machine-readable, and interoperable framework that enables policies to be validated, exchanged, and removed across heterogeneous systems and areas. The framework defines how authorization policies, expressed in declarative Policy-as-Code (PaC) languages, are encapsulated, managed, and distributed using YANG as the canonical representation format. This separation allows independent evolution of policy languages, enforcement architectures, and trust models. The model also defines extensible Policy-as-Code language identities using YANG identity and identityref mechanisms, enabling future policy languages to be incorporated without modifying the core schema. | |||||||||||||
| draft-cacciapuoti-qirg-quantum-native-architecture-01.txt | ||||||||||||||
| Quantum-Native Architectural Tenets and Philosophy for the Quantum Internet | ||||||||||||||
|
This document extends RFC 9340 by outlining a set of quantum-native architectural tenets for the design and evolution of the Quantum Internet. These principles should not be interpreted as dogmas, but as pragmatic guidelines and criteria for harnessing the unique properties of quantum entanglement within networked systems. Such design perspectives, while departing from the classical Internet, remain aligned with a foundational insight: the principle of constant change, articulated in RFC 1958. The document specifies quantum-native extensions to the Quantum Internet framework, defining an entanglement packet switching paradigm and an explicit separation between the Quantum Data Plane and Quantum Control Plane. It introduces Quantum Internet Addressing to extend quantum semantics into control and coordination, and generalizes the classical forwarding concept to quantum packets. | |||||||||||||
| draft-caini-dtn-quiccl-01.txt | ||||||||||||||
| Delay-Tolerant Networking QUIC Convergence Layer Protocol Version 1 | ||||||||||||||
|
This document describes a QUIC convergence layer (QUICCL) for Delay- Tolerant Networking (DTN). QUICCL uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and makes use of either QUIC streams (RFC 9001) or QUIC datagrams (RFC 9221) to transport such bundles. QUICCL design is largely based on TCPCLv4 specification (RFC9174), with three significant differences. First, as QUIC incorporates TLS security, all security related parts of TCPCLv4 were dropped. Second, QUICCL provides two new transport services, notified and unreliable, in addition to the reliable service; Third, in the reliable service, by taking advantage of QUIC streams, four levels of priority are offered. | |||||||||||||
| draft-calabria-bmwg-ai-fabric-inference-bench-04.txt | ||||||||||||||
| Benchmarking Methodology for AI Inference Serving Network Fabrics | ||||||||||||||
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI inference serving network fabrics. As Large Language Model (LLM) inference deployments scale to disaggregated prefill/decode architectures spanning hundreds or thousands of accelerators (GPUs/ XPUs), the interconnect fabric determines Time to First Token (TTFT), Inter-Token Latency (ITL), and aggregate throughput in tokens per second (TPS). This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI inference workloads. Coverage includes RDMA-based KV cache transfer between disaggregated prefill and decode workers, Mixture-of-Experts (MoE) expert parallelism AllToAll communication, request routing and load balancing for inference serving, congestion management under bursty inference traffic patterns, and scale/soak testing. The methodology enables direct comparison across NIC transport stacks (RoCEv2 and UET) and fabric architectures. This document is a companion to the AI training fabric benchmarking methodology, which addresses training workloads. | |||||||||||||
| draft-calabria-bmwg-ai-fabric-terminology-04.txt | ||||||||||||||
| Benchmarking Terminology for AI Network Fabrics | ||||||||||||||
|
This document defines benchmarking terminology for evaluating Ethernet-based network fabrics used in distributed Artificial Intelligence (AI) training and inference workloads. It consolidates and extends terms from "Benchmarking Terminology for Network Interconnect Devices" (RFC 1242) and "Data Center Benchmarking Terminology" (RFC 8238). Definitions cover collective communication primitives, RDMA transport mechanisms (RoCEv2 and Ultra Ethernet Transport), congestion control behaviors, AI-specific Key Performance Indicators (KPIs), and fabric topology concepts. This document is a companion to the AI training and inference fabric benchmarking methodology documents. Those documents are intended to be read together with the terminology defined here. Where definitions herein overlap with the foundational benchmarking terminology in RFC 1242 or RFC 8238, this document provides AI fabric context extensions and refinements; the foundational definitions in those RFCs remain authoritative for general network benchmarking. | |||||||||||||
| draft-calabria-bmwg-ai-fabric-training-bench-04.txt | ||||||||||||||
| Benchmarking Methodology for AI Training Network Fabrics | ||||||||||||||
|
This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI training network fabrics. As large-scale distributed Artificial Intelligence / Machine Learning (AI/ML) training clusters grow to tens of thousands of accelerators (GPUs or generic accelerator processing units (XPUs)), the backend network fabric determines Job Completion Time (JCT), training throughput, and accelerator utilization. This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI training workloads. The tests cover Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) transport, the Ultra Ethernet Transport (UET) protocol defined by the Ultra Ethernet Consortium (UEC) Specification 1.0, congestion management (Priority Flow Control (PFC), Explicit Congestion Notification (ECN), Data Center Quantized Congestion Notification (DCQCN), Credit-Based Flow Control (CBFC)), load balancing strategies (Equal-Cost Multi-Path (ECMP), Dynamic Load Balancing (DLB), packet spraying), collective communication patterns (AllReduce, AllToAll, AllGather), and scale/ soak testing. The methodology enables direct, reproducible comparison across switch ASICs, NIC transport stacks (RoCEv2 and UET), and fabric architectures (2-tier Clos, 3-tier Clos, and rail-optimized). | |||||||||||||
| draft-callec-api-advisory-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-callec-dive-02.txt | ||||||||||||||
| Domain-based Integrity Verification Enforcement (DIVE) Version 0.1 | ||||||||||||||
|
Domain-based Integrity Verification Enforcement (DIVE) is an application-layer protocol that provides cryptographic integrity and authenticity verification of HTTP response bodies by leveraging the Domain Name System Security Extensions (DNSSEC) as an out-of-band distribution channel for public keys. DIVE is designed for non-browser automated clients operating in controlled infrastructure: software update agents, package managers, and IoT device fleets. It is specifically suited to the distribution of static, pre-signable content (firmware images, packages, and versioned binary artifacts), where signatures can be computed offline and injected at deployment time. DIVE has two independent components: (1) an object-security layer, which uses HTTP Message Signatures (RFC 9421) to carry per-resource signatures in HTTP response headers, and (2) a DNS key-distribution layer, which publishes public keys and policy in DNSSEC-protected TXT records. A client implementing DIVE verifies each covered resource against the corresponding DNS-published public key before accepting it. An attacker must therefore compromise both the DNS infrastructure and the origin server simultaneously to deliver a tampered resource to a DIVE-compliant client. | |||||||||||||
| draft-campbell-agentic-market-00.txt | ||||||||||||||
| Agentic Hypercall Protocol (AHP): Tool Invocation,Blind Settlement,and Portable Reputation over HTTP | ||||||||||||||
|
This document specifies the Agentic Hypercall Protocol (AHP), a minimal convention for automated software agents to discover, invoke, pay for, and rate tools over plain HTTP. It replaces draft-campbell- agentic-http-00 and extends it in three directions. First, it formalizes the HTTP 402 (Payment Required) status code as a native economic layer with pluggable payment rails (Lightning L402, Cashu ecash, and prepaid balances). Second, it specifies a blind relay -- the Gateway -- through which a consumer and a provider can transact end-to-end encrypted: the relay verifies identity, settles payment, and forwards sealed payloads it cannot read. Third, it specifies signed receipts, settlements, and rating attestations that let reputation be weighted by money actually settled rather than by tokens or votes, and that ride with a provider's key rather than with any single relay. The result is an open market in which agents can buy compute, information, and services from one another without an SDK, a walled garden, or a native token. | |||||||||||||
| draft-campling-ech-deployment-considerations-12.txt | ||||||||||||||
| Encrypted Client Hello Deployment Considerations | ||||||||||||||
|
This document discusses operational and policy considerations related to the deployment of TLS Encrypted Client Hello (ECH). It describes the impact of encrypting the TLS Server Name Indication (SNI) on operational practices such as threat detection, network security controls, and content filtering in private, edge, and public network environments, with a particular focus on education, enterprise, and public operator use cases. | |||||||||||||
| draft-campling-parcep-sync-00.txt | ||||||||||||||
| PARCEP Protocol and Architecture for Networked Parental Controls | ||||||||||||||
|
PARCEP-Sync specifies a federated synchronization protocol and data model for guardian-controlled Child Online Protection, enabling household policies to be authored at a Policy Administration Point (PAP), distributed over a per-household Messaging Layer Security (MLS) group to Policy Enforcement Points (PEPs), and enforced using credentials and artifacts issued by jurisdictional Policy Information Points (PIPs). The protocol defines a small, regular set of methods for enrolment, policy publication and update, revocation, enforcement telemetry, digests, appeals, attestation, and artifact fetch, with dua l JSON-LD and CBOR/COSE encodings for web-scale and constrained environments. It is designed to avoid centralized databases of children s data, support cross-jurisdictional verification of guardianship and age, and provide privacy-preserving, metadata-only event reporting suitable for regulatory audit and appeal. | |||||||||||||
| draft-cao-savnet-ipfix-sav-00.txt | ||||||||||||||
| Export of Source Address Validation (SAV) Information in IPFIX | ||||||||||||||
|
This document specifies the IP Flow Information Export Information Elements to export the context and outcome of Source Address Validation enforcement data. These SAV-specific Information Elements provide detailed insight into why packets are identified as spoofed by capturing the specific SAV rules that triggered validation decisions. This operational visibility is essential for network operators to observe SAV enforcement behavior and analyze source address spoofing events detected by SAV. | |||||||||||||
| draft-capobianco-ncfed-00.txt | ||||||||||||||
| The NetClaw-to-NetClaw Federation Protocol (NCFED) | ||||||||||||||
|
This document specifies the NetClaw-to-NetClaw Federation Protocol (NCFED), an implementation-agnostic application-layer protocol that lets independently operated, heterogeneous AI network-engineering agents ("NCFED peers", or "claws") discover one another's capabilities, invoke remote tools, and delegate tasks over long-lived TCP sessions. Although named for its reference instantiation, NCFED is a wire specification, not an SDK, and federates arbitrary autonomous agent architectures across distinct administrative boundaries; a peer needs no knowledge of its counterparty's internal reasoning framework, prompt structure, or execution runtime. NCFED multiplexes its federation channel with BGP-4 and an associated tunneling data plane on a single listening port, using first-octet protocol discrimination. Its payload is JSON-RPC 2.0, onto which Model Context Protocol (MCP) tool-invocation semantics and Agent2Agent (A2A) task-delegation semantics are mapped. Federation between different trust domains (eN2N) requires mutual operator consent; within a single operator's trust domain (iN2N) it is hub- and-spoke, bootstrapped by an enrollment token. For eN2N, the channel is encrypted with TLS 1.3 and each peer is cryptographically authenticated by proof of possession of the credential bound to its identity, under either a domain-verified (publicly certified) or a pinned (trust-on-first-use) model. For iN2N, members and the Border mutually authenticate at the application layer with pinned credentials and a hub attestation, and TLS may additionally protect the transport. NCFED does not replace MCP or A2A; it is a cross- operator federation, identity, and transport layer beneath them. This document describes the protocol as implemented in the open- source NetClaw project and is published as Experimental to enable interoperability and public review. | |||||||||||||
| draft-car-agents-txt-wellknown-00.txt | ||||||||||||||
| AGENTS.TXT: Capability Declarations for Web Agents | ||||||||||||||
|
This document requests registration of two Well-Known URIs under the "/.well-known/" path: "agents.txt" and "agents.json". These URIs define a machine-readable capability declaration format: a positive statement of what web agents CAN do on a site -- which endpoints are sanctioned for agent use, which protocols (REST, MCP, A2A, GraphQL, WebSocket) are supported, what authentication mechanisms are expected, and what rate limits the site advertises. This is distinct from "robots.txt", which uses a restriction syntax to declare what crawlers may not do. Where "robots.txt" expresses prohibition, "agents.txt" expresses capability -- a sanctioned channel for agent interaction that is otherwise routinely blocked by bot detection, CAPTCHAs, and rate limiters because no positive declaration surface exists. | |||||||||||||
| draft-car-ai-txt-wellknown-00.txt | ||||||||||||||
| AI.TXT: A Declaration File for AI Usage Preferences,Licensing,and Policy | ||||||||||||||
|
This document requests registration of two Well-Known URIs under the "/.well-known/" path: "ai.txt" and "ai.json". These URIs define a structured, machine-readable file in which a site operator can declare AI usage preferences (training, scraping, indexing, caching), licensing terms, required attribution, and per-agent rules. "ai.txt" is positioned as a structured attachment surface for AI usage preferences in addition to robots.txt and HTTP-header carriage proposed by the IETF AIPREF working group. As the AIPREF vocabulary stabilizes, "ai.txt" can carry those preferences in a typed, single- file form alongside the broader licensing, attribution, and policy declarations defined in this document. This format is complementary to "robots.txt" [ROBOTS]. Where "robots.txt" can block crawling entirely, "ai.txt" expresses nuanced policies such as "you may crawl but not train on this content" -- a distinction that "robots.txt" alone cannot express. | |||||||||||||
| draft-car-rer-artifact-01.txt | ||||||||||||||
| RER Run Artifact Format: Hash-Chained,Signed Records of AI Inference Execution | ||||||||||||||
|
This document specifies the Run Envelope Runtime (RER) artifact format: a hash-chained, Ed25519-signed JSON record of a single AI inference run. An RER artifact carries (1) a signed envelope declaring the permissions and limits under which the run was authorized, (2) a hash-chained event log covering every model call, tool call, and policy decision made during execution, and (3) a runtime signature binding the envelope hash and event log head to the runtime implementation that produced the record. The artifact is designed for offline verification by parties who did not participate in the run. A separate verifier package, with a minimal dependency surface (canonicalization, SHA-256, Ed25519, JSON schema validation), can establish the artifact's structural and cryptographic integrity without any of the code that produced it. After sealing, the integrity of the record does not depend on trust in the operator. This document complements the declaration-side agents.txt and ai.txt well-known URI proposals (both filed, under review at the IANA Well- Known URIs registry). Declaration says what an agent was permitted to do. An RER artifact records what the runtime attested actually happened. The two surfaces together cover the before-and-after of an agent interaction. Two on-the-wire schema versions are defined here: rer-artifact/0.1 and rer-artifact/0.2. Version 0.2 adds a bundle format, manifest binding, and approval-protocol metadata while preserving the verification semantics of 0.1. | |||||||||||||
| draft-cardona-claise-netmod-yang-coverage-00.txt | ||||||||||||||
| Guidelines for YANG Example Validation and Coverage Analysis in IETF Documents | ||||||||||||||
|
This document defines guidelines for including YANG example instances in IETF documents in a way that enables automatic extraction and validation. It introduces the concept of YANG module "coverage" to measure how thoroughly example instances exercise a YANG module's data nodes. By standardizing how YANG examples are included, validated, and measured for coverage, these guidelines help authors catch errors before publication and give reviewers and implementers greater confidence that the examples in a specification are correct and cover a sufficient range of scenarios - ultimately making the underlying data models easier to implement and use. | |||||||||||||
| draft-carleton-workload-authz-grant-00.txt | ||||||||||||||
| Workload Authorization Grant | ||||||||||||||
|
This document profiles the Agent Identity Management System (AIMS) framework for agent platforms that host many agent instances per customer. Each agent is identified by an opaque, non-reassignable agent identifier; the agent obtains access tokens by presenting a JWT authorization grant (RFC 7523), signed by the platform's per-tenancy issuer, in the assertion parameter at the authorization server protecting the resource server. Trust is established once, by reference to the issuer's published metadata and keys; agent creation requires no per-agent step at the authorization server or resource server; and authorization is expressed over platform-asserted agent properties that resource servers map locally to permissions. This profile addresses agents acting on their own behalf; access on behalf of a user or other principal is out of scope, though the design is intended to compose with existing delegation mechanisms in which the agent appears as the actor. | |||||||||||||
| draft-carpenter-anima-grasp-rendezvous-01.txt | ||||||||||||||
| Using GRASP as an Agent Rendezvous Mechanism | ||||||||||||||
|
This document describes how the GeneRic Autonomic Signaling Protocol (GRASP) defined by RFC 8990 may be used as a rendezvous mechanism for one Autonomic Service Agent to find another, and then to establish a generic communication channel between them. Such a channel could be used for any form of agent-to-agent communication, not limited to GRASP exchanges. This document updates RFC 8990 by adding a transport identifier registry. | |||||||||||||
| draft-carpenter-anima-otp-casa-02.txt | ||||||||||||||
| One-time Pad for Authorizing Device Identity | ||||||||||||||
|
This document describes how devices joining an autonomic control plane as defined in RFC 8994 may use the BRSKI onboarding mechanism defined in RFC 8995, even if they cannot provide a manufacturer- installed X.509 IDevID certificate. Instead, such devices may generate a self-signed certificate embedding a unique token selected from a one-time pad. | |||||||||||||
| draft-carpenter-anima-quads-grasp-04.txt | ||||||||||||||
| Quick and Dirty Secure Autonomic Control Plane for GRASP | ||||||||||||||
|
A secure substrate known as the Autonomic Control Plane (ACP) is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Secure ACP using symmetric cryptography and preconfigured key material. It also describes a secure mechanism for providing the prefconfigured key material to enrolled ACP nodes via EST. | |||||||||||||
| draft-carpenter-gendispatch-anachronisms-07.txt | ||||||||||||||
| Some Anachronisms and Gaps in IETF Standards Process Documents | ||||||||||||||
|
This document discusses some aspects of documents describing the IETF standards process that have been overtaken by events, as well as identifying some gaps. It covers the six-month expiry of Internet- Drafts, the reality of the two-stage standards process, and various other issues. This draft is posted only to open a discussion. | |||||||||||||
| draft-carpenter-rswg-authoring-ethics-06.txt | ||||||||||||||
| Principles and Guidelines for Assignment of RFC Authorship | ||||||||||||||
|
This document discusses principles and guidelines for assigning authorship in RFC documents, including guidelines for the use of software tools during document preparation, and for inclusion of material from other sourcess. An important focus is on authors' responsibility for the content. The document also discusses the related issues of acknowledgements, editors and contributors. The various RFC streams are expected to apply these guidelines, and possibly define their own variations, which will have priority. | |||||||||||||
| draft-carr-sygil-protocol-00.txt | ||||||||||||||
| The Sygil Protocol: A Cross-Domain Personal Data Schema and Query Grammar for AI Agents | ||||||||||||||
|
This document specifies the Sygil Protocol, an open schema and query grammar for cross-domain personal data designed to make user data interoperable across systems, vendors, and AI agents. The protocol defines a content-addressable record envelope, a reverse-DNS namespace identifier scheme, a deterministic JSON canonicalization rule, an optional vocabulary of proof objects for conveying provenance and other trust evidence on the wire, a minimal query grammar, and three adoption tiers from envelope-shaped data through queryable surfaces to vault-certified runtimes. The protocol is runtime-neutral: it specifies what travels on the wire, not how implementations store, encrypt, authorize, or audit records. This separation lets independent systems produce, consume, and exchange Sygil-shaped data without depending on any specific vault infrastructure. | |||||||||||||
| draft-cassandres-hacp-agency-arch-00.txt | ||||||||||||||
| Human Agency Continuity Protocol (HACP) Architecture | ||||||||||||||
|
This document describes the architecture of the Human Agency Continuity Protocol (HACP): a pre-execution authorization contract for tool-using agents. HACP separates human intent, deterministic evaluation, cryptographic decision binding, and enforcement so that an agent cannot silently reinterpret authorized action after a decision is issued. This document is Informational. It is not an Internet Standard. It does not activate Enforcement revision 2 and does not claim general URI-normalization conformance. The acronym HACP in this series means Human Agency Continuity Protocol. A separately posted individual Internet-Draft, draft- sunyi-hacp-protocol, uses the same four letters for a different protocol (Hardware Agent Capability Protocol) by a different author. The present author has no affiliation with that document. | |||||||||||||
| draft-cassandres-hacp-agency-core-00.txt | ||||||||||||||
| Human Agency Continuity Protocol (HACP) Core | ||||||||||||||
|
This document specifies the HACP-Core decision contract: IntentEnvelope, ProposedAction, AgencyDecision, DecisionToken, provenance events, revocation, and the ordered evaluate() algorithm. Implementations MUST fail closed. Decisions MUST be deterministic and MUST NOT require a language model on the evaluation path. The published executable baseline is the 38-vector HACP-Core v0.9.2 suite. Wire object field hacp_version remains "0.9". Specification release 1.0.0 does not change that field. | |||||||||||||
| draft-cassen-vrrp-auth-hmac-01.txt | ||||||||||||||
| An HMAC Authentication Extension for the Virtual Router Redundancy Protocol (VRRP) | ||||||||||||||
|
VRRP relies on a hop limit of 255 to prove that an advertisement came from the local link. That guard cannot apply when advertisements travel as multi-hop unicast across a routed or overlay network, as is common in cloud deployments, leaving the protocol open to off-segment injection and replay. The legacy VRRPv2 authentication types do not close this gap and were removed from later VRRP specifications. This document defines an authentication extension that appends an HMAC- SHA256 trailer and a time-based sequence number to VRRPv3 advertisements, authenticating the sender as a holder of the group key, protecting message integrity and bounding replay, for both IP address families. The extension is the primary defense where the hop-limit check cannot apply, and defense in depth for multicast and single-hop unicast, where that check remains in force. | |||||||||||||
| draft-cds-rats-intel-corim-profile-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cel-nfsv4-copy-implementation-experience-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cel-nfsv4-rpc-over-quicv1-06.txt | ||||||||||||||
| Remote Procedure Call over QUIC Version 1 | ||||||||||||||
|
This document specifies a protocol for conveying Remote Procedure (RPC) messages via QUIC version 1 connections. It requires no revision to application RPC protocols or the RPC protocol itself. | |||||||||||||
| draft-cel-nfsv4-rpc-tls-dane-00.txt | ||||||||||||||
| Using RPC-with-TLS with DNS-Based Authentication of Named Entities | ||||||||||||||
|
RPC-with-TLS assumes that DNS-Based Authentication of Named Entities (DANE) is available on platforms where it is deployed, and recommends that a client operating under an opportunistic security policy check for a TLSA record before initiating an association, but does not say how. This document specifies the missing details, so that a TLSA record authenticates an RPC server with no certification authority trust anchor provisioned on the client. It updates RFC 9289. | |||||||||||||
| draft-cel-nfsv4-rpc-tls-othername-04.txt | ||||||||||||||
| Remote Procedure Call Identity Squashing via x.509 Certificate Fields | ||||||||||||||
|
This document extends RPC-with-TLS so that a client's x.509 certificate may carry instructions to the RPC server to execute all RPC transactions from that client as a single user identity. | |||||||||||||
| draft-celi-wiggers-tls-authkem-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cgfabk-nmrg-ibn-generative-ai-02.txt | ||||||||||||||
| Generative AI for Intent-Based Networking | ||||||||||||||
|
This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking. | |||||||||||||
| draft-chandra-agent-registry-corroboration-01.txt | ||||||||||||||
| Multi-Source Corroboration for AI Agent Discovery | ||||||||||||||
|
AI agents are discovered and identified through independent sources, including registries, name services, DID methods, and catalogs. A single source can misrepresent an agent by omission, withholding a record it holds, or by equivocation, serving different answers to different observers. A signature on a served artifact does not, by itself, defend against either behavior. This document specifies a corroboration procedure that classifies one source's claim about one agent observed from one network vantage; reduces claims to comparable views; diffs claims into findings with deterministic attribution; distinguishes legitimate propagation delay from persistent disagreement; and emits a signed Corroboration Record for every sweep, including agreement, that other evidence formats can bind by digest. The procedure is source-, format-, and layer-agnostic; requires neither cooperation from nor modification of any source; and is verifiable from recorded bytes. | |||||||||||||
| draft-chang-delta1-settlement-00.txt | ||||||||||||||
| Delta-1: A SCITT Profile for Binary Settlement Receipts in Agentic AI Accountability | ||||||||||||||
|
This document defines Delta-1, a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture applied to AI agent decision accountability. Delta-1 specializes the SCITT receipt model for a specific use case: proving that an individual AI decision met three accountability conditions simultaneously: C1: Evidence of the decision process was consumed and sealed. C2: Strategic intent was isolated from inference providers. C3: An authorized party recorded the settlement. The verdict is binary (VALID or INVALID) with no intermediate states. Receipts are independently verifiable without the issuing infrastructure being online, subject to the trust and attestation assumptions defined in this document. By building on the SCITT framework, Delta-1 inherits transparency-log semantics, receipt conventions, and verification patterns, while extending them with domain-specific requirements for AI decision closure. This profile is intended for regulated industries, including finance, healthcare, and legal, operating under accountability and record- retention obligations. | |||||||||||||
| draft-chang-ipplusplus-00.txt | ||||||||||||||
| IP plus plus | ||||||||||||||
|
This memo proposes an extension scheme for IPv4. It can resolve the exhaustion of IPv4 addresses at an extremely low cost and enable external access to internal networks as convenient as internal access to external networks. IPv4 adopts 32-bit fixed-length addresses, the problem of insufficient address space has long been prominent. As a temporary solution, Network Address Translation (NAT) alleviates address scarcity to a certain extent, yet it breaks the end-to-end communication principle of the Internet. It only allows intranet devices to actively access the extranet and fails to support direct access from the extranet to the intranet. Although various solutions have been proposed in the industry, they all have inherent limitations. This paper presents an innovative scheme named IP++ based on multi-level variable-length addresses, which fundamentally solves the above problems and restores the IP protocol to the basic end-to-end principle. The multi-level variable-length address structure of IP++ is highly compatible with the natural hierarchical topology of the Internet, featuring strong backward compatibility, convenient deployment and excellent usability. | |||||||||||||
| draft-chapman-a2a-mls-03.txt | ||||||||||||||
| End-to-End Encryption and Purpose-Bound Governance for Agent-to-Agent Messaging | ||||||||||||||
|
Agent-to-agent protocols increasingly carry messages between autonomous software agents acting on behalf of distinct principals, including across organisational boundaries. Existing protocols in this space secure the transport hop and authenticate the calling party, but do not provide message-level confidentiality, do not provide non-repudiable evidence of what a counterparty asserted, and do not carry machine-enforceable constraints on how a recipient may use the data conveyed. This document specifies a profile that addresses those three gaps. It defines a Governed Object: a signed, purpose-bound, expiring message envelope identified by a decentralised identifier. It specifies how such objects are exchanged inside end-to-end encrypted sessions established using the Messaging Layer Security (MLS) protocol [RFC9420], and how the MLS credential is cryptographically bound to the sending agent's identity. It defines the encapsulation of these constructs as an extension to an agent-to-agent transport, using the Agent2Agent (A2A) protocol [A2A] as the reference binding, and specifies mandatory receiver-side processing rules including replay rejection and purpose enforcement. | |||||||||||||
| draft-chapman-a2a-offline-delivery-00.txt | ||||||||||||||
| Offline Delivery and Reachability for Agent-to-Agent Messaging | ||||||||||||||
|
Agent-to-agent protocols assume a live HTTP or streaming hop. Many deployments cannot keep every agent always reachable: devices sleep, cost tiers duty-cycle backends, and operators park agents outside business hours. Senders need a machine-readable asleep signal, a bounded expectation for store-and-forward, and validation rules so an offline agent is not a spam sink and does not act on forged or expired messages after wake. This document profiles offline delivery and reachability for A2A- style JSON-RPC messaging. It defines abstract reachability modes, an asleep refusal signal, queue bounds and distinct queue-full errors, validate-on-dequeue requirements, and split delivery semantics (durable persist versus notify). It is independent of Messaging Layer Security (MLS) grouping; deployments that also use [GOMLS] MAY apply both profiles. | |||||||||||||
| draft-chen-ati-adaptive-ipv4-address-space-20.txt | ||||||||||||||
| Adaptive IPv4 Address Space | ||||||||||||||
|
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and IoTs (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to independently choose which service. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of an overlay of routers for interfacing between the Internet fabric (core plus edge routers) and the end user premises or IoTs. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy address expansion based on as few as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied 512M fold or even more. Enabling hierarchical address architecture which facilitates both hierarchical and mesh routing, EzIP can provide nearly the same order of magnitude of address pool resources as IPv6 while streamlining the administrative aspects of it. The basic EzIP will immediately resolve the local IPv4 address shortage, while being transparent to the rest of the Internet as a new parallel facility. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity for providing the availability levels required for delivering a long-term general service. The basic EzIP may be deployed in two distinctive phases. First, the CG-NAT operation may be enhanced by enabling the use of 240/4 netblock in addition to the current 100.64/10 netblock of RFC6598. This makes end-to-end connectivity feasible within the service area of each 240/4 netblock. Second, this capability may extend to global coverage with the use of the Option Word mechanism in the IP header. | |||||||||||||
| draft-chen-green-ran-transport-coord-energy-saving-00.txt | ||||||||||||||
| Coordinated Energy Saving between RAN and Transport Network | ||||||||||||||
|
This document provides an coordinated energy saving mechanism between RAN and transport network. | |||||||||||||
| draft-chen-green-transport-energy-saving-01.txt | ||||||||||||||
| Hybrid Energy Saving Mechanism for Transport Network | ||||||||||||||
|
This document continues the transport network energy saving that harmonizes device-level autonomy with network-wide coordination. By implementing control at hybrid both the device and network controller coordination, it enables dynamic, SLA-aware, and multi-layer energy optimization. | |||||||||||||
| draft-chen-grow-enhanced-as-loop-detection-09.txt | ||||||||||||||
| Enhanced AS-Loop Detection for BGP | ||||||||||||||
|
Misconfiguration and malicious manipulation of the BGP `AS_PATH` attribute can lead to route hijacking. This document proposes enhancements to BGP [RFC4271] inbound and outbound route processing when an AS loop is detected. This mechanism can be implemented directly on devices or deployed in a centralized architecture using the BGP Monitoring Protocol (BMP) [RFC7854]. These enhancements empower networks to quickly and accurately detect route hijacking and malicious path poisoning. Two implementation options are proposed: | |||||||||||||
| draft-chen-idr-srv6-flowspec-path-redirect-00.txt | ||||||||||||||
| Flowspec Indirection-id Redirect for SRv6 | ||||||||||||||
|
This document defines extensions to "FlowSpec Redirect to indirection-id Extended Community" for SRv6. This extended community can trigger advanced redirection capabilities to flowspec clients for SRv6. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. | |||||||||||||
| draft-chen-lamps-cms-frodokem-01.txt | ||||||||||||||
| Use of FrodoKEM in the Cryptographic Message Syntax | ||||||||||||||
|
FrodoKEM is a quantum-resistant key encapsulation mechanism (KEM) based on the standard Learning With Errors (LWE) problem，standardized by ISO. FrodoKEM offers multiple parameter sets, with the recommended sets for general use including (e)FrodoKEM-976-AES and (e)FrodoKEM-976-SHAKE for security level 3, and (e)FrodoKEM-1344-AES and (e)FrodoKEM-1344-SHAKE for security level 5. This document specifies the conventions for using FrodoKEM in the Cryptographic Message Syntax (CMS), using the KEMRecipientInfo structure defined in "Use of Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)" [RFC9629]. | |||||||||||||
| draft-chen-oauth-agent-authz-use-cases-03.txt | ||||||||||||||
| Agent Authorization use cases and gap analysis | ||||||||||||||
|
This document provides a systematic analysis of these emerging agent- based use cases. It categorizes them into distinct scenarios, details their specific authorization requirements, and performs a comprehensive gap analysis against the existing OAuth 2.0 framework[RFC6749] and its common extensions. The analysis identifies fundamental gaps and requirements, providing a foundation for future work on new extensions within the OAuth Working Group toward creating a more secure and interoperable ecosystem for agent- based systems. | |||||||||||||
| draft-chen-oauth-agent-revocation-00.txt | ||||||||||||||
| OAuth 2.0 Agent Authorization Explicit Revocation | ||||||||||||||
|
The OAuth 2.0 Token Revocation mechanism defined in RFC 7009 enables clients to notify authorization servers that a token is no longer needed. However, that mechanism is limited to single-token operations and does not support batch revocation, cascade propagation, or context-aware semantics at the agent level. With the emergence of autonomous systems and cross-domain agent networks, authorization servers require more granular, traceable revocation semantics. This document defines an agent-based explicit revocation extension, introducing new endpoints, request/response formats, and coordination protocols to support batch revocation based on agent IDs, cascade propagation, conditional revocation, and verifiable audit trails. | |||||||||||||
| draft-chen-oauth-rar-agent-extensions-01.txt | ||||||||||||||
| Policy,Lifecycle,and Intent Extensions for OAuth Rich Authorization Requests | ||||||||||||||
|
OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] defines a syntax for clients to request fine-grained permissions. While powerful, this mechanism lacks standardized methods for clients to express three critical contextual dimensions prevalent in modern automated systems: the high-level user intent driving the request, the required security policy under which the request should be evaluated, and the binding of the authorization's lifecycle to an external process. This document extends the RAR framework to address these gaps. It first defines a new authorization_details type, *intent_request*, to facilitate goal-oriented authorization. Second, it introduces two new parameters for the authorization_details object: *policy_context*, to request authorization under a specific assurance level, and *lifecycle_binding*, to tie the validity of the authorization grant to the state of an external entity. These extensions enable authorization servers to make more intelligent, secure, and context-aware decisions, particularly in ecosystems involving autonomous agents and complex, long-running tasks. | |||||||||||||
| draft-chen-oauth-roadmap-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-chen-qirg-srv6-qkd-relay-framework-00.txt | ||||||||||||||
| A Framework for SRv6-Based Trusted Key Relay in Quantum Key Distribution Networks | ||||||||||||||
|
Quantum Key Distribution (QKD) links generate symmetric key material between directly connected QKD nodes. Trusted relay is commonly used to extend key delivery beyond the reach of a single QKD link. A complete trusted-relay service requires the network to collect QKD link capacity and node trust information, compute a relay path according to service requirements, translate the result into an SRv6 path, and carry the relayed key information in an IPv6/UDP packet steered by that SRv6 path. This document describes an architectural framework for such a service. Each QKD link provides its available quantum key rate capacity, and each relay node provides a trust level. A controller uses these inputs together with application requirements to calculate a relay path. The path-computation algorithm is not standardized and may be selected or defined by the user, operator, or implementation. The calculated relay sequence is represented as an SRv6 path, and UDP packets following that path carry the key-relay information. This document identifies the protocol extension points needed to support the framework. The detailed encodings, message formats, SRv6 behaviors, TLVs, and signaling procedures are left for future work and are marked as TBD. | |||||||||||||
| draft-chen-rdma-windowless-ack-00.txt | ||||||||||||||
| Windowless Cumulative ACK Extension for RDMA Retransmission | ||||||||||||||
|
Traditional RDMA Reliable Connection (RC) uses selective retransmission, while TCP SACK depends on sliding window and RTO timer tuning. Both mechanisms waste network bandwidth when window or RTO parameters mismatch real network conditions. This document defines a windowless cumulative selective acknowledgement extension (T/C AETH) embedded within the RDMA ETH header, paired with dual- trigger ACK reporting logic driven by cumulative receive time threshold and cumulative received packet count threshold. The receiver generates extended SACK reports without sliding window constraints. The sender accurately identifies lost PSN segments through multi-segment confirmation fields carried in T/C AETH, then only retransmits missing packets. This design removes window dependency, eliminates redundant retransmissions, and improves bandwidth utilization and end-to-end throughput for high-speed RDMA workloads in data centers and wide-area networks. | |||||||||||||
| draft-chen-sidrops-sispi-06.txt | ||||||||||||||
| A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET | ||||||||||||||
|
This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object that carries an attestation for a single Autonomous System (AS) participating in inter-domain SAVNET. A valid SiSPI object confirms that the holder of the listed AS number has published the attestation indicating its participation in inter- domain SAVNET and its willingness to establish SAVNET peering relationships. | |||||||||||||
| draft-chen-spring-srv6-compressed-bsid-insertion-03.txt | ||||||||||||||
| SRv6 NET-PGM extension: Compressed BSID Insertion | ||||||||||||||
|
The End.B6.Insert and End.B6.Insert.Red SHOULD support the NEXT-CSID flavor either individually or in combinations. This document defines the SRH processing of the End.B6.Insert and End.B6.Insert.Red with NEXT-CSID. | |||||||||||||
| draft-chen-tls-composite-fndsa-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-6man-source-address-programmability-06.txt | ||||||||||||||
| Source IPv6 Address Programmability | ||||||||||||||
|
IPv6-based tunneling technologies, such as SRv6, have been deployed by provider on transport networks to provide users with services such as VPN and SD-WAN. After the service traffic enters the provider's transport network, it will be encapsulated by tunnel (SRv6 encapsulation). In order to better meet the SLA requirements of users, some technologies need to carry relevant information along with the flow to guide the processing of packets during forwarding. This document discusses the programmability of IPv6 source addresses to carry the necessary flow information | |||||||||||||
| draft-cheng-dhc-distribute-arn-dhcp-01.txt | ||||||||||||||
| Distribute ARN6 ID by DHCP | ||||||||||||||
|
This document describes a method for assigning ARN6 ID through DHCPv6. | |||||||||||||
| draft-cheng-dmm-srv6-6g-up-requirements-00.txt | ||||||||||||||
| Requirements of SRv6 for the 6G User Plane | ||||||||||||||
|
This document leverages the five standardized 6G service scenarios defined in 3GPP TR 22.870—multi-agent collaborative communication, compute-network integration, integrated sensing and communication (ISAC), network digital twin (NDT), and wide-area deterministic networking—as core business baselines. It systematically analyzes the multi-dimensional stringent user-plane requirements introduced by next-generation mobile systems. This work further dissects inherent technical limitations within the 5G GTP-U point-to-point tunnel architecture that render it incapable of accommodating dynamic 6G service characteristics. Based on the above analysis, this draft illustrates the inherent programmability benefits provided by SRv6, and accordingly establishes a suite of standardization requirements for SRv6 to serve as the underlay forwarding protocol of the 6G user plane. | |||||||||||||
| draft-cheng-lsr-extension-opt-srv6-sid-adv-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-lsr-igp-shortcut-enhancement-10.txt | ||||||||||||||
| IGP Color-Aware Shortcut | ||||||||||||||
|
IGP shortcut mechanism allows calculating routes to forward traffic over Traffic Engineering tunnels. This document specifies the enhancement of IGP shortcut which can steer routes onto TE-tunnels based on colors. | |||||||||||||
| draft-cheng-lsr-ospf-adjacency-suppress-06.txt | ||||||||||||||
| OSPF Adjacency Suppression | ||||||||||||||
|
This document describes a mechanism for a router to instructs its neighbors to suppress advertising the adjacency to it until link- state database synchronization and LSA reoriginating are complete. This minimizes transient routing disruption when a router restarts from unplanned outages. | |||||||||||||
| draft-cheng-rtgwg-adaptive-routing-framework-05.txt | ||||||||||||||
| Adaptive Routing Framework | ||||||||||||||
|
In many cases, ECMP (Equal-Cost Multi-Path) flow-based hashing leads to high congestion and variable flow completion time. This reduces applications performance. Load balancing based on local link quality is not always optimal, A global view of congestion, with information from remote links, is needed for optimal balancing. Adaptive routing is a technology that makes dynamic routing decision based on changes in traffic load and network topology. This document describes a framework for Adaptive Routing. Specifically, it identifies a set of adaptive routing components, explains their interactions, and exemplifies the workflow mechanism. | |||||||||||||
| draft-cheng-rtgwg-ai-network-reliability-problem-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cheng-rtgwg-enhanced-ecmp-01.txt | ||||||||||||||
| Enhanced ECMP for AI Cluster | ||||||||||||||
|
In AI training scenarios, the current mainstream load balancing technology is per-flow ECMP. However, hash collision issues lead to imbalanced traffic distribution, adversely affecting application performance. To address this problem, this document proposes an enhanced ECMP method that resolves load imbalance caused by hash collisions. The proposed solution effectively improves load balancing efficiency, reduces network congestion, and enhances overall network performance. | |||||||||||||
| draft-cheng-rtgwg-srv6-multihome-egress-protection-12.txt | ||||||||||||||
| SRv6 Egress Protection in Multi-homed scenario | ||||||||||||||
|
This document describes a SRv6 egress node protection mechanism in multi-homed scenarios. | |||||||||||||
| draft-cheng-savnet-intra-domain-sav-igp-06.txt | ||||||||||||||
| Intra-domain SAVNET Support via IGP | ||||||||||||||
|
This document introduces a new method for generating SAV rules based on the SAVNET mechanism. This method generates SAV rules layer by layer through the topology of the link state database formed by the IGP protocol. | |||||||||||||
| draft-cheng-sidrops-rpki-rov-gap-analysis-00.txt | ||||||||||||||
| Information Asymmetry and Deployment Gaps in RPKI-based Route Origin Validation | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV) have made significant progress. Over 60% of IPv4 routes now have ROAs, and more than 70% of Internet traffic flows to ROA-covered prefixes. A growing number of large transit providers actively reject RPKI-invalid routes. Despite these achievements, however, thousands of RPKI-invalid routes persistently appear in the global routing table, and their count has not shown a sustained downward trend over the years. More importantly, the deployment of strict ROV drop policies is highly uneven. While large transit providers have largely embraced dropping invalids, the long tail - tens of thousands of stub ASes and small regional ISPs - remains on the sidelines, often keeping ROV in monitor-only mode or not deploying it at all. This document analyzes the root causes behind these persistent gaps: (1) inherent *synchronization asymmetry* between the RPKI management plane and router control planes, and (2) the inevitable possibility of *errors on both planes* (ROA configuration and router origin configuration). These causes lead to a fundamental *information asymmetry*: downstream routers cannot distinguish self-inflicted invalids (due to sync delays or misconfigurations) from true prefix hijacks. We examine the operational harms of this asymmetry - unnecessary blackholes, path shifts, global route churn, and long-lived connectivity loss - and explain why the long tail remains reluctant to deploy ROV. We then identify the informational requirements that any enhanced system would need to meet: source-side cross-validation to prevent self-inflicted invalids, and downstream consistency information to reconcile local ROV outcomes with the origin's intent. The goal is to enable more confident and widespread deployment of strict ROV policies while preserving the existing RPKI-ROV architecture. This document does not propose a specific protocol solution. It defines the problem space and information needs, providing a foundation for future work. | |||||||||||||
| draft-cheng-spring-srpolicy-ar-framework-00.txt | ||||||||||||||
| SR-TE Path Based on Quality-Aware Dynamic Adaptive Adjustment | ||||||||||||||
|
This document defines a framework for quality-aware dynamic adaptive adjustment of Segment Lists within an SR-TE Candidate Path. It addresses the limitation of static weight assignment, which cannot adapt to dynamic changes in path quality (e.g., latency, loss, utilization). The framework enables continuous monitoring of end-to- end metrics for each Segment List, computation of updated weights proportional to their relative quality, and application at the policy head-end. This allows the Candidate Path to autonomously optimize traffic distribution towards higher-quality paths, enhancing performance without altering the SR-Policy architecture. | |||||||||||||
| draft-cheng-spring-srv6-encoding-network-sliceid-13.txt | ||||||||||||||
| Encoding Network Slice Identification for SRv6 | ||||||||||||||
|
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. For packet forwarding in a specific NRP, some fields in the data packet are used to identify the NRP the packet belongs to, so that NRP-specific processing can be performed on each node along a path in the NRP. At the data plane, use the NRP Selector ID to map and differentiate between different NRPs. How to map to NRP via Selector ID is not within the scope of this document. This document describes a novel method to encode NRP Selector ID in the outer IPv6 header of an SRv6 domain, which could be used to identify the NRP-specific processing to be performed on the packets by each network node along a network path in the NRP. | |||||||||||||
| draft-cheng-spring-srv6-for-ai-network-01.txt | ||||||||||||||
| A SRv6 Traffic Engineering Application for AI Network | ||||||||||||||
|
AI applications require fast processing and responses. Traffic using RoCEv2 has low entropy for ECMP. At the same time, AI elephant flows are predictable. Traffic engineering technology for AI backend networks becomes a possible solution. SRv6 TE can start from the host side, making SRv6 source routing and traffic path control from the host side an optional solution. This document presents a AI network Traffic Engineering (TE) application scenario for handling link faults and traffic congestion issues in data centers, based on Segment Routing over IPv6 (SRv6) and Compressed Segment Identifier (CSID). The application scenario uses SRv6 CSID Network Programming to directly install all forwarding paths on the head-end device. When a data center experiences a link fault or traffic congestion, the head-end device switches the forwarding path to another optimal path for avoiding the location of link fault or traffic congestion, ensuring optimal AI data flow forwarding. | |||||||||||||
| draft-cheng-spring-stateless-nd-srv6-locator-03.txt | ||||||||||||||
| Distribute SRv6 Locator by IPv6 Stateless Address Autoconfiguration | ||||||||||||||
|
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 locator, and segment IDs are generated within the address space of this SRv6 locator. This document describes a method for assigning SRv6 locators to SRv6 Segment Endpoint Nodes through IPv6 stateless address autoconfiguration. | |||||||||||||
| draft-cheshire-sbm-04.txt | ||||||||||||||
| Source Buffer Management | ||||||||||||||
|
In the past decade there has been growing awareness about the harmful effects of bufferbloat in the network, and there has been good work on developments like L4S to address that problem. However, bufferbloat on the sender itself remains a significant additional problem, which has not received similar attention. This document offers techniques and guidance for host networking software to avoid network traffic suffering unnecessary delays caused by excessive buffering at the sender. These improvements are broadly applicable across all datagram and transport protocols (UDP, TCP, QUIC, etc.) on all operating systems. | |||||||||||||
| draft-choudhary-rcoap-00.txt | ||||||||||||||
| Ratcheted CoAP: A Forward-Secure Delta over OSCORE for Highly Constrained Wake-Send-Sleep Devices | ||||||||||||||
|
This document specifies RCOAP, a compact, zero-round-trip, link-layer agnostic object-security mechanism for highly constrained devices that transmit infrequently. RCOAP is a targeted delta over OSCORE ([RFC8613]): instead of a single long-lived Sender Key, RCOAP derives a fresh symmetric key for every message via a one-way hash ratchet. This bounds the impact of physical device capture to future messages only, at the cost of a modest per-message size increase and the loss of future secrecy. RCOAP is explicitly scoped to a narrow niche left open between OSCORE and EDHOC ([RFC9528]): devices for which even EDHOC's one-time handshake cost is disproportionate to their message rate or compute budget. This document is a first individual submission, has not been reviewed by the IETF, and requests feedback in particular from the LAKE and CoRE working groups on whether this gap is real and worth standardizing, or already adequately covered. | |||||||||||||
| draft-chowdhury-terms-txt-00.txt | ||||||||||||||
| terms.txt: Machine Access Terms and an Origin-Enforced Consent and Compensation Exchange | ||||||||||||||
|
The Robots Exclusion Protocol lets an origin ask automated clients not to fetch certain paths. It cannot express who is asking, for what purpose, under what terms, or at what price, and it provides no server-side enforcement. This document specifies terms.txt, a file at a well-known location in the style of robots.txt that states, per path and per purpose, whether automated access is allowed, charged, or denied, at what use level, at what price, and whether a user's delegation is required. It also specifies the HTTP exchange that enforces the file at the origin: requests signed with Web Bot Auth, a signed declaration of intent, delegation tokens and payment vouchers bound to the authenticated identifier, payment negotiation signaled with Problem Details, and origin-signed receipts. The document states which properties the exchange enforces before delivery, which it can only audit afterward, and which remain contractual. | |||||||||||||
| draft-chu-oauth-subject-key-binding-00.txt | ||||||||||||||
| OAuth Subject Signing Key Binding for Resource Servers | ||||||||||||||
|
Resource servers in OAuth deployments sometimes receive application- layer authorization evidence that is digitally signed by the subject represented by an access token. Verification of such evidence requires the resource server to obtain a trusted public signing key that is bound to that subject. This specification defines the subject_keys parameter, by which an OAuth authorization server conveys one or more subject public signing keys to a resource server. The parameter can be carried as a claim in a JWT access token or as a member of a token introspection response. The resulting key binding is scoped to the authorization server, token subject, resource server audience, and token validity context. This specification does not define a public-key enrollment protocol or the syntax and semantics of the application-layer authorization evidence. It also does not use the OAuth cnf claim, which identifies a proof-of-possession key held by the presenter of a token. | |||||||||||||
| draft-chuang-agent-attribution-header-fields-00.txt | ||||||||||||||
| Agent Attribution Header Fields | ||||||||||||||
|
When human users communicate with autonomous computer agent users, the human users should be able to identify that communication as coming from agent users and know which humans are responsible for the agent users. This document specifies email header fields that an email sender can use to transmit agent user attribution information to email receivers. The first header field is human readable and specifies the agent's responsible humans' email address. The second header field is machine readable and specified in JSON attribution information. | |||||||||||||
| draft-chuang-dkim2-localized-header-fields-00.txt | ||||||||||||||
| DKIM2 Localized Header Fields | ||||||||||||||
|
The DKIM2 specification authenticates email messages with digital signatures, with additional metadata to recover the signature even when the message is forwarded and modified. This draft builds upon DKIM2 to support hashing and authentication of domain specific headers even when the message is forwarded and modified. Other trace-like headers may be supported as well. Authentication-Result header fields support documentation of authentication results as seen by receivers during the forwarding path. Receivers often delete older copies of Authentication-Results even though they may have forensic value. This draft provides a means to preserve those header fields despite those receiver actions. | |||||||||||||
| draft-chuang-dkim2-sender-policy-01.txt | ||||||||||||||
| DKIM2 Sender Policy | ||||||||||||||
|
This document updates DMARC RFC9989 for DKIM2. In particular DKIM2 verification supports MTA relay forwarding with message modifications through multiple MTAs, so this updates DMARC to support those scenarios as well. While DMARC defines a RFC5322 From alignment constraint with an enforcement policy if validation fails, this generalizes and separates enforcement policy from constraint validation policies. This provides a mechanism for MTAs to declare support for DKIM2 through the DMARC DNS policy record that helps secure DKIM2 from downgrade attacks. | |||||||||||||
| draft-chueayen-attestation-receipts-02.txt | ||||||||||||||
| Enforcement Attestation Receipts for AI Inference Decisions | ||||||||||||||
|
This document specifies a compact JSON attestation receipt for an AI inference decision. A receipt binds an outcome to a request hash under a published Ed25519 public key, so a party that does not trust the issuer's infrastructure can still verify offline what the issuer's signing key attested was decided. The format is intentionally small and version-selected, so independent verifiers stay easy to implement and audit. It is intended for settings where an operator-controlled log is not, on its own, sufficient evidence of the decision. | |||||||||||||
| draft-chung-ccwg-search-10.txt | ||||||||||||||
| SEARCH -- a New Slow Start Algorithm for TCP and QUIC | ||||||||||||||
|
TCP slow start is designed to ramp up to the network congestion point quickly, doubling the congestion window each round-trip time until the congestion point is reached, whereupon TCP exits the slow start phase. Unfortunately, the default Linux TCP slow start implementation -- TCP Cubic with HyStart [HYSTART] -- can cause premature exit from slow start, especially over wireless links, degrading link utilization. However, without HyStart, TCP exits slow start too late, causing unnecessary packet loss. To improve TCP slow start performance, this document proposes using the Slow start Exit At Right CHokepoint (SEARCH) algorithm [KCL24] where the TCP sender determines the congestion point based on acknowledged deliveries -- specifically, the sender computes the delivered bytes compared to the sent bytes, smoothed to account for link latency variation and normalized to accommodate link capacities, and initiates exits slow start if the delivered bytes are lower than expected. We implemented SEARCH in Linux, FreeBSD, and QUIC and evaluated it over WiFi, 4G/ LTE, and low earth orbit (LEO) and geosynchronous (GEO) satellite links. Analysis of the results show that SEARCH reliably exits from slow start after the congestion point is reached but before inducing packet loss. | |||||||||||||
| draft-chursin-rats-energy-attestation-00.txt | ||||||||||||||
| Hardware-Rooted Attestation Tokens for Electricity Generation | ||||||||||||||
|
This document specifies an attestation token format and verification protocol for hardware-rooted measurements of electricity generation. The protocol enables a tamper-evident chain of custody from the secure element at a metering device to a publicly verifiable settlement layer, using ECDSA P-256 signatures generated inside a certified secure element and carried in a COSE_Sign1 structure. It defines: (a) the CBOR-encoded attestation token, aligned with the Entity Attestation Token format of RFC 9711 and the Remote ATtestation procedureS (RATS) architecture of RFC 9334; (b) a Merkle- aggregation and on-chain commitment scheme for scalable verification; and (c) a registry mechanism for endorsing device public keys. The token is intended for use by relying parties, such as energy producers, consumers, regulators, and standards bodies, that require cryptographic provenance for clean-energy claims. | |||||||||||||
| draft-chuyi-nmrg-agentic-network-inference-01.txt | ||||||||||||||
| Agentic Network Architecture and Protocol for Supporting Agent Interconnection Communication and Multi-level Inference | ||||||||||||||
|
With the advent of the era of AI large models and intelligent agents, more and more scenarios about agent interconnection have emerged, such as collaboration among multiple agents within a household, intelligent robots cooperating to complete pipeline tasks in different operations of the industrial Internet, drone groups, intelligent vehicle networking, etc. These scenarios not only require low latency and high bandwidth, but also demand efficient information exchange and cross-domain coordination and scheduling capabilities in complex collaborative tasks. Therefore, new orchestration and management technologies and frameworks are needed in existing networks to address this. The interconnection of different agents also brings about an emergence of inference, with a large number of inference requests being processed from the mobile phone side to the cloud. In order to improve inference efficiency, in a cloud-edge-end multi-layer inference architecture, large models and agents at different levels cooperate to complete tasks, resulting in a complex intelligent agent interconnection network. Gateways and routers serve as forwarding entries on the network road highways, responsible for building communication channels for the agents spread throughout the network, which requiring function upgrades to support the continuously evolving inference service in the future. | |||||||||||||
| draft-claise-green-capability-discovery-01.txt | ||||||||||||||
| A YANG Data Model for Power State Capability Discovery | ||||||||||||||
|
This document defines a YANG data model that augments the system capabilities model of RFC 9196 to allow a network element to advertise, per hardware Component, the set of Power States that the Component supports, together with a static characterization of each such state: the expected and maximum Power the Component draws in it, and the time to enter and exit it. This capability model complements the operational Power and Energy data model defined in the GREEN Power and Energy YANG module, which reports the current Power State and the measured Power of a Component, but not which Power States are available, how much Power each draws, or how long transitions between them take. It is anchored to the hardware inventory of RFC 8348, reuses the Power State identities of the GREEN Power and Energy model, and, because it is static, may be provided at implementation time as YANG instance data per RFC 9195 so that an Energy Management System can learn a platform's Power State capabilities before the equipment is deployed or even powered on. | |||||||||||||
| draft-claise-opsawg-ipfix-ordered-ie-01.txt | ||||||||||||||
| Ordered Information Element Export in IP Flow Information Export (IPFIX) | ||||||||||||||
|
The IP Flow Information Export (IPFIX) protocol allows the same Information Element to appear multiple times in a Template Record. RFC 7011 states that multiple occurrences of the same Information Element SHOULD follow the logical order of their treatments by the Metering Process; however, no protocol mechanism exists for the Exporting Process to explicitly signal to the Collecting Process that this ordering is guaranteed. Without such a guarantee, the Collecting Process cannot safely interpret repeated Information Elements as ordered observations. This document describes the problem, presents use cases, analyzes candidate solutions, and specifies a mechanism -- a new Ordered Set type -- that establishes an end-to-end ordering guarantee: the Metering Process records repeated Information Element values in the order the corresponding observations are made, the Exporting Process preserves and signals this guarantee, and the Collecting Process interprets the n-th occurrence of an Information Element as corresponding to the n-th observation by the Metering Process at the Observation Point. This document updates RFC 7011, RFC 5476, and RFC 6183. | |||||||||||||
| draft-clifford-testimony-record-01.txt | ||||||||||||||
| The Testimony Record: An Interchange Format for What an Automated System Believed and Did | ||||||||||||||
|
This document specifies the Testimony Record, an append-only interchange format for the account an automated system gives of its own operation: what it believed, what evidence each belief rested on, which of its beliefs contradicted one another, what actions it attempted, and who authorised the consequential ones. The format is defined so that a party who was not present, and who has no access to the emitting system, can read a record and check specific properties of it. Four conformance levels are defined, each stating a property that can be verified mechanically rather than asserted. This is not a logging format. Logs record what a program did. A Testimony Record states what a system claimed to know, what disagreed with it, and what it was permitted to do about it. | |||||||||||||
| draft-cllz-cfrg-ecdsa-pop-00.txt | ||||||||||||||
| Schnorr-Type Proofs of Possession for ECDSA Device Binding | ||||||||||||||
|
This document specifies a Schnorr-type, circuit-free zero-knowledge proof of possession (PoP) of an ECDSA signature produced under a committed public key over the NIST P-256 (secp256r1) curve. The PoP lets a credential holder prove, in zero knowledge, that it can produce a fresh ECDSA signature under a device public key without revealing that key, thereby providing device binding for privacy- preserving credentials whose presentation must remain unlinkable. The construction is built exclusively from Sigma protocols as it decomposes the ECDSA verification equation into a scalar- multiplication relation and a point-addition relation over P-256, each proved with a dedicated Sigma protocol over a companion ("Tom") curve whose scalar field equals the base field of P-256. It is designed to be expressed using the interfaces of the CFRG Sigma- protocols specification and to serve as the device-binding sub-proof of the modular BBS / JSON Web Proofs construction. SNARK-based realizations of the same relation are out of scope. | |||||||||||||
| draft-cmcc-asrp-08.txt | ||||||||||||||
| Available Session Recovery Protocol | ||||||||||||||
|
This document describes an experimental protocol named the Available Session Recovery Protocol (ASRP). The protocol is designed to optimize high-availability network cluster architectures, providing a superior high-availability solution for clusters offering stateful network services such as load balancing and Network Address Translation (NAT [RFC4787]). ASRP defines the procedures for session backup and recovery, as well as the message formats used during these interactions, enabling efficient and streamlined session state management. In contrast to traditional high-availability techniques that back up session state within the cluster itself, the core innovation of ASRP lies in its distributed backup of state information to the client or server side. This approach offers multiple advantages: theoretically unlimited elastic scaling capacity; support for rapid recovery from multi-point failures; reduction of resource redundancy through the elimination of centralized backup nodes; and significant simplification of cluster implementation complexity. The ASRP protocol provides a standardized method for constructing elastic service clusters, facilitating broader participation from software and hardware developers in building elastic cloud network service clusters. | |||||||||||||
| draft-cmcc-tcp-sro-02.txt | ||||||||||||||
| The Session Recovery (SR) Option for TCP | ||||||||||||||
|
This document defines the Session Recovery (SR) option for TCP. The option lets the endpoints of a connection exchange identifiers: during the handshake each endpoint carries its own identifier, and designated segments afterwards carry the identifier of the peer. This places the knowledge of which endpoint a connection belongs to inside the TCP header, where network functions on the path - load balancers, NAT gateways, firewalls - can read it without per-flow state and without payload inspection. The primary use is session recovery in SNAT and load-balancing clusters; further uses include reduced-state forwarding, connection-tracking recovery, and per- backend telemetry. The option is carried in the SYN, the SYN-ACK, and retransmitted segments, or in every segment when so configured; the default adds no overhead to normal data segments. Endpoints that do not support it behave as if the option did not exist. | |||||||||||||
| draft-codere-ldapsyntax-11.txt | ||||||||||||||
| Lightweight Directory Access Protocol (LDAP): Additional Syntaxes | ||||||||||||||
|
This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directory services series X.500. This includes widely used datatypes and syntaxes. | |||||||||||||
| draft-coetzee-oauth-spt-txn-tokens-03.txt | ||||||||||||||
| Transaction-Bound Authorization Tokens for Software and AI Agents (SPT-Txn) | ||||||||||||||
|
Current authorization is role-scoped: an actor is granted a role whose authority persists across every action it takes. This fails exactly when actors fail -- under compromise, prompt injection, or goal hijacking -- because a compromised actor retains full role authority. This document specifies SPT-Txn, a family of transaction- bound authorization tokens in which authority exists only inside a short-lived token bound to one declared action, on one resource, under one jurisdictional policy, verified against how the requesting workload was attested. Delegation across agents and tools is expressed as a cryptographically sealed chain that can only narrow authority and is verifiable offline. Each authorization decision emits a signed, tamper-evident receipt as a byproduct of enforcement. This document specifies normative intent binding, transaction receipts and their transparency log, attested issuance via OAuth 2.0 Token Exchange, per-token status-list revocation, and cryptographic algorithm agility including hybrid post-quantum signing. It also hardens attested issuance in response to an adversarial security review of the reference implementation: it makes an audience and a verifiable expiry mandatory on the presented attestation, requires the issuer to bound the delegated depth it grants, and clamps a token's lifetime to the attestation it was minted on. The issuer- side requested-versus-permitted scope intersection is retained; the enforcement point re-checks the chain independently. | |||||||||||||
| draft-cole-cose-encoded-gnss-chimera-marker-keys-00.txt | ||||||||||||||
| Global Navigation Satellite System (GNSS) Fast Channel Chimera Marker Key Package using Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) | ||||||||||||||
|
Chips Message Robust Authentication (Chimera) is a technique by which a Global Navigation Satellite System (GNSS) constellation, such as the Global Positioning System (GPS), may provide user equipment (i.e., receivers) with authentication of pseudorange measurements on one or more publicly available (i.e., open) Positioning, Navigation, and Timing (PNT) signals. This specification describes a Fast Channel Chimera Marker Key Package, an efficient data structure for encoding one or more Fast Channel Chimera marker keys and associated metadata with a digital signature over all security relevant parameters. Concise Binary Object Representation (CBOR) Object Signing and Encryption (COSE) is used as the underlying message structure. This specification also describes a streaming network protocol by which Fast Channel Chimera Marker Key Packages may be distributed over the Internet. | |||||||||||||
| draft-comcast-flair-crypto-discovery-00.txt | ||||||||||||||
| FLAIR: Framework for Language-Agnostic Discovery of Cryptographic Elements using Semantic Graphs | ||||||||||||||
|
This document introduces FLAIR (Framework for Language-Agnostic Intermediate Representation), a novel approach to discover cryptographic elements in source code. By detecting encryption components present in code, FLAIR addresses critical challenges like identifying deprecated and misconfigured implementations across diverse programming languages. Unlike language-specific tools, FLAIR employs semantic graphs to represent instances of encryption detected, enabling identification of cryptographic algorithm usage, associated parameters (keys, nonces, salts), and flag compliance status with established encryption standards. The semantic graph approach makes representing cryptographic algorithms and related elements independent of the underlying programming language. | |||||||||||||
| draft-condrey-content-binding-00.txt | ||||||||||||||
| A Conformant Mechanism for Content Binding in Text Streams | ||||||||||||||
|
This document proposes a conformant mechanism for binding metadata to plain text streams using boundary-delimited transport. The mechanism uses existing ASCII characters to establish a text/non-text boundary, requiring no new code points and no changes to existing Unicode text processing algorithms. It defines a delimiter format, a parsing algorithm, a canonicalization procedure, and correctness criteria sufficient for two independent implementations to interoperate without coordination. This RFC is a companion to a Unicode Technical Standard proposal submitted to the Unicode Technical Committee. | |||||||||||||
| draft-condrey-posme-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-connolly-cfrg-ml-dsa-security-considerations-02.txt | ||||||||||||||
| Security Considerations for ML-DSA | ||||||||||||||
|
NIST standardized ML-DSA as FIPS 204 in August 2024. This document discusses how to use ML-DSA within protocols - that is, what problem it solves, and what you need to do to use it securely. | |||||||||||||
| draft-consolidated-content-01.txt | ||||||||||||||
| Content Negotiation for Consolidated Machine-Readable Representations | ||||||||||||||
|
This document specifies the use of HTTP content negotiation and the Prefer header to request consolidated, machine-readable representations of web resources. A client uses the Accept header to negotiate an appropriate media type and Prefer: return=consolidated to request a representation intended for automated consumption. A server that honours the preference identifies the selected representation with Preference-Applied: return=consolidated and varies cached responses on Accept and Prefer. The mechanism uses existing HTTP semantics and introduces a single new preference value for the existing Prefer header. It provides a protocol-level alternative to ad-hoc client detection or path conventions when serving machine-readable representations, while also enabling publishers to reduce repeated fetching, bandwidth use, and server processing. | |||||||||||||
| draft-contreras-bmwg-ai-agent-benchmarking-00.txt | ||||||||||||||
| Benchmarking Methodology for AI Agents in Network Operations | ||||||||||||||
|
This document defines a benchmarking methodology for evaluating Artificial Intelligence (AI) agents performing network operations tasks such as configuration, troubleshooting, and optimization. This document focuses on task-oriented performance metrics, including task completion success, execution efficiency, and robustness across multi-step workflows, proposing benchmarking practices towards agent- based, closed-loop network operation scenarios. The proposed methodology aims to provide a reproducible and vendor- independent framework to compare AI agent effectiveness in controlled network environments. | |||||||||||||
| draft-contreras-detnet-preof-oam-00.txt | ||||||||||||||
| PREOF Observability and OAM Requirements | ||||||||||||||
|
Packet Replication, Elimination, and Ordering Functions (PREOF) enables highly reliable packet delivery through path redundancy and packet sequencing mechanisms in DetNet domains. Existing DetNet Operations, Administration, and Maintenance (OAM) specifications provide mechanisms for monitoring service connectivity, packet loss, delay, and overall service performance. However, they do not provide detailed operational visibility into the behavior of PREOF functions themselves. This document identifies operational observability gaps associated with PREOF, defines requirements for PREOF-specific OAM, and introduces a set of observable events and metrics to monitor, troubleshoot, and validate PREOF operation independently of the underlying DetNet data plane technology. | |||||||||||||
| draft-contreras-pce-pam-07.txt | ||||||||||||||
| Path Computation Based on Precision Availability Metrics | ||||||||||||||
|
This document extends PCEP to support Precision Availability Metrics (PAM) [RFC9544] for path computation. The optimization objectives for PAM computations are encoded using the Objective Function (OF) object defined in [RFC5541], allowing PCCs to specify precise optimization criteria for services with SLO requirements. And a PCE can report the statistical characterization associated with a computed path. | |||||||||||||
| draft-contreras-pim-eco-mode-01.txt | ||||||||||||||
| IGMP / MLD Extension for Signaling Eco-Mode | ||||||||||||||
|
This document specifies an extension to IGMPv3 and MLDv2 messages to indicate eco-mode preferences in the delivery of multicast content based on the mechanism described in [RFC9279]. The extension enables receivers and network elements to signal energy-aware multicast delivery preferences, including different eco-mode levels, so that multicast services can be operated consistently with energy-efficient network management, service-level optimisation, and telemetry-driven assessment of energy and carbon impact. | |||||||||||||
| draft-contreras-tvr-interco-scheduling-00.txt | ||||||||||||||
| Time-Variant Routing Scheduling for Interconnection Scenarios | ||||||||||||||
|
This document specifies the applicability of Time-Variant Routing (TVR) information in interconnection scenarios. In particular, it discusses how scheduled changes affecting BGP sessions, routing policies, and effective interconnection capacity between administrative domains can be applied. | |||||||||||||
| draft-contreras-tvr-schedule-lifecycle-yang-00.txt | ||||||||||||||
| Lifecycle and State Extensions for TVR Schedule YANG Model | ||||||||||||||
|
The Time-Variant Routing (TVR) YANG data model [I-D.ietf-tvr-schedule-yang] defines a mechanism to describe scheduled changes in network resources (such as nodes and topology) as a function of time. However, the base model does not provide explicit lifecycle management semantics for the schedules, such as activation, suspension, or deprecation. This document defines an optional augmentation of the base YANG model to introduce lifecycle and administrative state control, enabling more flexible operational handling of schedules without modifying the base model semantics. | |||||||||||||
| draft-corbel-updates-to-rfc2289-00.txt | ||||||||||||||
| Updates to the One-Time Password (OTP) System defined by RFC 2289 | ||||||||||||||
|
This document aims to submit a few updates to RFC 2289 [RFC2289], which describes a One-Time Password (OTP) System: an application programming interface to the new Secure Hash Algorithms (SHA256, SHA384, and SHA512), an algorithm for folding hashes to 64 bits, using alternate dictionaries, and automatic renewal of authentication parameters will be described. | |||||||||||||
| draft-corneo-schc-ctx-mgmt-00.txt | ||||||||||||||
| SCHC Context Management Extensions | ||||||||||||||
|
This document defines extensions to the Static Context Header Compression (SCHC) framework that improve context management efficiency. Two categories of mechanisms are introduced: rule referencing CDAs (ref and ref-edit) that enable composable rule definitions and reduce context storage, and a rule fragment branching CDA (branch) with associated Matching Operators that enable dynamic multi-layer protocol compression without combinatorial rule explosion. | |||||||||||||
| draft-corneo-t2trg-sdf-coap-agents-00.txt | ||||||||||||||
| Extending SDF and CoAP for AI Agent Interaction with IoT Devices | ||||||||||||||
|
This document proposes extensions to the Semantic Definition Format (SDF) and the Constrained Application Protocol (CoAP) to better support AI agent interaction with Internet of Things (IoT) devices. It covers two aspects: identifying AI agents in CoAP transactions, and making SDF device descriptions readily consumable by large language models (LLMs) and autonomous agents. The document is intended to stimulate discussion within T2TRG on these topics. | |||||||||||||
| draft-correctover-ccs-09.txt | ||||||||||||||
| Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls | ||||||||||||||
|
This document defines the Correctover Conformance Shape (CCS), a runtime verification framework for AI agent tool calls. CCS specifies seven verification dimensions (Structure, Schema, Latency, Cost, Identity, Integrity, Security) that tool calls and results must conform to at runtime. The framework defines a receipt format with Ed25519 signatures, three verdict values (allow, deny, escalate) and four executor lifecycle states (confirmed, dispatched, indeterminate, unknown), and normative requirements for implementations. This revision makes the document self-contained for publication: the related AEB and CAID specifications are reclassified as Informative References, and the native artifact requirements they motivate are restated normatively in this document so that no conformance requirement depends on an unreferenced work in progress. It also corrects the implementation-experience description (one reference implementation in two deployment forms, plus one independently developed third-party interoperability profile), clarifies the relationship to SCITT-based agent evidence work, and updates the author contact address. The detached Ed25519 signature construction over RFC 8785 canonical JSON and the receipt lifecycle and signing- algorithm conformance are unchanged from draft-08. | |||||||||||||
| draft-cowles-aee-01.txt | ||||||||||||||
| Agent Envelope Exchange (AEE): A Minimal JSON Envelope Format for Inter-Agent Communication | ||||||||||||||
|
Agent Envelope Exchange (AEE) defines a minimal, transport- independent JSON envelope format for communication between autonomous AI agents, traditional services, and human participants. The envelope comprises 14 well-defined fields that provide message identity, typing, correlation, tracing, priority, and extensibility without prescribing payload semantics or transport mechanisms. AEE separates the concerns of message routing and lifecycle management (the envelope) from domain-specific meaning (intent schemas), enabling portable, composable, and auditable workflows across heterogeneous agent frameworks. This document specifies the envelope structure, validity rules, conformance levels, entity identifier conventions, a reserved intent namespace for protocol negotiation, and a referencing strategy that avoids envelope nesting. | |||||||||||||
| draft-cowles-aocl-01.txt | ||||||||||||||
| Agent Orchestration Control Layers (AOCL) Protocol | ||||||||||||||
|
Agent Orchestration Control Layers (AOCL) is a protocol that standardizes how an orchestrator processes incoming events by passing them through a layered control pipeline. AOCL defines an eleven- layer taxonomy covering ingress normalization, identity scoping, smart routing, policy gating, plan decomposition, context retrieval, prompt shaping, delegation and execution, verification, response assembly, and audit writeback. The protocol is runtime-agnostic and framework-agnostic, producing auditable governance traces as a first- class output. AOCL supports both sequential pipeline and directed acyclic graph (DAG) execution modes, with explicit bypass and branch semantics that mandate audit records for all control-flow deviations. | |||||||||||||
| draft-cowles-volt-01.txt | ||||||||||||||
| Verifiable Operations Ledger and Trace (VOLT) Protocol | ||||||||||||||
|
The Verifiable Operations Ledger and Trace (VOLT) protocol defines a minimal, interoperable format for producing tamper-evident execution traces for agentic AI workflows. VOLT records are linked via SHA-256 hash chains and packaged into portable Evidence Bundles that can be verified independently by any conformant implementation. VOLT functions as a "flight recorder" for AI agent operations: it captures the sequence of events -- messages received, policy decisions evaluated, human approvals granted, tools invoked, and results returned -- with cryptographic integrity guarantees that detect post-hoc modification, deletion, or insertion of records. The protocol is privacy-first by design. Events carry metadata and content-addressed references rather than raw secrets or sensitive payloads. Evidence Bundles support explicit redaction, optional Ed25519 signatures for non-repudiation, and both rolling and final snapshot modes for long-running workflows. | |||||||||||||
| draft-cowles-ward-00.txt | ||||||||||||||
| Write-once Append-only Receipt Digests (WARD): A Content-Free Hash-Chain Witnessing Protocol for Agentic AI Systems | ||||||||||||||
|
Write-once Append-only Receipt Digests (WARD) defines a minimal, interoperable protocol for producing tamper-evident, content-free hash-chain witnesses over events from agentic AI systems. WARD observes events from companion protocols (Agent Envelope Exchange (AEE) messages, Agent Orchestration Control Layers (AOCL) decisions, and Verifiable Operations Ledger and Trace (VOLT) evidence records) and produces cryptographically linked receipts that prove specific events existed at specific points in time, without storing any event content. WARD entries record only source identifiers and payload hashes, never raw payloads, secrets, or personally identifiable information. Entries are linked via SHA-256 hash chains anchored by deterministic genesis hashes. Periodic checkpoints called "tips" may be signed with Ed25519 and published to external append-only stores (sinks) for independent verification. A meta-chain pattern allows witnessing tips from multiple sub-chains, providing deployment-wide integrity from a single verification point. The protocol is designed as a passive observer: witnessing never blocks, delays, or modifies the source event pipeline. WARD failures are logged but never disrupt AEE transport, AOCL decisions, or VOLT recording. This fire-and-forget integration model ensures that witnessing adds tamper-evidence guarantees without introducing operational risk. | |||||||||||||
| draft-creator-bvs-protocol-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-crocker-dnsop-dnssec-algorithm-lifecycle-04.txt | ||||||||||||||
| Documenting and Managing DNSSEC Algorithm Lifecycles | ||||||||||||||
|
Cryptographic algorithms go through multiple phases during their lifetime: experimental, adopted, generally available, in mainstream use, phasing out, deprecated, and obsoleted. This document defines phases for algorithm deployment lifecycles within DNSSEC, and criteria that the IETF and/or other Standards Development Organizations are encouraged to use when moving an algorithm from one phase to the next. | |||||||||||||
| draft-crockford-davis-base32-for-humans-01.txt | ||||||||||||||
| Base32 for Humans | ||||||||||||||
|
This document details the formal specification of Base32 for Humans; an alternate Base32 alphabet which extends the "Handled by Humans" text found in Section 3.4 of RFC 4648. This base features an alphabet curated for expressing numbers in a form that can be conveniently and accurately transmitted between humans and computer systems. | |||||||||||||
| draft-crovia-seal-01.txt | ||||||||||||||
| The Crovia Seal: A Cryptographic Receipt Format for AI-Generated Output Provenance | ||||||||||||||
|
This document specifies the Crovia Seal v1, a compact, tamper-evident JSON receipt that may be attached to any output produced by an AI generator (large language model, image model, audio model, or composite system) to record its provenance in a cryptographically verifiable form. A Crovia Seal binds an issuer's identity to the SHA-256 digests of an input/output pair, the identity and parameters of the generator, an emission timestamp, and a per-issuer hash chain, under an Ed25519 signature computed over a strict canonicalization (CSC-1) of the receipt with explicit domain separation. Optional fields permit transparency-log inclusion proofs and witness co- signatures. The Seal is designed for offline verification and for inclusion in third-party transparency logs and standards-based revocation infrastructure. | |||||||||||||
| draft-cruzgonzalez-ipoac-dns-00.txt | ||||||||||||||
| DNS over Avian Carriers (DoAC) | ||||||||||||||
|
The Domain Name System (DNS) was designed under the implicit assumption that the underlying transport would be fast, reliable, and free from predation. This document specifies DNS over Avian Carriers (DoAC), enabling hostname resolution for networks operating over avian-carrier infrastructure. Without DoAC, operators of avian- carrier networks are forced to hardcode IP addresses directly onto their Carriers, a practice that does not scale and is widely considered inelegant. | |||||||||||||
| draft-cui-ai-agent-discovery-invocation-02.txt | ||||||||||||||
| AI Agent Discovery and Invocation Protocol | ||||||||||||||
|
This document proposes a standardized protocol for discovery and invocation of AI agents. It defines a common metadata format for describing AI agents (including capabilities, I/O specifications, supported languages, tags, authentication methods, etc.), a capability-based discovery mechanism, and a unified RESTful invocation interface. This revision refines the discovery mechanism by defining fields for intent-based agent selection. This capability enables a client, host agent, or orchestration system to describe a task intent and receive a ranked set of candidate agents before invocation, without changing existing discovery or invocation semantics. The goal is to enable cross-platform interoperability among AI agents by providing a discover-and-match mechanism and a unified invocation entry point. Security considerations, including authentication and trust measures, are also discussed. This specification aims to facilitate the formation of multi-agent systems by making it easy to find the right agent for a task and invoke it in a consistent manner across different vendors and platforms. Intent-based selection is an application-layer capability and does not define network routing, packet forwarding, path computation, reachability advertisement, or address resolution. | |||||||||||||
| draft-cui-ai-agent-task-01.txt | ||||||||||||||
| Task-oriented Coordination Requirements for AI Agent Protocols | ||||||||||||||
|
AI agent communication requires intelligent task level coordination to manage dynamic workloads across large-scale, heterogeneous networking environments. This draft proposes general requirements for an agent protocol to enable autonomous task coordination at scale, including dynamic task discovery, negotiation, and context- aware scheduling with real-time adaptability. | |||||||||||||
| draft-cui-dawn-mdi-model-00.txt | ||||||||||||||
| An Information Model for Minimum Discoverable Information (MDI) | ||||||||||||||
|
The Discovery of Agents, Workloads, and Named Entities (DAWN) terminology document defines Minimum Discoverable Information (MDI) as the minimum information an entity must provide to be discoverable, but does not define its field-level content. The DAWN requirements and problem-statement documents identify the need for a standardized minimum structure; in its absence, emerging discovery formats risk each defining its own minimal metadata, with descriptors that do not interoperate across organizational or protocol boundaries. This document proposes a small, encoding-neutral information model, in the sense of RFC 3444, for MDI: three mandatory elements, a short set of recommended and optional elements, and the minimal constraints that hold among them. It is a minimum common subset and a mapping target for richer descriptors -- not a new card format and not a discovery protocol. | |||||||||||||
| draft-cui-dns-native-agent-naming-resolution-02.txt | ||||||||||||||
| DNS-Native AI Agent Naming and Resolution | ||||||||||||||
|
This document specifies DNS-Native Agent Naming and Resolution (DN- ANR) for AI agents. DN-ANR uses domain names (FQDNs) as stable Agent Identifiers and resolves a selected Agent Identifier to verifiable endpoints and supported protocol/version information with a cryptographic integrity chain, with DNSSEC preferred. DN-ANR is a post-selection resolution profile. It does not define agent discovery, capability search, semantic matching, ranking, or routing decisions. Agent discovery, publication, or registry, including DNS-based mechanisms such as DNS-AID, may produce candidate Agent Identifiers; DN-ANR resolves and verifies the identifier selected by such mechanisms or by local policy. Within that scope, DN-ANR additionally defines DNS-based version distribution and deterministic version selection, canonicalized SVCB integrity cross- checking, and a signed HTTPS mirror for clients that cannot perform SVCB queries. While AI agents are the primary use case, the resolution and verification behavior defined here applies to any entity identified by an FQDN, such as services and workloads. | |||||||||||||
| draft-cui-idr-content-filter-flowspec-04.txt | ||||||||||||||
| Packet Content Filter for BGP FlowSpec | ||||||||||||||
|
The BGP Flow Specification enables the distribution of traffic filter policies (traffic filters and actions) via BGP, facilitating DDoS traffic filtering. However, the traffic filter in FSv1 and FSv2 predominantly focuses on IP header fields, which may not adequately address volumetric DDoS attack traffic characterized by fixed patterns within the packet content. This document introduces a new flow specification filter type designed for packet content filtering. The match field includes ptype, otype, offset, content-length, content, and mask encoded in the Flowspec NLRI. This new filter aims to leverage network devices such as routers and switches to support controlled traffic handling, traffic optimization, and mitigation of simple volumetric DDoS attacks, reducing the overall processing cost of carrier networks. | |||||||||||||
| draft-cui-idr-flowspec-feedback-roadmap-00.txt | ||||||||||||||
| Problem Statement and Roadmap for BGP FlowSpec Monitoring | ||||||||||||||
|
This document describes the problem space and roadmap for monitoring BGP Flow Specification (FlowSpec) deployments. It outlines the operational motivation for FlowSpec monitoring, identifies representative classes of monitoring information, and positions relevant work on FlowSpec, the BGP Monitoring Protocol (BMP), IP Flow Information Export (IPFIX), and YANG-based operational state within a common framework. The resulting roadmap provides common context for related protocol-specific work in the relevant IETF working groups. | |||||||||||||
| draft-cui-nmop-agent-sketch-com-00.txt | ||||||||||||||
| Operational Requirements for Network State Exchange in Agent-Assisted Network Operations | ||||||||||||||
|
This document describes operational requirements for exchanging network state in agent-assisted network operations. In this document, an agent-assisted system is any automation or decision- support system that consumes operational state to support tasks such as anomaly triage, incident correlation, configuration verification, traffic engineering analysis, or attack mitigation support. Such a system may use a large language model (LLM), a rule engine, a statistical model, or conventional software. The document focuses on operational problems created by high-volume telemetry, cross-domain state sharing, privacy constraints, approximate state summaries, and auditability of state used by automated workflows. It identifies requirements for compact, scoped, mergeable, bounded-error, incrementally synchronized, and auditable network state artifacts. The document complements existing NMOP work on anomaly detection, incident management, and YANG Push/message broker integration. It does not define a new network management protocol, a new agent communication protocol, or a wire format. | |||||||||||||
| draft-cui-nmop-auto-test-00.txt | ||||||||||||||
| A Framework for AI-Assisted Network Protocol Testing from Specifications | ||||||||||||||
|
Network protocol testing is essential for validating that implementations conform to their specifications. Traditional testing approaches rely heavily on manual effort or protocol-specific models that are expensive to build and difficult to reuse as specifications evolve and new protocols emerge. This document describes a framework for AI-assisted network protocol testing that decomposes the testing workflow into six stages: structured protocol representation, coverage scoping, test case generation, executable artifact generation, test execution, and feedback-based refinement. The framework emphasizes explicit stage boundaries and reviewable intermediate outputs, keeping the workflow auditable and traceable to the specification text. The document discusses the design motivations and trade-offs behind the framework, presents examples from routing protocol testing, and identifies operational considerations and open issues for applying the framework in test environments. | |||||||||||||
| draft-cui-nmrg-auto-test-02.txt | ||||||||||||||
| A Framework for AI-Assisted Network Protocol Testing from Specifications | ||||||||||||||
|
Network protocol testing is essential for validating that implementations conform to their specifications. Traditional testing approaches rely heavily on manual effort or protocol-specific models that are expensive to build and difficult to reuse as specifications evolve and new protocols emerge. This document describes a framework for AI-assisted network protocol testing that decomposes the testing workflow into six stages: structured protocol representation, coverage scoping, test case generation, executable artifact generation, test execution, and feedback-based refinement. The framework emphasizes explicit stage boundaries and reviewable intermediate outputs, keeping the workflow auditable and traceable to the specification text. The document discusses the design motivations and trade-offs behind the framework, presents examples from routing protocol testing, and identifies open research challenges. | |||||||||||||
| draft-cui-nmrg-llm-benchmark-02.txt | ||||||||||||||
| A Framework to Evaluate LLM Agents for Network Configuration | ||||||||||||||
|
This document specifies an evaluation framework and related definitions for intent-driven network configuration using Large Language Model(LLM)-based agents. The framework combines an emulator-based interactive environment, a suite of representative tasks, and multi-dimensional metrics organized in two layers: outcome metrics that verify functional correctness in a method-agnostic way, and agentic process metrics that assess reasoning quality and interactive command generation. Functional testcase results serve as the primary metric; command and reasoning scores act as diagnostic estimates against the task's ground truth configurations (which may include more than one validated solution), and optional efficiency metrics capture time and token cost. The framework aims to enable reproducible, comprehensive, and fair comparisons among network configuration approaches, covering both agentic and non-agentic solutions while highlighting capabilities specific to autonomous agents. | |||||||||||||
| draft-cui-nmrg-llm-nm-02.txt | ||||||||||||||
| A Framework for LLM Agent-Assisted Network Management with Human-in-the-Loop | ||||||||||||||
|
This document describes a reference framework for collaborative network management between Large Language Model (LLM)-assisted agents and human operators. Because network management actions can affect service availability, security posture, customer traffic, and compliance obligations, LLM-generated recommendations need to be validated, reviewed, and audited before they are applied to operational networks. The framework therefore focuses on human-in- the-loop control for safe, auditable, and operator-supervised use of LLM-assisted decision support in network operations. The document is intended to be compatible with existing network management systems and protocols while identifying research issues, rather than specifying a complete implementation of all LLM agent mechanisms. | |||||||||||||
| draft-curtis-myterms-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-cx-mpls-mna-inband-pm-09.txt | ||||||||||||||
| MNA for Performance Measurement with Alternate Marking Method | ||||||||||||||
|
MPLS Network Action (MNA) is used to indicate action for Label Switched Paths (LSPs) and/or MPLS packets, and to transfer data needed for the action. This document defines MNA encodings for MPLS performance measurement with alternate marking method, which performs flow-based packet loss, delay, and jitter measurements on MPLS live traffic. | |||||||||||||
| draft-cxx-ippm-ioamaggr-06.txt | ||||||||||||||
| Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) | ||||||||||||||
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. | |||||||||||||
| draft-cxxx-nmrg-ai4ibn-00.txt | ||||||||||||||
| Agentic AI for Intent-Based Networking | ||||||||||||||
|
This document specifies how the rise of agentic AI and LLMs can impact and and accelerate the transition towards Intent-Based Networking. Specifically, it revisits functionality and liefecycle in IBN, as defined in [RFC9315], and outlines how agentic AI and LLMs can be leveraged. | |||||||||||||
| draft-cz-bier-bgp-ls-bier-te-ext-07.txt | ||||||||||||||
| BGP-LS extensions for BIER-TE | ||||||||||||||
|
BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BGP Link-State (BGP-LS) enables the collection of various topology informations from the network, and the topology informations are used by the PCE to calculate the path and then propagate them onto the BFRs(instead of having each node to calculate on its own) and that can be for both inter-as and intra-as situations. This document specifies extensions to the BGP Link-state address- family in order to advertise BIER-TE informations. | |||||||||||||
| draft-czz-rtgwg-elastic-bandwidth-routing-00.txt | ||||||||||||||
| Elastic Bandwidth-aware Routing Framework | ||||||||||||||
|
IGP normally computes the shortest paths in a network for packet forwarding, without taking the traffic demands and available bandwidth into consideration. When there is a link degradation or partial link failure in a network which causes throughput reduction, or the volume of specific traffic flows increase dramatically, unexpected congestion may happen if only the shortest paths are used for IP forwarding. Conventional centralized Traffic Engineering (TE) focuses on long- term bandwidth and routes planning based on traffic demands, which can not react to the congestions in networks timely. This document describes a distributed path computation and load balancing mechanism named Elastic Bandwidth-aware Routing (EBR), which can alleviate congestions timely before TE finishes the global optimization. It allows IGP-enabled nodes which face congestion to distribute traffic among the shortest paths and load-balancing alternate paths through Segment Routing Traffic Engineering (SR-TE), with weights determined based on the bandwidth utilization and available bandwidth of these paths. It provides an efficient, accurate and backward compatible approach for dynamic link congestion avoidance. | |||||||||||||
| draft-dahm-tacacs-sshpk-00.txt | ||||||||||||||
| SSH Public Key Distribution for Device Administration using Terminal Access Controller Access-Control System Plus (TACACS+) | ||||||||||||||
|
SSH [RFC4251] provides a robust and reliable mechanism to connect to network devices for administration. Conventionally, the public keys required to authenticate SSH sessions are provisioned directly on the network devices. This document adds an extension to Terminal Access Controller Access-Control System Plus (TACACS+) to eliminate the need for the direct provisioning of SSH public keys onto the Network Devices. | |||||||||||||
| draft-daniel-ai-agent-internet-architecture-03.txt | ||||||||||||||
| Architectural Requirements for Supporting AI Agents on the Internet | ||||||||||||||
|
Autonomous AI agents are evolving from interactive assistants into networked software workloads that discover services, invoke tools, delegate authority, transact, communicate with other agents, and act asynchronously on behalf of humans and organizations. Existing Internet protocols provide strong foundations, but agent autonomy, dynamic delegation, machine-speed execution, long and unpredictable model-processing intervals, and cross-domain interaction create requirements that span multiple protocol families. This document describes architectural requirements for supporting AI agents on the Internet across naming and discovery, HTTP, authentication, authorization and delegation, TLS and workload identity, transport and connection continuity, asynchronous messaging, capability and intent-based resolution, payments, provenance, auditability, revocation, security, and privacy. It favors profiling and extending existing Internet protocols over defining a monolithic new agent protocol, and identifies the need for IETF-wide architectural coordination. | |||||||||||||
| draft-das-6g-query-scoped-communication-handles-06.txt | ||||||||||||||
| 6G-Era Communication Authorization-to-Reach: Separating Identifier Possession from Permission to Contact | ||||||||||||||
|
Many Internet and telephone communication systems treat possession of a routable identifier as sufficient to attempt contact. A telephone number, SIP URI, messaging handle, relay address, or marketplace contact reference can therefore remain a reusable reachability path after the purpose of disclosure has ended. Existing IETF and industry mechanisms solve related but different problems. STIR and SHAKEN authenticate or attest originating identity: they answer whether the calling party is who it claims to be, not whether that authenticated party currently holds bounded, purpose-scoped, revocable permission to reach a particular recipient. Virtual or masked numbers hide a persistent endpoint but commonly leave a substitute route active while the alias is valid. OAuth can express delegated API authorization. Spam scoring and call screening classify or reject an attempt after some path already exists. This document describes an authorization-to-reach model. A visible communication handle is not, by itself, permission to create a communication effect. A request is held as a candidate until current, purpose-scoped, revocable, and optionally consumable authority is validated. The document is informational. It asks whether the IETF Applications and Real-Time area should define interoperable semantics or an encoding for that authority (for example a PASSporT claim, a SIP header or pre-INVITE check, or a reusable authorization object). This work is not a 3GPP radio, core-network, or IMT-2030 architecture proposal. References to machine-scale or future-network traffic are motivational only. The intended protocol home, if any, is IETF work on SIP, STIR, messaging, and Internet communication identifiers. The motivation is nonetheless sharpened by the trajectory of upcoming 6G and IMT-2030 network infrastructure: as networks move toward AI- native architectures in which software agents, network functions, and third-party AI systems can originate signaling at machine speed, and as vendors including Qualcomm and Huawei publish AI-native 6G radio- and core-network research, an authorization-to-reach gap that is tolerable at human-initiated call volumes becomes structurally more significant at machine-originated volumes. Global telecom operators such as Deutsche Telekom, Orange, AT&T, and Vodafone -- among the carriers with the largest exposure to SIP, STIR/SHAKEN, and voice- messaging signaling volumes -- are named here only as illustrative examples of the operator community for whom an interoperable authorization-to-reach answer would be most directly relevant. This document does not depend on any particular 6G, IMT-2030, Qualcomm, Huawei, Deutsche Telekom, Orange, AT&T, or Vodafone architecture, deployment, or product, and does not assert that any of them has adopted, evaluated, or endorsed this proposal; it identifies why telecom infrastructure evolution makes the underlying Internet- identifier-layer question more urgent for IETF to consider now rather than after machine-scale traffic arrives. Google Maps, Apple Maps, and social or commerce platforms with map- adjacent or messaging-based business discovery features such as Meta Business (including Facebook and Instagram business discovery and messaging) are referenced elsewhere in this document family as recognizable illustrative examples of where a visible communication handle is exposed after discovery; no affiliation, endorsement, implementation, adoption, or technical alignment by Google, Apple, Meta, Qualcomm, Huawei, Deutsche Telekom, Orange, AT&T, Vodafone, or any other named provider is implied by this document. | |||||||||||||
| draft-das-actuation-bound-execution-finality-00.txt | ||||||||||||||
| Command Accepted Is Not Actuation Authorized: Execution Finality for Cyber-Physical and Industrial Control Systems | ||||||||||||||
|
Cyber-physical and industrial systems increasingly accept commands from cloud services, AI agents, remote operators, enterprise applications, and distributed control software. A high-consequence failure can occur even when identity, authorization, message integrity, platform attestation, and functional-safety mechanisms are individually correct: a digitally valid command can remain apparently acceptable while the target actuator, command parameters, machine mode, process state, safety/interlock state, authority state, or effectuation path has changed. The consequence is no longer merely an incorrect API call. It can be drive energization, robotic motion, valve or pump actuation, material release, process transition, or another physical effect. No token forgery, cryptographic break, or defeat of the safety protocol is necessarily required; the failure can be a loss of continuity between earlier digital authority and the exact physical act that becomes effective. Existing industrial mechanisms already solve major parts of this problem. IEC 61508 and IEC 61511 define mature functional-safety engineering and Safety Instrumented Systems; IEC 62443 defines cybersecurity requirements for industrial automation and control components; OPC UA provides industrial security mechanisms, while OPC UA Safety defines a functional-safety communication layer; ACE-OAuth [RFC9200] provides authorization for constrained IoT environments; RATS [RFC9334] provides trusted platform Evidence and Attestation Results; and existing safety PLCs/controllers from Siemens, Rockwell Automation, Schneider Electric, ABB, and other vendors provide mature safety logic and output control. These are complementary precedents, not examples of missing safety engineering. Where an existing safety controller or protected actuator boundary already makes exact command authority, current safety/process state, and final output mediation non-bypassable, that deployment already satisfies the core property described here. The residual gap exists only where one of those mechanisms stops at a boundary upstream of the first physical effect or does not carry the complete cyber-authority predicate required by the deployment. IEC functional-safety mechanisms can correctly enforce safety functions without necessarily expressing the provenance and exact scope of an AI-, cloud-, or enterprise-originated command. IEC 62443 controls can correctly protect identity, use, integrity, and information flow without by themselves defining the final application's exact actuation predicate. OPC UA Safety can correctly deliver SafetyData while the receiving safety application still determines whether a cyber-originated act is applicable. ACE can correctly authorize a constrained resource while current machine/process/safety state may be evaluated later. RATS can correctly attest the controller while platform trust is not authorization for a particular torque, motion, valve transition, or output. Current application-layer action- evidence work [SOKOLOV-AEP] can strengthen accountability while remaining distinct from pre-actuation non-completability. If any existing deployment already composes these properties at the true output boundary, no residual gap remains for that deployment. This document therefore proposes a narrower actuation-bound execution-finality invariant. A Candidate Act remains in a Non- Effective State until a protected Actuation Finality Boundary (AFB) verifies the exact pending command, current execution authority, target actuator identity, freshness and replay state, required current machine/process/safety predicates, and authorized effectuation path immediately before or atomically with the physical output becoming effective. The AFB is an architectural role, not a mandatory new appliance: an existing safety PLC, safety controller, protected drive, robot controller, SIS function, secure I/O stage, or device controller can already be the AFB when it enforces the required invariant. Prevention is claimed only where the protected physical effect cannot occur without those checks and where existing functional-safety controls remain authoritative rather than being bypassed or replaced. Execution-finality logic MUST NOT convert an existing safety DENY into ALLOW. If enforcement is upstream-only, mutable context is stale, path coverage is incomplete, or the mechanism merely records what occurred, the result is mitigation, detection, or auditability rather than the same prevention guarantee. The architecture complements functional safety; it does not replace hazard analysis, define a safe state, certify an unsafe controller, or claim that an IETF mechanism establishes SIL or PL. The problem is industrially relevant to robotics and motion control, process plants, manufacturing and warehouse automation, power and critical infrastructure, and other systems where remote or AI- generated commands can cross several cyber layers before becoming physical. Siemens Safety Integrated, Rockwell GuardLogix, Schneider Electric Modicon M580 Safety, ABB AC500-S, and OPC UA Safety are cited politely as mature safety precedents and potential integration points. No vulnerability, deficiency, non-conformance, affiliation, or endorsement is asserted. Criticism, corrections, counterexamples, prior art, real-time implementation experience, and evidence that existing safety or authorization mechanisms already provide the full invariant are explicitly invited. | |||||||||||||
| draft-das-agentic-execution-finality-02.txt | ||||||||||||||
| Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch in High-Risk AI Systems | ||||||||||||||
|
This architecture is specifically designed for high-risk AI systems, where standard engineering priorities shift from speed and latency toward absolute determinism and safety. An agentic model can emit a tool call that today's runtimes treat as something to execute. Allowlists, OAuth tokens, MCP server auth, sandboxes, output filters, and human approval decide whether an agent may reach a tool. They do not decide whether this generated call, with this argument digest, from this instruction chain, at this delegation depth, may take effect now. That gap is the incident surface. Prompt-injected content, poisoned retrieval, a malicious tool response, or a delegated sub-agent can produce a call that looks like ordinary tool use. If the dispatcher executes whatever the model selected, policy that lived upstream becomes advisory. This document specifies a dispatch-time gate. The model may compute a call. The call remains a Candidate Act. A Protected Enforcement Domain binds agent, tool, arguments, purpose, destination, provenance, and policy epochs, then issues scoped non-bearer authority. A Tool-Dispatch Finality Sink verifies that authority against the actual invocation immediately before the tool runs, then consumes it. The same gate applies to support, coding, payments, clinical, SOC, browser-use, and multi-agent MCP deployments. Tool selection is not execution authority. A runnable reference implementation for this dispatch-time gate is provided at tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP (https://github.com/sangmdas/ tool_use-Is-Not-invoke-Binding-Execution-Finality-to-Agentic-Tool- Call-Interfaces-and-MCP). | |||||||||||||
| draft-das-agentic-tool-binding-03.txt | ||||||||||||||
| tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP | ||||||||||||||
|
Frontier runtimes already standardized the dangerous moment. A model emits a tool_use block, a tool_calls array, or an MCP tools/call payload. The host then invokes whatever name and arguments the model printed. Alignment, allowlists, and OAuth sit around that moment. They do not sit on it. The consequence of this gap is no longer confined to email or payment demos. In defense, energy, grid control, industrial process control, and other critical-infrastructure deployments, the same tool_use block already reaches actuation-class systems -- logistics and targeting-adjacent decision support, SCADA and PLC interfaces, medical devices, autonomous platforms. In these environments, detection after the fact is not mitigation; it is an incident report written after the effect has already occurred. An agent that can act at machine speed but cannot be halted at machine speed is a system running without brakes: the first uncontrolled invocation is not a warning sign, it is the accident. Command authority, human oversight, and legal review all operate on human time. An unbound tool_use block operates on machine time. When those two clocks diverge, the gap belongs to whichever side reaches the effect first -- and today, nothing structurally guarantees that side is authorization. This document does not invent another assistant API. It binds the Agent Candidate Act profile [I-D.das-agentic] onto the three interface families those runtimes and their customers already ship: tool_use / computer_use style interfaces, function-calling and structured tool-response interfaces, and Model Context Protocol tools/call. The model may emit the block. The block remains non- effective. A local enforcer builds the act, binds the argument digest, and refuses invoke() until scoped authority is verified and consumed at the dispatch sink. For consequence classes above a defined threshold -- FINANCIAL, PHYSICAL, NETWORK_CONTROL, and any act reaching defense or critical- infrastructure actuation -- this binding treats fail-closed as the only conforming behavior: absent successfully verified, current, act- bound authority, the candidate act stays non-effective regardless of model confidence, prior session trust, or upstream alignment signal. Each enforcement decision, allow or deny, commits a Ledger-Anchored Validation Receipt (LAVR) -- a signed, hash-chained enforcement artifact bound to the specific candidate act and its argument digest at the moment of decision. An LAVR is not a log entry assembled afterward for audit; it is the proof that the finality boundary actually gated this act before any effect could occur, and its absence is itself a fail-closed condition. The implementation target is a middleware function that a host loop can call without changing the model vendor. tool_use is not invoke(). | |||||||||||||
| draft-das-ai-factory-silicon-finality-01.txt | ||||||||||||||
| Execution Finality for AI-Factory Silicon and Accelerated Infrastructure: Enforcement Profiles for GPUs,Chiplets,Memory Fabrics,DPUs,RDMA,CXL,and Photonic Boundaries | ||||||||||||||
|
AI factories and AI-native network infrastructure are becoming heterogeneous hardware systems rather than isolated model-serving applications. A single consequential operation may traverse CPU control planes, GPUs or NPUs, high-bandwidth memory, chiplets, coherent memory fabrics, CXL or PCIe paths, IOMMUs, DMA and RDMA engines, SmartNICs or DPUs, accelerator fabrics, model-serving runtimes, optical interconnects, storage systems, and physical power or cooling controllers. At these layers, a computation can be valid and a component can be authenticated while the resulting tensor transfer, memory exposure, queue activation, model load, routing change, optical emission, partition transition, firmware update, or physical actuation is still not authorized to become effective. This document describes a silicon-oriented execution-finality architecture for preserving that distinction. A consequential hardware or infrastructure operation is represented as a Candidate Act and remains in a Non-Effective State until a Protected Enforcement Domain establishes a machine-verifiable act descriptor, validates applicable authority predicates, updates or consumes protected state, and commits Protected Validation Evidence. A scoped non-bearer capability is then bound to the exact Candidate Act, relevant descriptor or digest, protected evidence, protected state, freshness and policy conditions, permitted scope, execution-finality boundary, and applicable Finality Sink. Possession of the capability alone is insufficient. The Finality Sink is the hardware, firmware, protected-runtime, fabric, controller, or adjacent enforcement role that has mandatory control over the consequence. Depending on the profile, it may be a memory controller, HBM gate, GPU scheduler, accelerator partition controller, IOMMU or SMMU, DMA or RDMA engine, DPU or SmartNIC, fabric switch, chiplet link controller, CXL component, cache- coherence controller, model loader, token-emission gate, optical modulator or wavelength controller, eFPGA configuration gate, rack power controller, or another protected effectuation point. The Candidate Act becomes effective only after sink-local verification confirms that the actual pending operation still corresponds to the validated act and current protected state. The document provides 83 detailed Enforcement Profiles. Sixty-three translate the supplied GPU, silicon, chiplet, memory-fabric, and AI- factory source set; twelve supplementary profiles map the same execution-finality model onto current hyperscale and Arm-based infrastructure directions; and eight additional profiles selectively adapt non-duplicative mechanisms from the companion DAS Protocols V, VI, and VIII disclosures for silicon and AI-factory use. The catalogue covers GPU and accelerator egress, rack-scale AI fabrics, sparse expert routing, coherent and disaggregated memory, collective communication, DPUs and SmartNICs, RDMA and GPU-direct access, model and KV-cache lifecycle state, accelerator partitioning, arithmetic- mode control, AI-factory scheduling, storage, telemetry, firmware, power and cooling, digital-twin actuation, in-network compute, federated-learning egress, neural-waveform release, silicon photonics, optical lanes and wavelengths, chiplet admission and UCIe control, CXL memory pools, RAS and memory quarantine, eFPGA configuration, reconfigurable optical accelerator topologies, accelerator-pod membership, compiler-to-silicon executable activation, confidential-realm memory ownership, secure device attachment, coherent-mesh admission, confidential offload-device attachment, network and storage offload queues, isolated management- controller actions, host-independent cloud-offload actions, UltraServer-scale accelerator-fabric membership, distributed EFA/RDMA endpoint admission, protected neural-state proofs, hardware-isolated shadow auditing, cross-committed collection-time and execution-time validation, attested measurement paths, distributed partial-share finality, separate compute-enable and produced-output authority, output-derived digest binding, and effectuation-enabling-resource withholding. Profile identifiers retain the source numbering for traceability; gaps are intentional. The architecture is intended to complement, not replace, existing work in accelerated computing, AI networking, confidential computing, chiplet and coherent-memory systems, accelerator fabrics, optical I/ O, attestation, authorization, and hardware isolation. In particular, the profiles are directly relevant to public technology directions associated with NVIDIA, AMD, Intel, Google, Amazon Web Services (AWS), Microsoft, Broadcom, Marvell, and Arm, whose current infrastructure spans GPUs and AI accelerators, custom AI silicon, high-bandwidth memory, CPU-to-accelerator coherence, chiplets, CXL and PCIe-class fabrics, DPUs and infrastructure offload, RDMA and high-speed AI networking, rack-scale accelerator systems, optical and silicon-photonic interconnects, hardware roots of trust, and large- scale AI-factory orchestration. Additional industry relationships with Qualcomm, Meta, Cisco, HPE, Nokia, Ericsson, Samsung, Huawei, AT&T, Verizon, Orange, and Deutsche Telekom are discussed in the body of the document where AI-native networking, RAN, 6G, edge compute, and operator-controlled infrastructure create related effectuation boundaries. These references identify technical complementarity and possible enforcement locations; they do not imply that any named organization has reviewed, endorsed, adopted, or lacks equivalent mechanisms. The IETF relevance is principally the cross-layer security relationship among identity, attestation, evidence, cryptographic binding, workload authorization, protected state, replay resistance, delegation, and the final effectuation boundary. The hardware protocols themselves remain within the remit of the appropriate hardware, semiconductor, telecommunications, optical, and system standards bodies. The common invariant is: computation may produce a Candidate Act, but computation is not authority for consequence. | |||||||||||||
| draft-das-ai-native-6g-execution-finality-03.txt | ||||||||||||||
| Execution-Finality for AI-Native 5G/6G and O-RAN | ||||||||||||||
|
In programmable and AI-assisted mobile networks, successful authentication of a network function or AI controller does not establish authority for every routing, signaling, session, resource- allocation, sensing, or subscriber-specific consequence that the function can generate. This document defines an informational execution-finality profile for AI-native 5G, 5G-Advanced, IMT-2030/6G, O-RAN, and AI-RAN environments. A proposed network operation is represented as a Network Candidate Act and remains in a Non-Effective State while a Protected Enforcement Domain validates act-specific predicates. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer finality authority. A Network Finality Sink at the enforcement boundary independently verifies that authority immediately before live network state changes. The governing rule is that network authentication is not network finality, and computation is not authority. This revision also defines a JSON interoperability profile for Candidate Acts, validation decisions, scoped authority, and sink verification. This profile is distinct from, and complementary to, present AI- native 6G industry roadmaps that focus on radio, sensing, and platform capability, including air-interface, MIMO, spectrum, and AI- RAN infrastructure work described in Qualcomm's public AI-native 6G platform material, and the broad native-trustworthiness and agentic- core-network architectures described in Huawei's public 6G security research. Those efforts address how a network becomes more intelligent, autonomous, and platform-trustworthy. This document addresses a narrower and later question: once an already- authenticated, already-policy-approved AI-generated network operation has been computed, whether that exact operation may become a live network consequence. The Candidate Act, Non-Effective State, Protected Enforcement Domain, and Finality Sink constructs defined here, as an explicit pre-effectuation gate with act-bound non-bearer authority and independent sink-side re-verification, are not established as an equivalent primitive in publicly reviewed material from those roadmaps. | |||||||||||||
| draft-das-attestation-interconnect-finality-00.txt | ||||||||||||||
| When Attestation Is Not Enough: Execution Finality for High-Assurance Resource Transitions | ||||||||||||||
|
Modern infrastructure increasingly allows memory, accelerators, device interfaces, storage regions, and other resources to move dynamically between hosts, tenants, virtual machines, and security domains. Existing mechanisms can authenticate devices, attest software and firmware state, protect communication, and authorize resource operations. However, these properties do not necessarily establish that the exact resource transition that becomes effective is still the transition that was evaluated and authorized. This distinction becomes security-critical when a change in addressability, ownership, routing, or device assignment itself exposes protected state. For example, a dynamically reassigned memory extent may become accessible to a new tenant even though the device is authentic and the transport is protected, if sanitization, ownership state, allocation generation, destination binding, or other required conditions are no longer valid at the moment of reassignment. This document describes an execution-finality model in which a proposed transition remains non-effective until a protected enforcement boundary verifies the concrete operation immediately before effectuation. Authorization is bound to the exact resource, source, destination, generation, security state, freshness conditions, and required preconditions, with replay and alternate- path protections. The problem is particularly relevant to high-assurance AI and composable-compute environments, including NVIDIA NVLink-based confidential multi-GPU systems, Arm Confidential Compute Architecture (CCA) and Realm Management Extension (RME) systems, UALink accelerator fabrics, CXL pooled-memory systems, and confidential- computing deployments operated by cloud providers. These names identify published industry directions and alignment points; they are not assertions that any named implementation is vulnerable or non- conformant. The model complements attestation, confidential computing, secure transport, and device-assignment mechanisms rather than replacing them. Its central security invariant is that a trusted component does not, by itself, imply a trusted transition. | |||||||||||||
| draft-das-child-safe-rendering-finality-04.txt | ||||||||||||||
| Preventing Unauthorized Adult and Age-Restricted Content Rendering to Children Through Hardware-Rooted Execution Finality | ||||||||||||||
|
Online child-safety controls commonly operate before the final rendering boundary. Platforms may use account-age flags, parental settings, content labels, recommender controls, server-side classification, age-assurance systems, access policies, or application filters to decide whether adult or age-restricted content should be available to a user. Those controls are important, but an upstream decision does not by itself guarantee that the content cannot later be decrypted, decoded, composited, rendered, forwarded, mirrored, or otherwise materialized through another software or device path. The practical motivation is also personal. As a father of three, I have encountered this same problem in my own family: a parent may understand that an unrestricted adult-configured phone should not be handed to a minor, yet a son or daughter may repeatedly ask to use the parent's phone and, in ordinary family life, the parent may eventually hand it over. Human affection, trust, convenience, and everyday family circumstances cannot simply be designed away. Existing age checks, parental controls, child profiles, and application restrictions are useful, but they do not necessarily provide a simple device-wide protection for this moment of handover. Requiring the adult to provide a fingerprint, facial verification, or other authentication for every individual video would also create an impractical user experience. This document therefore considers a Temporary Under-18 Handover Mode: before giving an adult-configured device to a child, the adult can place the device into a temporary minor-protection state, after which Execution-Finality makes that state technically consequential at the protected rendering boundary. This is therefore not only an abstract design problem for me; it is a solution developed to address a problem I encounter myself as a parent, with the broader aim of turning that everyday family difficulty into a practical protection that may also help other families. This problem is becoming more important as content delivery becomes more distributed, encrypted, AI-mediated, personalized, and dynamically generated. A modern device may receive content through applications, browsers, content-delivery networks, embedded web views, messaging clients, recommendation systems, generative-AI services, caches, cloud gaming or streaming pipelines, local AI models, or third-party SDKs. The security question is therefore no longer only whether content was classified or whether an age check occurred upstream. A later question must also be answered: is this specific protected content authorized to become perceptible to this recipient, on this device, under the current eligibility, policy, and revocation state, at this moment? This document defines a protected rendering execution-finality architecture for adult, pornographic, sexually explicit, violent, gambling-related, or otherwise age-restricted content. A proposed rendering is represented as a Restricted Content Candidate Act and remains in a Non-Renderable State until a Protected Enforcement Domain validates the applicable recipient, content, device, policy, age-or-eligibility, freshness, revocation, and sink predicates. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer Rendering Finality Authority. A Protected Rendering Finality Sink independently verifies that authority immediately before the content becomes perceptible. Depending on the implementation, the sink may control content-key release, decryption, media-decoder enablement, GPU or compositor access, protected-surface creation, audio output, casting, screen mirroring, display enablement, or an equivalent materialization boundary. Content bytes may therefore be delivered to a device while remaining technically non-renderable. The architecture deliberately does not define a universal age- estimation algorithm, identity system, or content-classification scheme. Those mechanisms may supply inputs to the Protected Enforcement Domain. This document defines the consequence-control step that prevents an upstream policy result from becoming merely advisory at the point of rendering. UNICEF has warned that pornographic content can harm children and that digital restrictions have not kept pace with technological shifts. The ITU Child Online Protection programme provides global guidance for safer digital environments, and the United Nations Committee on the Rights of the Child has called for protection of children from harmful content and online risks in the digital environment. The European Commission has likewise adopted protection-of-minors guidance and a privacy-preserving age- verification approach for adult-restricted content. These materials motivate the problem addressed here; they do not endorse this particular technical architecture. The central protocol principle is: permission to deliver content is not permission to render it. | |||||||||||||
| draft-das-composite-execution-finality-01.txt | ||||||||||||||
| Partial Commit Is Not Finality: Composite Candidate Acts Across Multiple Finality Sinks | ||||||||||||||
|
An agent, a payment orchestrator, or a control-plane applicator often intends one Candidate Act that would become real only as several consequences: a settlement post, a ledger write, a tool invoke, a notification, a radio enable. [DAS-HANDLE] specifies verify, consume, and receipt at one Finality Sink. It does not say what "the act was permitted" means when sink S1 has consumed and posted and sink S2 has rejected, timed out, or committed a different digest. Existing distributed-transaction tools already address adjacent problems. Two-phase commit, XA, sagas, TCC, transactional outbox, and workflow engines coordinate steps. OAuth, WIMSE, RATS, and SCITT still name identity, environment, and signed statements. None of them, by themselves, bind N sink-local Execution Handles to one composite Act Digest and require that no child consequence become externally effective unless every required child reaches a defined terminal state. This document specifies Composite Candidate Acts, child handles, a coordinator that may only prepare, a two-phase consume rule, and the distinction between prevention (no child commits unless the composite closes) and mitigation (compensate after a partial post). Compensation is itself a Candidate Act. It is not a silent undo and not a license to skip verify on the original child. The join is closed by a durable, linearizable Composite Decision Log holding one value per composite: empty, COMMIT, or ABORT, written only by compare-and-swap so that the first writer wins. The coordinator MUST win the log before sending a decision to any child. A prepared child whose reservation timer expires MUST consult the log: it commits if COMMIT is recorded, releases if ABORT is recorded, attempts its own compare-and-swap of ABORT if the log is empty, and holds its reservation (HOLD) only if the log is unreachable. No child acts on silence alone. This is not a new consensus protocol and not a claim that XA is obsolete. Profiles that cannot obtain prepare-from-every-sink, or cannot reach a durable linearizable decision log, MUST NOT claim all- or-none prevention. Three rejections are expected and are treated as design constraints. "Saga plus handle is enough" is accepted when each saga step already reconstructs the live child, consumes a child handle, and cannot log SUCCESS after a required child rejects; this draft then shrinks to join fields. Prepare across N sinks is a latency tax only if consume-state is global; it is per child handle, and a no_prepare mail or MCP child must use the mitigation profile rather than pretend 2PC. Child sinks reconstruct only their own pending effect, not a mesh-wide CAD. Reviewers who would reject on saga, performance, or reconstruction grounds are asked to read those sections before discarding the document. Criticism, including "this should stay a note in the handle draft," remains invited. | |||||||||||||
| draft-das-consequence-path-completeness-00.txt | ||||||||||||||
| When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality | ||||||||||||||
|
A perfectly correct authorization or security gate does not prevent a protected consequence if the same effect remains technically reachable through another path. High-consequence systems commonly place authentication, authorization, policy, attestation, or execution-finality checks at identified API, gateway, Resource Server, operating-system, service-perimeter, or hardware boundaries. The vulnerability examined here is therefore a coverage failure: the protected gate can be sound while the effect can go around it. This deserves high attention where the bypass can produce irreversible, financial, safety-relevant, privacy-sensitive, sovereign, or mission- critical consequences. Existing security architecture already addresses important parts of this problem. The reference-monitor concept requires complete mediation, tamper resistance, and verifiability; OAuth Resource Servers validate authorization for requests they receive; gateways, service meshes, cloud policy systems, and service perimeters mediate configured flows; RATS provides trust evidence for components; and confidential-computing or hardware isolation can provide protected enforcement locations. If any existing mechanism actually mediates every route capable of producing the defined consequence under the stated threat model, that deployment already satisfies the core property described here and no additional component is required merely for duplication. The residual problem arises when enforcement coverage is narrower than the consequence: for example, when an approved API hands work to a queue or database with other ingress paths, a service perimeter covers selected services while another interface remains effect- capable, or a software gate coexists with administrative, recovery, device, DMA, storage, or management-plane routes. This document introduces a consequence-oriented execution-finality formulation: a Protected Consequence K, an Effectuation Domain D, a generation- indexed directed Effectuation Graph G_g, an Effectuation Path Set P_g(K,D), a Finality Cut Set F, and a protected Path-Set Generation g. Prevention is claimed only when removal of the valid enforcement set F disconnects every admissible source from the consequence node, every member of F enforces an equivalent load-bearing finality predicate, and topology changes cannot silently inherit an older completeness claim. Where path discovery is incomplete, enforcement is bypassable, topology state is stale, or only selected interfaces are covered, the mechanism is mitigation or detection rather than the same prevention guarantee. The model is relevant to AI-agent tool execution, cloud authorization, service meshes, financial and database commits, operating-system and device actions, confidential computing, accelerator/DPU/SmartNIC infrastructure, and industrial control. Microsoft Azure Policy, Amazon Verified Permissions/Cedar, Google Cloud VPC Service Controls, NVIDIA attestation, and Arm CCA are cited only as complementary industrial comparison or integration points, not as assertions of vulnerability, deficiency, non-conformance, affiliation, or endorsement. The proposed delta is not invention of complete mediation. It is an explicit, testable mapping of complete-mediation reasoning to a protected consequence across heterogeneous distributed software and hardware paths, with coverage bound to a topology generation and to effectuation-time finality. Criticism, corrections, counterexamples, prior-art pointers, evidence of equivalent existing mechanisms, and cases where path completeness cannot be established at acceptable cost are explicitly invited. | |||||||||||||
| draft-das-cvid-enforcement-profiles-00.txt | ||||||||||||||
| Capability-Validated Inbound Descriptors: Catalogue of Enforcement Profiles | ||||||||||||||
|
A destination identifier, an API credential, a completed computation, and an attested execution environment are each routinely treated as if they carried authority for consequence. This document argues that none of them does, and catalogues fifty-nine enforcement profiles of the Capability-Validated Inbound Descriptor (CVID) architecture, in which an attempted act is a Candidate Act with no external effect until a protected enforcement domain validates a conjunctive predicate set and releases the capability the effect requires. The profiles span inbound communication; network capability exposure and intent-driven network programming; AI-native radio access, network slicing and packet core; distributed inference and digital twins; ultra-reliable low-latency operation; cross-border and sovereignty-bound execution; satellite, non-terrestrial and direct- to-device networks; optical inter-satellite links; immersive and semantic media; machine swarms; ambient IoT and backscatter; reconfigurable intelligent surfaces; device paging and wake; offline central bank digital currency settlement; lawful disclosure through escrow; platform neutrality measurement; network energy expenditure; and enforcement in silicon at accelerator output paths, DMA and RDMA boundaries, interconnects, and die-to-die interfaces. Three authorities commonly conflated are separated: authority to consume resources, authority to compute, and authority to cause an external effect. From that separation follows the treatment of energy as an enforceable security resource rather than only an efficiency metric, with a low-energy admission tier deciding whether a candidate may activate expensive baseband, accelerator, or radio paths at all. The document compares this position with published 6G energy work from Ericsson, Nokia, Qualcomm, and Huawei, states what the author believes is new, and sets out the limitations of the approach. Profiles are reproduced in the structural form in which they were drafted, including system and method variants of the same mechanism. The architecture itself, its terminology, and its protocol mappings are described in a companion document. This document is published for discussion and comment; it is not a product of an IETF Working Group, and corrections are invited. | |||||||||||||
| draft-das-digital-sovereignty-finality-02.txt | ||||||||||||||
| When Data Leaves Its Originating Jurisdiction,Who Controls It? Digital Sovereignty Without Data Localisation by Separating the Compute Plane from the Authority Plane | ||||||||||||||
|
Consider a simple case: data concerning U.S. citizens is processed in infrastructure located outside the United States. The foreign jurisdiction may have its own lawful-access, surveillance, disclosure, retention, or national-security rules. Even where contractual commitments, privacy policies, regional settings, or enterprise agreements specify how that data should be handled, the infrastructure executing the workload may ultimately operate under legal and technical authority outside the originating jurisdiction. The same problem applies in reverse to European, Indian, Japanese, Canadian, Australian, or other data processed through globally distributed infrastructure. This creates a deeper architectural problem than ordinary data localisation. If control over data automatically follows the physical location of compute, then moving computation across borders can also move practical authority over the resulting data, operations, and disclosures. Privacy may be the first concern, but the same architectural dependency can later affect economic security, critical infrastructure, sensitive enterprise information, government workloads, and national security. This is where policy alone begins to reach its limit. Contracts, privacy policies, adequacy mechanisms, access-control rules, cloud-region settings, and audit requirements remain important. However, they primarily describe what an actor is permitted or expected to do. They do not necessarily create a technical condition that prevents a prohibited external effect from occurring in the first place. Although this document uses the term "digital sovereignty," it does not attempt to standardize national policy, determine which jurisdiction's law should prevail, or prescribe where data must be stored. Its focus is technical: defining an interoperable mechanism by which deployment-selected policy and trust inputs can be bound to a specific Candidate Act and enforced at the effectuation boundary before that act becomes externally effective. In this document, "sovereignty" therefore refers to retained execution authority, not to the standardization of geopolitical or regulatory policy. The architecture described here addresses this problem through a different model of digital sovereignty: separate the Compute Plane from the Authority Plane. The Compute Plane may remain globally distributed. Data may be stored, transformed, analysed, routed, or processed using infrastructure located in another jurisdiction. The architecture therefore does not require that all data remain physically local, nor does it assume that sovereign computing requires complete national isolation from global cloud, telecom, AI, or platform infrastructure. Instead, the Authority Plane remains independently governed. A remote compute environment may perform computation, but computation alone does not grant authority to produce a protected external consequence. A proposed cross-jurisdiction operation is represented as a Candidate Act and remains in a Non-Effective State until the required policy, identity, purpose, destination, jurisdiction, runtime, revocation, and other applicable predicates have been validated. Protected validation may produce a LAVR or equivalent validation commitment and a scoped Finality Authority bound to the particular Candidate Act. At the relevant Finality Sink — the first point at which the protected operation would become externally effective — the authority is independently verified. Only after successful verification and appropriate consumption or reservation of that authority may the external effect occur. The resulting model is therefore: Compute Anywhere -> Authority Remains Independently Governed -> Candidate Act -> Protected Validation -> Scoped Finality Authority -> Finality-Sink Verification -> External Effect. If the required authority is missing, stale, revoked, mismatched, replayed, or inconsistent with the governing jurisdictional policy: No Valid Authority -> No Protected External Effect. This permits a form of digital sovereignty without mandatory data localisation. A jurisdiction, enterprise, regulated institution, or other authorised policy owner does not necessarily need to operate every processor, cloud region, network, or AI system that performs the computation. Instead, it can retain technical control over the conditions under which specified externally effective acts are permitted. The architecture therefore separates two questions that are commonly treated as one: Where is the computation performed? Who has authority over the resulting external effect? Those questions need not have the same answer. A U.S. workload could execute outside the United States while specified sensitive external effects remain subject to U.S.- controlled or enterprise-controlled authorization conditions. An EU workload could similarly use infrastructure outside a particular Member State while retaining independently governed finality requirements. The same mechanism could apply to India, Japan, Singapore, Australia, Canada, multinational enterprises, sovereign clouds, regulated industries, or private data spaces. The architecture does not prescribe which country's policy should prevail and does not attempt to resolve conflicts of law. Its contribution is narrower and technical: cross-border computation does not have to imply cross-border surrender of execution authority. This turns digital sovereignty from a primarily location-centred concept into an authority-centred execution model. The objective is not to fragment the Internet or exclude global technology providers. On the contrary, separating the Compute Plane from the Authority Plane could allow hyperscale cloud providers, AI platforms, telecom operators, CDNs, satellite networks, and other global infrastructure providers to continue supplying efficient distributed computation while supporting stronger jurisdiction-specific, enterprise-specific, or regulated execution guarantees. In this model, sovereignty does not require saying that the data must never leave. It can instead mean: the computation may occur elsewhere, but this protected external effect cannot occur without the required authority. That is the central architectural proposition of this document. | |||||||||||||
| draft-das-ef-registries-01.txt | ||||||||||||||
| Illustrative Codes Are Not a Namespace: Registries for Execution-Finality Consequence Classes,Sink Types,Act Types,Failure Codes,Profiles,and Media Types | ||||||||||||||
|
The execution-finality family uses a shared vocabulary: Candidate Act, Execution Handle, Finality Sink, consume, and Finality Receipt [DAS-HANDLE] [DAS-PROTOCOL]. Each profile currently invents overlapping labels for the same ideas — FINANCIAL, SETTLEMENT, EF- 005, SINGLE_USE — and then states that the codes are illustrative and not IANA assignments. Two implementations can therefore emit the same token string with different meaning, or different strings for the same deny reason. Existing IANA registries already name adjacent objects. JWT and CWT claim names [RFC7519] [RFC8392], OAuth parameters [RFC6749] [RFC7591], HTTP problem types [RFC9457], media types, RATS EAT claims, and SCITT statement types [RFC9943] solve identity, token, and transparency naming. They do not allocate consequence class, sink type, act type, handle reuse policy, execution-finality failure code, or finality-profile identifiers. This document proposes those registries and an initial allocation drawn from the family drafts. It does not decide which acts should be authorized. It does not replace OAuth error codes, HTTP status codes, or application problem types. A registered code is a shared name for a machine-readable condition; it is not a legal classification and not evidence that any named product implements the condition. Until IANA action occurs, codes in this document and in companion drafts remain provisional. Implementations MUST treat foreign namespaces as distinct. Criticism of the registry split, the initial code list, the registration policy, and the claim that a new namespace is required at all is explicitly invited. | |||||||||||||
| draft-das-enterprise-ai-enforcement-profiles-00.txt | ||||||||||||||
| Securing the Enterprise Future: Technical Non-Joinability for Enterprise AI | ||||||||||||||
|
Enterprise artificial-intelligence systems are increasingly connected to multiple organizational repositories, applications, tools, memory systems, and workflow interfaces. Representative industrial deployment classes include OpenAI ChatGPT and ChatGPT Work, Anthropic Claude, Google Gemini Enterprise, xAI Grok for Business, Microsoft Copilot and Copilot Studio, Amazon Q Business, Salesforce Agentforce, ServiceNow AI Agents, and comparable enterprise or privately deployed AI systems. These names are cited only as publicly described examples of the broader deployment class. Their inclusion does not assert that any named product implements, lacks, requires, infringes, endorses, or is vulnerable to the mechanisms described here, does not characterize undisclosed internal architectures, and does not imply that equivalent functionality is absent from an existing product or specification. The security problem considered here is not limited to theft of a pre-existing database. An enterprise-AI workload may be individually authorized to retrieve information from customer, engineering, financial, source-code, supplier, scheduling, communication, memory, and operational systems while the combination of those sources reveals a sensitive relationship or future enterprise state that no single repository contains. Conventional access control, encryption, network segmentation, database separation, confidential computing, and source-level authorization remain important, but storage separation alone does not prevent such reconstruction where the same effective authority can obtain the constituent values and freely resolve the relationships among them. The mechanism described here therefore separates not only protected data but also the authority required to create protected semantic relationships among that data. Identity components, substantive content, relationship-mapping information, reconstruction-enablement state, and authorization state may be maintained under independently controlled protection domains. A processing request establishes a bounded reconstruction authorization tied to the actual workload, execution context, session, permitted fields, permitted relationships, processing purpose, and output conditions. Each required protection domain independently determines whether its component may participate. Approved components may remain session bound, cryptographically wrapped, capability restricted, opaque, or accessible only through a mandatory mediated path. Only the specifically authorized relationships are resolved inside a protected reconstruction environment, which constructs a temporary minimum- necessary view without providing the AI workload with unrestricted authority over the underlying stores. This creates a technical distinction between authority to access information and authority to associate information. Access to an identity component and access to a content component do not, by themselves, authorize every relationship between them. The same distinction applies after computation: successful reconstruction, inference, or generation does not automatically authorize disclosure, persistence, transmission, tool invocation, database modification, payment, downstream-model use, or another external consequence. A resulting output or proposed act can remain technically non- releasable while current session, execution, association, provenance, destination, recipient, policy, revocation, and disclosure conditions are verified. Protected evidence of successful verification is committed before scoped release authority is created and checked at the actual consequence boundary. This document presents 79 Enforcement Profiles that apply the same underlying architecture to different enterprise-AI enforcement points, including multi-domain information separation, independent association authority, session-bound reconstruction, protected provenance, runtime behavioral verification, agentic tool invocation, prompt and input mediation, streaming disclosure, lifecycle restrictions, distributed policy enforcement, and multi-authority consequence control. Each profile is expressed in terms of the problem being addressed, the technical enforcement mechanism, and its relationship to existing technology so that the underlying engineering concept can be evaluated independently of specialized terminology. This document is related to the earlier [DAS-ENTERPRISE-OUTPUT], which introduced the broader enterprise-future-reconstruction threat, protected reconstruction, and output-finality architecture. The principal new contribution here is the systematic decomposition of that architecture into 79 concrete enforcement profiles, together with a more explicit treatment of Technical Non-Joinability as a separately enforceable property governing when independently accessible enterprise information may be semantically associated. The common engineering principle is that access to components is not necessarily authority to join them, and completion of computation is not necessarily authority to make the resulting consequence externally effective. | |||||||||||||
| draft-das-enterprise-ai-output-finality-03.txt | ||||||||||||||
| The Missing Piece for High-Value Confidential Enterprise AI: Non-Joinable Vaults and Output-Release Finality for Banking,Defence,and Public-Sector Deployments | ||||||||||||||
|
This profile is specified for high-risk, multi-system enterprise and public-sector AI — assistants and agents that can see several independently authorized stores and then send, write, or invoke. It is not specified for consumer chat. In industrial terms that describes enterprise assistant and agent seats of the kind offered by Anthropic, OpenAI, Google Gemini, and xAI Grok, together with self- hosted open-weight deployments; these names are used with respect, as publicly described deployment classes only, and imply no claim about any vendor's internals and no vendor endorsement of this profile. A 2020 breach stole what was already stored: a server image, a database dump, user rows. After 2025 a compromised assistant can do what a dump cannot. In minutes it can join mail, tickets, code, finance, and memory into a map of launch plans, targets, defects, and negotiation room — strategy that was never one record — and that map can be sold to a competitor. There is no credential rotation for a future that has already been read. Traditional access control still answers who may touch each store. It does not answer whether those fragments may be joined into that meaning, or whether that meaning may leave. This document specifies an architectural framework and metadata profile for that gap. Technical Non-Joinability is enforced by a session-bound Reconstruction Authorization Object (RAO) that limits relational binding. Technical Non-Completability is enforced by an Output Release Boundary that requires committed validation evidence before a generated token or tool invocation can take external effect. The specification defines the authorization objects, cryptographic bindings, and boundary validation sequences required to isolate reconstruction domains without modifying the underlying datastores. A published runnable reference implementation is provided so that the profile can be executed and tested, not only read as theory. That implementation is an architectural reference for the state machine, not a claim of production isolation. The architecture introduces bounded evaluation on the path that can intercept unauthorized join or release. That latency is accepted where the asset is high- consequence enterprise or public-sector intelligence and raw speed is subordinate to preventing reconstruction and release. The author states that trade-off explicitly: this profile is for deployments that choose that priority. It is not offered as a design for consumer chat or other paths that optimize only for speed. Readers are respectfully encouraged to review Section 4 and Section 5 in full, as those sections set out the complete problem description and motivating scenarios and should not be skipped. | |||||||||||||
| draft-das-eu-ai-act-execution-enforcement-02.txt | ||||||||||||||
| Technical Enforcement of the EU AI Act and Global AI Laws for High-Risk AI Systems Without Relying on Paper Policies | ||||||||||||||
|
This architecture is specifically designed for high-risk AI systems, where standard engineering priorities shift from speed and latency toward absolute determinism and safety. The European Union Artificial Intelligence Act establishes an extensive paper-based governance regime for artificial intelligence: risk-management documentation, data-governance records, conformity assessments, human-oversight instructions, transparency notices, logging obligations, and post-market monitoring plans. These instruments are necessary, and this document does not propose to discard them. They are not, however, sufficient by themselves once an AI system can autonomously or semi-autonomously act at machine speed, because a document can only describe what an operation should do; it cannot, by itself, make an operation technically incapable of doing otherwise. This is not a problem unique to the European Union. South Korea's AI Basic Act regulates "high-impact AI" through comparable risk- management, human-oversight, and documentation duties. Japan's AI Act, in force since September 2025, takes a lighter, more promotion- oriented approach but still assumes that written governance is the primary control. China enforces a binding but differently structured set of algorithm-recommendation, deep-synthesis, generative-AI, and AI-content-labelling rules. Texas and Colorado have each enacted state-level AI statutes in the United States with disclosure and consequential-decision obligations, and Brazil's PL 2338/2023 and Canada's lapsed AIDA proposal show the same EU-style risk-based model spreading, whether or not yet enacted. Every one of these regimes, whatever their legal differences, shares the identical underlying engineering gap this document addresses: a written rule, however well drafted, does not by itself make a machine unable to break it before anyone can react. The gap is most consequential precisely where the stakes are highest. In defence-relevant AI, critical-infrastructure control systems, and satellite or space-system automation, an autonomous agent can select a target, reroute power or water, transfer control of a physical asset, or transmit a command to an orbital platform within a single inference cycle -- before any operator, reviewer, regulator, or after-the-fact investigation can intervene. If that act causes harm, two questions follow immediately: who is liable, and at what cost. A risk-management file, a conformity-assessment certificate, or an audit log written after the fact can show that a rule existed; none of them can show that the machine was technically incapable of breaking it, and none of them limits the cost already incurred by the time the record is examined. For these classes of system, the appropriate default when an authorization cannot be verified is not "log it and investigate later"; it is fail-closed: the act simply does not occur. This document describes an execution-finality architecture that converts a selected, already-determined AI-governance requirement from a document into a mandatory, machine-verifiable precondition of the AI-generated operation itself. A consequential AI-generated operation is first represented as a Candidate Act and is held in a Non-Effective State -- technically incapable of invoking a tool, actuating a device, transmitting a command, or otherwise causing an external consequence -- until a Protected Enforcement Domain validates the machine-readable constraints applicable to that exact act, including the AI system identity, permitted operation, target, recipient, destination, required human-oversight state, transparency marker, risk-control status, policy epoch, and revocation state. Successful validation produces narrowly scoped, act-bound effectuation authority; a Finality Sink positioned at the point of first usable external effect independently re-verifies that exact authority, and the current required state, immediately before the consequence is permitted to occur. Absent, stale, revoked, or unverifiable authority results by default in no effect, not in a warning. The same architecture accepts a jurisdiction-specific governance profile as an input, so that an EU AI Act profile, a Korean AI Basic Act profile, or another national profile can each supply the machine-readable constraints for the identical enforcement mechanism without this document taking a position on how those laws relate to one another. This document does not determine whether an AI system is legally high-risk under Annex III, whether a practice is prohibited under Article 5, whether a conformity assessment is valid, whether human oversight under Article 14 is legally sufficient, or whether an organisation complies with the Regulation as a whole, nor does it make any equivalent determination under another jurisdiction's law. Those determinations remain outside the protocol and must be made by the responsible legal, regulatory, or organisational authority. This document addresses the narrower engineering problem that arises only after such a determination has already been made: once an applicable governance requirement has been translated into a machine-readable constraint, how can satisfaction of that constraint be made technically necessary before the corresponding AI-generated consequence becomes effective? This document does not advocate replacing paper-based AI governance for general-purpose or low-consequence AI applications, where the cost and rigidity of execution-level enforcement would be disproportionate to the risk. The architecture is proposed specifically for high-criticality AI deployments -- defence and dual- use systems, critical infrastructure, satellite and space systems, and comparably consequential autonomous or agentic systems -- in which an unauthorised act is not merely a compliance finding but a matter of physical safety, national security, or irreversible loss, and in which liability and cost must be bounded by making the unauthorised act technically non-completable rather than merely detectable afterward. Cross-regime use is treated as a profile-input problem rather than as legal harmonisation. An EU AI Act profile, a South Korean AI Basic Act profile, a Japanese AI Act profile, or another national, sectoral, or contractual profile can each supply machine-readable constraints to the same Candidate Act / Protected Enforcement Domain / Finality Sink mechanism. Where profiles are compatible, the effective authority is their intersection; where they conflict, the act remains unauthorised by default pending an external legal or organisational determination. That is the maximum interoperability claim this document makes: a shared enforcement substrate, not equivalence of laws, not a conflict-of-law solver, and not a finding that any listed regime is legally sufficient or interchangeable. A primary public reference implementation accompanies this document at https://github.com/sangmdas/Execution-Finality-Technical- Enforcement-for-EU-AI-Act-and-AI-Governance-Constraints (https://github.com/sangmdas/Execution-Finality-Technical- Enforcement-for-EU-AI-Act-and-AI-Governance-Constraints). It is a runnable engineering reference for the substrate and selected AI- governance predicates (human-approval binding, runtime evidence, delegation bounds, bounded offline mode, policy-epoch revocation, and profile intersection). It is not a legal-compliance product, not a certification, and not evidence that any deployment using it complies with the EU AI Act or another law. Reviewer questions that recur in this series -- cross-regime generalisation, deterministic runtime bounds for dynamic agentic plans, interaction with Article 14 human oversight, and audit responsibility -- are collected as frequently asked questions in Section 43. Trust-boundary, insider-approval, sink-failure, delegation, liability, and residual-limitation questions are treated as a threat model and operational caveat set in Section 44 and Section 38. Those sections state what the architecture can and cannot claim. Independent technical and legal criticism is invited; the author would rather have the limits of execution-finality found in review than have them discovered after a protected effect has already occurred. | |||||||||||||
| draft-das-execution-finality-ai-boundary-00.txt | ||||||||||||||
| An Execution Interlock at the AI Model-to-External-Effect Boundary | ||||||||||||||
|
An AI system's ability to compute an operation is not the same as authorization for that operation to take effect outside the system. This document defines an enforcement boundary at which an operation produced by an AI system is verified against the effect it will actually produce, rather than against the effect that was requested or approved upstream, and specifies that the operation carries no external consequence until that verification succeeds. The boundary is complementary to alignment, sandboxing, monitoring, and interpretability, which reduce the likelihood that an unsafe operation is produced. This document addresses the separate question of what prevents a produced operation from becoming effective. The mechanism functions as a safety interlock: it does not restrict what the system may compute, only whether a specific computed operation may take effect. The invariant is that computation is not authority. | |||||||||||||
| draft-das-execution-finality-ai-interoperability-04.txt | ||||||||||||||
| Secure and Privacy-Preserving AI Interoperability under Article 6(7) of the European Digital Markets Act: An Execution-Finality Architecture | ||||||||||||||
|
This document presents a security- and privacy-preserving execution- finality architecture for third-party AI interoperability under the European Digital Markets Act (DMA). It is designed to enable meaningful participation by external AI assistants while keeping consequential device actions under bounded, verifiable platform control. The architecture separates an AI-generated request from the authority to make that request externally effective. A requested operation remains in a Non-Effective State until protected infrastructure validates the requester, intended resource, destination, user authorization or intent where required, purpose and scope, freshness, revocation state, runtime conditions, and other applicable policy predicates. After successful validation, the system creates narrowly scoped, non- bearer execution authority bound to the specific Candidate Act. At the Finality Sink—the first boundary at which the operation can become externally effective—the system independently verifies that the actual operation still matches the validated act and that the authority remains current and unused. This design is intended to address major security risks associated with AI interoperability, including prompt injection, compromised assistant or cloud infrastructure, confused-deputy behavior, replay, token theft or reuse, destination or parameter substitution, scope escalation, stale authorization, alternate-path bypass, and unauthorized consequential execution. It also supports privacy protections by limiting access and effectuation to the minimum act-specific scope, reducing dependence on broad reusable permissions, preserving revocation and user-control boundaries, and preventing data release or transmission when the protected validation conditions are not satisfied. The resulting model is open participation with bounded, verifiable authority: third-party AI systems may interoperate with device functions without receiving unrestricted final-effect authority, while the platform retains protected enforcement over whether a proposed action is permitted to become externally effective. The length of this document is intentional. It aims to work through the major security- and privacy-related objections associated with third-party AI interoperability at a technical level of detail sufficient to show that they are addressed, rather than merely asserted, and reviewers are welcome to engage with any section on its own merits. In June 2026, Apple announced that it would not ship its new Siri AI on iOS 27 and iPadOS 27 in the European Union, stating that EU regulators had not accepted its proposed interoperability safeguards and that granting third-party assistants access equivalent to Siri's created unacceptable security and privacy exposure. The European Commission responded that nothing in the DMA itself required Apple to withhold the feature, describing Apple's decision as a voluntary business choice rather than a legal necessity, and noting that Apple had requested a blanket exemption rather than submitting a compliant technical mechanism. Both positions are correct within their own frame: Apple's underlying security concern about undifferentiated third-party system access is real, and the Commission is also correct that the DMA does not itself compel a trade-off between interoperability and security. This document's execution-finality architecture is offered as the middle solution by which both can be satisfied simultaneously: third-party AI assistants gain the interoperability the DMA requires, while the platform retains the bounded, verifiable finality control that Apple's objection is actually about. To show this is not only a theoretical proposal, a runnable reference implementation of this architecture has been published, demonstrating how the design behaves end to end in a virtual/test environment (note: behavior and measurements in an actual production environment may differ). A note for reviewers: the length of this document is deliberate. More than sixty technical questions are answered in question-and- answer form, covering anticipated security, privacy, deployment, and standardisation objections as well as performance, scalability, and hardware enforcement. To show that the architecture is intended to be implementable and not only a paper proposal, two runnable open- source reference implementations are also referenced: the initial demonstrator, and an adversarially hardened follow-on that adds live challenge-bound finality, strict object verification, cross-object consistency checks, and 100 executable tests. The latest implementation is available in the Hardened Challenge-Bound Execution-Finality Reference Implementation repository (https://github.com/sangmdas/Hardened-Challenge-Bound-Execution- Finality-for-AI-Interoperability). Both implementations were exercised in a virtual/local test environment, and actual readings may vary in separate environments; they are offered as evidence of engineering feasibility rather than as production-certified software. Critical review of both the document and the code is sincerely welcomed. | |||||||||||||
| draft-das-execution-finality-enforcement-profiles-01.txt | ||||||||||||||
| Execution Finality at External-Effect Boundaries: Enforcement Profiles for 6G,AI-Native RAN,RF,ISAC,Accelerated Compute,Devices,and Autonomous Systems | ||||||||||||||
|
AI-native and autonomous infrastructure is increasingly able to generate, optimize, schedule, route, transmit, disclose, render, allocate, encrypt, modify network state, control radio resources, and initiate physical or machine actions without a human decision at every step. An agentic AI system may generate a tool call or machine instruction; an AI-native RAN may compute a beam, handover, power, spectrum, routing, slicing, or topology change; an integrated sensing and communication (ISAC) system may generate sensing information for release or fusion; an O-RAN xApp or rApp may generate a network- control instruction; an accelerator may produce a routing, scheduling, inference, or resource-allocation result; or an autonomous controller may prepare a cyber-physical actuation. Successful computation, authentication, attestation, access authorization, credential possession, or execution inside a trusted environment does not, by itself, establish authority for the resulting operation to become externally effective. This document describes a protected execution-finality architecture in which that distinction is machine-enforced. A proposed consequential operation is represented as a Candidate Act and remains in a Non-Effective State while a Protected Enforcement Domain establishes a machine-verifiable act descriptor, validates applicable machine-verifiable authority predicates, and performs, consumes, advances, or references applicable protected state. The resulting state is represented by an applicable protected-state representation, and Protected Validation Evidence is committed before, or atomically with, authorization of availability of a scoped non-bearer capability. The capability is machine-verifiably or cryptographically bound to the specific Candidate Act, the act descriptor or its digest, the committed validation evidence, applicable protected state, freshness constraints, permitted effectuation scope, the relevant execution-finality boundary, and the applicable Finality Sink. The Finality Sink is positioned at or before the point at which the Candidate Act would first acquire an externally meaningful consequence. Before effectuation, the Finality Sink performs a machine-enforced capability-validity check and permits the Candidate Act to cross the execution-finality boundary only when the required bindings, protected state, validation evidence, freshness conditions, and effectuation scope remain valid. Absence, expiry, revocation, exhaustion, replay, staleness, mismatch, timeout, unverifiability, indeterminacy, scope failure, binding failure, or failure of a required preceding protected operation causes the architecture to fail closed, leaving the Candidate Act non-effective. The document provides 132 detailed Enforcement Profiles that instantiate this common architecture at materially different consequence boundaries. The profiles cover agentic AI tool calls and machine instructions; AI-native RAN and RF control; integrated sensing and communication (ISAC); sensing-result, location, telemetry, and metadata release; restricted-content delivery, decryption, decoding, recommendation, and rendering; derivative, transformed, synthetic, and AI-modified content; VPN, proxy, encrypted-DNS, encrypted-session, and tunnel establishment; cyber- physical, robotic, vehicle, industrial, and actuator control; network exposure, CAPIF, northbound APIs, and operator-controlled capabilities; distributed, edge, joint communication-compute, and in- network compute; shared AI-RAN accelerators and deterministic resource isolation; O-RAN xApp, rApp, A1, E2, and O1 control paths; cloud-native and virtualized RAN; network slicing, routing, topology, service-function-chain, and autonomous-network operations; ambient, passive, batteryless, backscatter, and zero-energy IoT; device wake and RF-energy admission; dynamic spectrum occupancy and spectrum authorization; RF, millimetre-wave, sub-THz, and future-band emission; reconfigurable intelligent surfaces; cooperative and distributed radio; post-quantum and hybrid cryptographic activation; RAN AI-model mutation; hardware-controlled location release; speculative decoding and target-model reconciliation; persistent and vector memory; deferred, scheduled, recurring, and trigger- conditioned acts; tool, plug-in, MCP-server, and external-agent supply-chain re-attestation; neural-state descriptors and privacy- preserving neural proofs; neural Candidate Act fragments; neural trust segmentation and influence-threshold enforcement; hardware- isolated neural-influence shadow auditing; multimodal sensory provenance; distributed multi-GPU neural execution and secure interconnect binding; unknown-agent marketplace recruitment and trust establishment; two-instance collection-time and execution-time cross- committed validation with independent protected enforcement domains; boundary-local reconstruction of the actual pending operation; attested measurement paths; atomic verify-and-effectuate and compare- and-commit enforcement; distributed partial-share finality without centralized authority reconstruction; sink-rooted finality evidence for dependent operations; readable-data operational inertness; cross- committed multi-agent delegation chains; autonomous cloud-control- plane and telco-cloud commit control; AI-mediated voice, video, recording, call-transfer, and communication-response control; separate computation authority and produced-output finality authority; produced-output canonicalization and output-derived digest binding; effectuation-enabling-resource withholding and execution- substrate technical non-completability; first-usable, location- neutral effectuation-boundary control; output grounding-to- effectuation correspondence; and accelerator, DMA, RDMA, memory, interconnect, SmartNIC, DPU, and other hardware-egress boundaries. Each profile identifies the relevant Candidate Act, authority predicates, protected state, capability scope, Finality Sink, execution-finality boundary, and externally effective consequence while inheriting the common execution-finality model. The architectural question addressed here is complementary to, rather than a replacement for, current industry work on AI-native and future communications. Publicly described work from Qualcomm, Nokia, NVIDIA, Samsung, Ericsson, and Huawei is relevant to areas covered by these profiles, including AI-native 6G, AI-RAN, accelerated and shared compute, programmable and autonomous RAN control, RF and spectrum operation, ISAC, cloud-native networking, energy optimization, and increasingly autonomous network-management loops. The present document addresses a narrower enforcement question that arises at or immediately before consequence: after an AI model, network function, accelerator, application, controller, or autonomous agent has successfully computed or prepared an operation, what machine-verifiable authority must exist at the exact external-effect boundary before that specific operation is allowed to take effect? The named organizations are referenced solely to identify publicly relevant technical directions; no affiliation, review, adoption, approval, endorsement, or participation by any named organization is implied. The common invariant across all profiles is therefore: computation may produce a Candidate Act, but computation is not authority for consequence. Profiles 184 through 213 add package-interconnect acceptance, exception-path and fault-report egress, transmission-quota grant, asserted-prior-authorization, non-transfer coherence visibility, runtime capacity arrival, PHY link-state, in-path component, post- attestation interface-protection, test-path egress, electrical and clock prerequisite, and virtual-channel admission finality, together with commercially mapped profiles for multi-accelerator tensor egress, CXL extent assign-and-reclaim, DPU host-bypass denial, produced-inference-output release, accelerator tenant rebind, destination-jurisdiction egress, agentic tool-call dispatch, key- value-cache admission, model-weight activation, co-packaged optical- lane enablement, training-contribution admission, secret unwrap, streaming-token release, retrieved-context admission, on-device sensor binding, radio and UPF emission, cross-application on-device assistant capability, and telemetry or debug egress. The silicon- layer extension profiles additionally cover CXL-class coherent memory pooling and ownership transitions; UCIe-class chiplet attach and die- to-die manageability; accelerator scale-up-fabric remote load, store, atomic, and route operations; confidential accelerator contexts and secret provisioning; IOMMU/SMMU, PASID, ATS, DMA-aperture, and peer- to-peer translation state; HBM4-class memory-region reassignment and residual-state control; DPU/SuperNIC host-independent network and storage data paths; co-packaged optics and silicon-photonics optical egress; silicon-root-of-trust firmware, microcode, and bitstream activation; and on-die memory-system, NoC, cache, and bandwidth partition state. | |||||||||||||
| draft-das-execution-finality-protocol-layer-01.txt | ||||||||||||||
| The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority | ||||||||||||||
|
TLS tells you the channel is authentic. OAuth tells you the caller holds a valid grant. HTTPS tells you the origin is who it claims to be. EMV tells you a payment cryptogram is transaction-specific. None of these mechanisms answer a question that autonomous, machine- speed systems now raise on every turn: is _this specific act_, generated by _this_ model, agent, or workload, at _this_ moment, actually authorized to become externally effective? Large language model agents, autonomous cloud workloads, and machine- to-machine network functions increasingly compute, decide, and act inside a single event loop, at latencies where no human, log reviewer, or downstream audit process can intervene before an API call fires, a payment settles, a file leaves the enterprise boundary, or a physical actuator moves. Transport, authentication, and authorization protocols were designed for a world in which the gap between "this request was generated" and "this request had a chance to be reviewed" was measured in human-relevant time. That gap has collapsed to milliseconds. Existing protocol layers were never built to close it, because the question they answer -- identity, channel integrity, delegated scope -- is a necessary but categorically different question from whether _this act, right now, should be allowed to leave computation and become consequence_. This document specifies an architectural pattern, execution finality, that treats every machine-generated operation as a Candidate Act held in a Non-Effective State until a Protected Enforcement Domain validates act-specific authority -- purpose, destination, jurisdiction, freshness, revocation state, policy epoch, and runtime integrity -- and issues a narrowly scoped, non-bearer Execution Handle bound to that act and to a specific Finality Sink, the first boundary at which the act would otherwise become externally effective. The document formalizes the vocabulary, a cold-path/hot- path split for latency-sensitive deployment, a structured threat model with adversary-facing pseudocode, an incremental migration path for coexistence with TLS, HTTPS, OAuth, and EMV rather than replacement of them, and worked examples spanning AI agents, payments, telecommunications, cloud infrastructure, satellite command, industrial control, and robotics. The central claim is narrow and falsifiable: _computation does not itself confer authority for consequence_, and no general, cross- domain Internet layer currently makes that separation a structural property of the release path rather than an application-specific convention. This document is intended to solicit IETF community review of whether that gap is real, whether it is already covered by existing or in-progress work, and if not, which venue should take it up. This document describes a patent-pending architectural concept. Any intellectual-property rights or disclosure obligations relating to implementation are outside the technical scope of this document and are subject to applicable IETF IPR procedures, including BCP 79. | |||||||||||||
| draft-das-execution-handle-01.txt | ||||||||||||||
| Possession Is Not Authority: Execution Handle,Sink Verification,Atomic Consumption,and Finality Receipt | ||||||||||||||
|
Across agentic AI, payments, cloud control planes, industrial actuation, and cross-border processing, a machine can prepare a concrete operation long before that operation is allowed to become externally effective. Existing protocols already move identity, authorization data, attestation results, and signed statements. They do not, by themselves, define the small set of interoperable objects required at the effectuation boundary: a canonical Candidate Act Descriptor, a scoped non-bearer Execution Handle bound to that exact act and to a designated Finality Sink, a verify operation that reconstructs the pending effect, an atomic consume that prevents replay, and a Finality Receipt that records what was actually permitted. The residual failure is familiar and does not require token forgery. An access token, capability, session cookie, SPIFFE SVID, WIMSE credential, OAuth grant, attestation result, or signed mandate can remain cryptographically valid while being presented for a different tool call, a substituted beneficiary, a second sink, a replayed payment, a migrated region, or an alternate administrative path. Bearer possession then becomes mistaken for current, act-specific authority to effectuate. Existing mechanisms already address important adjacent problems. OAuth 2.0 and OAuth Rich Authorization Requests can express fine- grained authorization data [RFC6749] [RFC9396]. DPoP and certificate-bound tokens constrain sender possession [RFC9449] [RFC8705]. JWT and CWT carry signed claims [RFC7519] [RFC8392]. HTTP Message Signatures authenticate individual requests [RFC9421]. WIMSE addresses workload identity in multi-system environments [WIMSE-ARCH]. RATS supplies Evidence and Attestation Results [RFC9334]. SCITT supplies signed statements, transparency, and receipts [RFC9943]. MCP and similar tool interfaces dispatch agent- selected functions. None of these objects is specified as a non- bearer, exact-act, sink-bound, single-use-or-bounded effectuation authority whose verification is serialized with protected commit. This document specifies those wire objects and the verify/consume/ receipt exchange. A Candidate Act remains in a Non-Effective State until a Finality Sink reconstructs the security-relevant pending operation, verifies that a current Execution Handle authorizes that exact operation at that sink, consumes or reserves the handle according to its reuse policy, and optionally emits a Finality Receipt. The Execution Handle is not a session token and is not valid merely because the caller can present it. Prevention is claimed only when exact-act binding, sink binding, currentness, reuse policy, consequence-path coverage, and verification-to-commit serialization are load-bearing. If a deployment uses ordinary bearer tokens, advisory act identifiers, post-hoc logs, or a gateway that can be routed around, the result is mitigation or evidence rather than the same prevention guarantee. Encoding profiles are provided for JSON and COSE/CWT; the architecture requires the semantics, not one exclusive encoding. Three rejections are expected and are addressed in the body rather than dismissed here. First, a saga, 2PC, or workflow plus ordinary tokens already coordinates steps; that coordinator is complementary, and is enough only if each sink also reconstructs the live act and consumes act-bound authority. Second, atomic consume is not a process-wide lock: SINGLE_USE is per handle, COUNTED and ENVELOPE exist for high-QPS classes, and rails that already keep idempotency keys already pay this cost. Third, reconstruction is required only at the component that would first make the effect real, over fields that sink can observe — not at every mesh hop, and not as blind trust in a caller digest. Reviewers who hold any of those objections are asked to read those sections and to supply a counterexample if the residual gap is already closed. Criticism, prior art, and a recommendation to stop the work remain invited. | |||||||||||||
| draft-das-finality-bound-revocation-00.txt | ||||||||||||||
| Revoked but Still Executable: Closing the Authorization-to-Effect Gap with Finality-Bound Revocation | ||||||||||||||
|
Revocation is often treated as a property of a credential, token, session, grant, policy, or identity record. In consequence-bearing systems, however, an authorization can be completely legitimate when issued and still become unsafe before the authorized operation becomes externally effective. The security question is therefore not only whether revocation exists, but whether a revocation that becomes authoritative before a protected commit is guaranteed to control that commit. The severity is deployment- dependent, but can be high in financial, administrative, AI-agent, cloud-control, confidential- compute, device, industrial, or other environments where a stale-but- valid authorization can produce an irreversible or externally consequential effect. This document describes a finality-bound revocation model. A Candidate Act remains in a Non-Effective State after upstream authorization. The authorization is bound to an act-specific revocation basis, such as a protected revocation generation, epoch, status root, or equivalent authority state. Immediately before the protected consequence is committed, a Finality Sink verifies that no applicable revocation, suspension, narrowing, or superseding authorization state has become load-bearing. Where the revocation state changed, the act is rejected, re-authorized, or explicitly shown to survive the change under an authoritative rule. With authoritative current state, atomic check-and-commit semantics, and complete mediation of all effectuation paths, this is intended as a prevention property for the protected stale act; deployments that permit bounded staleness or incomplete path coverage obtain mitigation rather than the same prevention guarantee. The model complements existing mechanisms rather than replacing them. OAuth Token Revocation [RFC7009] and Token Introspection [RFC7662] provide standardized token-state mechanisms; Microsoft Entra Continuous Access Evaluation [MS-CAE] demonstrates event-driven rejection of otherwise unexpired tokens; Amazon Verified Permissions and Cedar [AWS-VERIFIED-PERMISSIONS] provide fine-grained policy- evaluation mechanisms; Google Cloud IAM [GOOGLE-IAM-DENY] provides centrally managed deny-policy controls; and confidential-computing and attestation platforms such as NVIDIA attestation [NVIDIA-ATTEST] and Arm CCA [ARM-CCA] can provide protected execution and trust inputs. These technologies are cited as industrial alignment and integration points, not as assertions of vulnerability, deficiency, non-conformance, affiliation, or endorsement. The proposed delta is an effectuation-bound invariant: if revocation becomes authoritative before an act crosses the protected effectuation boundary, a previously valid permit must not remain sufficient merely because its signature, expiry, sender constraint, earlier authorization decision, or cached status result is still valid. The document therefore focuses on the ordering and binding between revocation state and the exact protected commit, including queued work, multi-hop delegation, alternate effectuation paths, rollback, crash recovery, and TOCTOU races. The document asks the IETF community whether existing standards or deployed mechanisms already provide this invariant in full, where the correct effectuation boundary lies, and what interoperability work, if any, is justified. Criticism, corrections, counterexamples, implementation experience, and pointers to existing equivalent mechanisms are explicitly invited. | |||||||||||||
| draft-das-global-privacy-execution-enforcement-00.txt | ||||||||||||||
| Technical Enforcement of the European GDPR and Global Data-Protection Constraints Without Paper Policy | ||||||||||||||
|
The European Union's General Data Protection Regulation (GDPR), China's Personal Information Protection Law (PIPL), and India's Digital Personal Data Protection Act (DPDP Act) each require, in their own terms, that personal data be used only for a specified purpose, be limited to what is necessary, be kept secure, and remain subject to the data subject's or regulator's ability to hold a controller accountable. Every one of these regimes is currently enforced primarily through paper: privacy notices, consent records, data-processing agreements, internal policies, access-control configurations, and audits performed after data has already moved. Paper policy fails in the age of artificial intelligence because it assumes a human-speed decision that no longer exists. An agentic AI system can authenticate, read from several lawfully accessible data sources, combine those sources into a new relationship that was never separately assessed, choose a purpose, select a recipient or an international destination, and transmit the result -- all within a single inference pass, before any privacy officer, consent record, contract clause, or after-the-fact audit log can intervene. A GDPR purpose-limitation clause, a PIPL processing-purpose restriction, or a DPDP consent-manager rule can be entirely correct on paper and still fail in practice, because none of them is a property of the computation itself; each is a property of a document that the computation is merely expected to obey. By the time an audit trail shows that Article 5(1)(b) of the GDPR, the purpose-limitation principle of the PIPL, or the purpose-limitation requirement of the DPDP Act was violated, the disclosure, the cross-border transfer, or the unauthorized combination of data has already occurred and cannot be undone. This document introduces an execution-finality architecture that converts an already-determined privacy rule from a document into a mandatory, machine-verifiable precondition of the computer operation itself. A proposed privacy-sensitive operation is represented as a Candidate Act and is held in a Non-Effective State -- technically incapable of disclosing, transmitting, or combining protected data -- until a Protected Enforcement Domain conjunctively validates the requesting Virtual Identity (VI), the applicable purpose and jurisdictional constraints represented as a Compliance Jurisdiction Token or Structure (CJT/CJS), the minimum required data attributes, the recipient, and the destination, and a Finality Sink positioned at the boundary of first usable external effect independently reverifies that state immediately before release. Non-Joinable Vaults further ensure that holding a valid credential or an authenticated AI session does not, by itself, grant authority to recombine separated categories of personal data. A worked example applies the architecture to a small-or-medium enterprise (SME) AI customer-service deployment, including a prompt- injection scenario in which a manipulated AI agent is technically prevented from exfiltrating payment and identity data regardless of what the model was tricked into generating. A feasibility and latency analysis shows the mechanism can be deployed as ordinary gateway middleware without replacing existing identity or SaaS infrastructure. The document then provides a deliberately bounded mapping onto specific GDPR provisions (Articles 5(1)(b), 5(1)(c), 5(1)(f), 6, 25, 32, and Chapter V), stating plainly which provisions this architecture can make technically load-bearing and which -- such as the legal validity of a basis for processing, or the lawfulness of an international transfer mechanism -- must remain a legal and regulatory determination that no software can make on its own. This document does not advocate discarding paper-based privacy policy, consent management, contractual controls, or audit for general-purpose applications, where the cost, rigidity, and operational overhead of execution-level enforcement would be disproportionate to the risk being managed. The architecture is instead proposed for high-criticality systems: national-security- relevant infrastructure, critical infrastructure, systems processing special-category or otherwise highly sensitive personal data, and other environments in which unauthorized disclosure, cross-border transfer, or unauthorized data combination would be catastrophic, irreversible, or strategically damaging rather than merely a regulatory infraction. For ordinary commercial applications, existing paper-policy, consent, and audit mechanisms, combined with conventional access control, may remain proportionate and sufficient on their own. The central proposition offered to regulators, standards bodies, and implementers is this: a privacy rule that exists only on paper is a rule the machine can violate before anyone notices; a privacy rule bound to the execution boundary is a rule the machine cannot complete without satisfying. | |||||||||||||
| draft-das-hardware-enforced-execution-finality-02.txt | ||||||||||||||
| Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI,MCP Tool Calls,and Industrial Agents | ||||||||||||||
|
Neural AI systems -- large language models, vision-language models, and other learned decision systems -- now move directly from computation to consequence. A model output becomes a tool call; a tool call becomes an API transaction, memory write, payment, file mutation, browser action, or actuator signal; an agent delegates to another agent. Successful inference, sandbox containment, connector allowlisting, session permission, or upstream model approval does not by itself establish authority for that particular real-world consequence. A model may be authorized to compute while remaining unauthorized to act. This document specifies a hardware-rooted execution-finality architecture for neural and agentic systems. A proposed consequence- bearing operation is represented as a Candidate Act and held in a Non-Effective State until a Protected Enforcement Domain validates act-specific predicates and an independent Finality Sink verifies scoped, non-bearer finality authority immediately before the operation becomes externally effective. If that authority is absent, stale, replayed, revoked, or mismatched to the act being attempted, the Candidate Act remains non-effective and the operation fails closed. The architecture is model- and vendor-neutral. It is written for the industrial surfaces that now dominate production agent deployments: Model Context Protocol (MCP) tool dispatch, computer use, code execution, enterprise connectors, memory and knowledge-store writes, GPU and confidential-computing egress, and settlement. The same invariant applies to those surfaces: computation is not authority; tool selection is not tool-effectuation; a connector allowlist is not per-act finality. | |||||||||||||
| draft-das-jurisdiction-bound-execution-finality-00.txt | ||||||||||||||
| Authorized Here,Not Authorized There: Jurisdiction-Bound Execution Finality for Cross-Border and Sovereign Systems | ||||||||||||||
|
Modern cloud, AI, financial, telecom, and critical-infrastructure systems increasingly operate across regions, sovereign clouds, multi- cloud environments, and distributed workload chains. A high- consequence authorization failure can occur even when identity, cryptography, policy evaluation, and platform attestation all succeed: the same Candidate Act can become effective under a jurisdictional or governance context different from the one under which it was authorized. Workload migration, disaster-recovery failover, cross-region queues, service rerouting, remote administration, control-plane changes, destination substitution, key- control changes, or downstream processing can convert an authorization that was valid under context J1 into an effect occurring under context J2. No token forgery or cryptographic break is required. Existing mechanisms already address important parts of this problem. OAuth Rich Authorization Requests [RFC9396] can carry fine-grained authorization details; OAuth Resource Indicators [RFC8707] bind authorization requests to protected resources; JWT [RFC7519] can carry signed application claims; WIMSE [WIMSE-ARCH] provides workload-identity and security-context architecture for multi-system environments; RATS [RFC9334] provides Evidence, Verifiers, and Attestation Results; and SCITT [RFC9943] provides signed statements, transparency, and receipts. Industry systems also provide concrete sovereignty and data-boundary controls: Microsoft documents its EU Data Boundary [MS-EUDB], AWS operates the European Sovereign Cloud [AWS-ESC], and Google Cloud provides Sovereign Controls by Partners [GOOGLE-SOV]. The residual gap exists only where jurisdiction is treated as descriptive metadata, inferred from weak location signals, enforced only at deployment time, or checked at an upstream boundary while the actual consequence can later move through another region, operator, administrative path, processing service, destination, failover route, or control domain. A workload can be correctly authenticated and a platform correctly attested while the current effectuation context no longer satisfies the deployment's sovereignty rule. Likewise, storing data in one region does not by itself prove where it is processed, remotely administered, decrypted, transmitted, or finally disclosed. This document proposes a jurisdiction-bound execution-finality invariant. A Candidate Act remains in a Non-Effective State until the Finality Sink establishes a current, authoritative Jurisdiction Execution Context (JEC) for the exact act and verifies that the present effectuation environment satisfies the deployment-defined Jurisdiction Policy. The JEC can combine workload identity, compute and processing domain, storage location, destination, operator/ control domain, key-control domain, remote-access state, attested trust state, and policy generation. JEC is an architectural role, not a mandated token format. Prevention is claimed only when the jurisdiction policy, evidence sources, current effectuation context, exact-act binding, state continuity, and consequence path are load-bearing and non-bypassable. If the deployment relies only on GeoIP, region labels, advisory metadata, best-effort routing, post-hoc audit, or incomplete path coverage, the result is mitigation or evidence rather than the same prevention guarantee. The architecture enforces machine-readable jurisdiction or compliance policy supplied by an authoritative deployment source; it does not determine what law applies or provide a legal conclusion. Microsoft, AWS, Google Cloud, NVIDIA, and Arm are discussed only as complementary industrial examples or potential integration points. The document does not assert vulnerability, deficiency, non- conformance, affiliation, or endorsement by any named organization. A deployment that already makes its required jurisdictional constraints current, non-bypassable, and mandatory at the actual consequence boundary already satisfies the core property. Criticism, corrections, counterexamples, prior-art pointers, implementation experience, and evidence of equivalent existing mechanisms are explicitly invited. | |||||||||||||
| draft-das-map-discovery-communication-finality-01.txt | ||||||||||||||
| Privacy-by-Design Architecture for Map-Based Business Discovery Using Query-Scoped Non-Bearer Authorization | ||||||||||||||
|
Map-based discovery systems can help a person identify nearby businesses, properties, service providers, hotels, clinics, restaurants, and other commercial actors, but discovery frequently transitions into communication through a persistent telephone number, reusable virtual number, open message thread, callback route, or other contact path. A person may intend only a short first conversation with several candidates, while the communication mechanism unintentionally creates continuing reachability after that inquiry has ended. This document describes an architecture in which first contact and future reachability are separate authorization events. After a user creates a map search, property inquiry, service request, booking inquiry, quote request, or similar context, a platform can create a query-scoped non-bearer communication reference and bounded preview authority. A user or eligible business can participate in a real but limited first interaction. Continued communication is separately authorized and remains bound to attributes such as the original query, business identity, purpose, channel, effect, validity window, nonce, quota, revocation state, and enforcement point. Possession of a number, handle, previous conversation, lead assignment, API credential, or payment event is not by itself sufficient future- contact authority. The architecture separates marketplace policy from communication effectuation. A Communication Authority Service creates a protected authorization binding, while an enforcement point reconstructs the actual attempted communication, checks current protected state, atomically reserves or consumes relevant authority, and releases the communication-bearing resource only after successful verification. This permits privacy-preserving first contact, controlled future reachability, preview-qualified lead monetization, and AI-assisted business discovery without requiring a new public telecom protocol for initial deployment. Google Maps, Apple Maps, mobile operating- system discovery surfaces such as iOS and Android, and social and commerce platforms with map-adjacent or messaging-based business discovery features such as Meta Business (including Facebook and Instagram business discovery and messaging) are used as recognizable illustrative examples; no affiliation, endorsement, implementation, adoption, or technical alignment by Google, Apple, Meta, or any other named provider is implied. The architecture's binding of recipient identifiers to pseudonymous, query-scoped, time-limited, purpose-bound, and revocable authorizations rather than persistent contact data is consistent with the data protection principles of the EU General Data Protection Regulation (GDPR) -- including data minimization and purpose limitation (Article 5), storage limitation through bounded validity and quota, and privacy by design and by default (Article 25). This document describes a technical architecture only; it does not constitute a legal compliance determination, and conformance with GDPR or any other data protection law depends on the specific deployment, controller and processor roles, and operational practices of an implementing platform. | |||||||||||||
| draft-das-ntn-rf-execution-finality-01.txt | ||||||||||||||
| RF Enable Is Not Transmit Authority: Finality for LEO/NTN and Inter-Satellite Control | ||||||||||||||
|
A LEO constellation computer can compute a transmit burst, a beam command, an inter-satellite forward, or a user-terminal PA enable faster than any ground reviewer can see it. Today those acts become RF because the scheduler selected them, the command link authenticated, or the flight process had the radio device open. Authentication of TT&C, 3GPP NTN registration, and operator allowlists decide who may talk to the vehicle. They do not decide whether this burst, on this beam, to this next hop, over this territory, in this mission epoch, may leave the aperture. Radiation is not reversible. An ISL hop is not a log line. A phased-array user terminal that is already pointed is one register write away from radiating. If the enable line trusts the last ground "go," a stale, substituted, or autonomy-generated command becomes sky-facing consequence. This document specifies a radio-side execution-finality profile for NTN and mega-constellation control. A proposed RF, ISL, beam, gateway, or payload act remains a Candidate Act. A Protected Enforcement Domain binds vehicle, beam, frequency class, duration, next hop, overflight or jurisdiction epoch, and intended sink, then issues scoped non-bearer authority. The Finality Sink sits at the PA enable, ISL switch, beam driver, feeder gateway, or UT transmit path and verifies that authority immediately before energy leaves the system. RF enable is not transmit authority. | |||||||||||||
| draft-das-ot-actuation-finality-00.txt | ||||||||||||||
| A Setpoint Write Is Not Actuation: Finality for ICS,Grid,and Robot Command | ||||||||||||||
|
Industrial systems already know how to move a breaker, a valve, a robot joint, or a turbine setpoint. They do not know whether this write — this tag, this value, this device, from this operator session or this agent — is the write that was authorized to become motion. A signed OPC UA call, a valid DNP3 control, an IEC 61850 command, or an MQTT publish onto the plant bus can all be protocol-correct while the act is wrong. The protocol authenticates a channel. It does not bind a Candidate Act at the actuation sink. That gap is now an agent gap. Copilots sit on historians and work- order text. They propose "explain this alarm" and then "set this point." If the gateway treats a well-formed write as authority, reconstruction of plant state becomes physical consequence. Past incidents stole engineering workstations. Present incidents steal the jump host or the agent seat. Future incidents let the model format the command. This document specifies an OT-side execution-finality profile. A write remains an Actuation Candidate Act. A Protected Enforcement Domain binds principal, zone, device, tag, value envelope, mode (local/remote, auto/manual), safety interlock state, policy epoch, and intended actuation sink, then commits evidence before scoped non- bearer authority is issued. The sink that would actually drive I/O verifies that authority against the live write and consumes it. A setpoint write is not actuation. | |||||||||||||
| draft-das-payment-execution-finality-01.txt | ||||||||||||||
| A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments | ||||||||||||||
|
Payment rails already know how to move money. They do not know whether this generated instruction — this amount, this beneficiary, this rail, this purpose, from this agent or API worker — is the instruction that was authorized to move. A signed ISO 20022 message, an OAuth token on a PSP, a stored mandate, or a pass through 3-D Secure can all be valid while the act is wrong. The signature authenticates a channel. It does not bind a Candidate Act at the settlement sink. That gap is now an agent gap. A model that can call payout.create, a RPA job that submits ACH, or a checkout agent that captures a card will treat tool selection as settlement authority. Fraud used to steal credentials and replay files. It now steals a seat or injects a document and asks the authorized worker to pay a new beneficiary at the old amount, or the old beneficiary at a new amount. This document specifies a payment-side execution-finality profile. An instruction remains a Payment Candidate Act. A Protected Enforcement Domain binds principal, wallet or account, amount, currency, beneficiary, rail, purpose, policy epoch, and intended settlement sink, then commits evidence before scoped non-bearer authority is issued. The sink that would actually post, capture, or release funds verifies that authority against the live instruction and consumes it. A signed instruction is not settlement. | |||||||||||||
| draft-das-precision-bounded-egress-03.txt | ||||||||||||||
| Access Is Not Egress: Precision-Bounded Location Release | ||||||||||||||
|
A device may legitimately possess exact location while an application, SDK, AI agent, analytics library, or foreign endpoint is entitled only to a coarser representation, a delayed or randomized representation, or no location at all. Operating system permission to read a fix does not answer whether that fix may leave the device at the requested precision. This document defines a precision-bounded egress profile: a data- minimization mechanism applied at the point of external disclosure, on top of an execution-finality architecture, applicable equally to conventional applications and to autonomous AI agents acting on a user's behalf. The gap this closes is concrete: an application that legitimately reads exact GPS for one on-device purpose commonly shares its process with an embedded SDK, agent tool, or cloud sync path that can forward the same exact coordinate to a destination that never needed it, without the user seeing that forwarding as a separate disclosure. A proposed release is a Location-Release Candidate Act and remains non-effective while a Protected Enforcement Domain evaluates purpose, requester, component, recipient, destination, jurisdiction, required precision, policy and revocation state, cumulative disclosure state, and intended egress sink. The Protected Enforcement Domain issues scoped, non-bearer, cryptographically bound finality authority for a specific precision ceiling, expressed using the JSON interoperability objects defined in this document. An independent egress Finality Sink verifies that authority against the actual outbound payload immediately before release, so the bound ceiling, rather than the requester's declared precision, determines what may leave the device. The permitted result may be exact data, a reduced representation, or denial. Data access is not data-export authority. Precise GPS access is not precise GPS-release authority. | |||||||||||||
| draft-das-protocols-candidate-act-finality-01.txt | ||||||||||||||
| Stopping AI Hallucinations and Unsafe Acts from Becoming Real-World Consequences (DAS Protocols) | ||||||||||||||
|
The internet has protocols for moving data, securing channels, naming hosts, and delegating identity. It has no protocol for the moment a machine-generated instruction becomes a real-world act. As AI systems begin to move money, change databases, reconfigure networks, send communications, and control physical systems, that missing boundary becomes a structural risk. Today an AI can hallucinate a fact, cite a stale source, invent a tool argument, or propose an unsafe agentic step — and still reach an effectuation interface. Model approval is not output approval. Workflow approval is not consequence approval. Moderation, access control, TEEs, simulation, and post-hoc audit all leave the final transition from computation to consequence under-protected. This document specifies the DAS Protocols Candidate-Act Finality architecture. Every effect-capable AI output is first converted into a non-effective Candidate Act. The Candidate Act stays non-effective until a Protected Enforcement Domain has validated output, provenance, factual support, consequence, jurisdiction, epoch, and sink predicates. Only then is a scoped non-bearer capability or Execution Handle released and verified at a Finality Sink. In advanced forms the Finality Sink is cryptographically unable to complete the act unless the handle supplies the missing execution material. The architecture supports graduated and escalated conditional finality so that elevated-risk but necessary acts can still proceed under stricter controls. The document elaborates the problem space, compares the approach with representative existing techniques, describes the base and advanced finality paths, and provides JSON Schema definitions for the core protected objects. Related Indian provisional applications and PCT filings are listed in the final appendix. | |||||||||||||
| draft-das-protocols-enterprise-ai-02.txt | ||||||||||||||
| Assume the AI Server Is Already Compromised: Execution-Consequence Decoupling So a High-Risk Enterprise AI Cannot Join,Infer,or Send | ||||||||||||||
|
Start from the assumption that the attacker already controls the AI server — that the workload is fully compromised. Not the perimeter, not a phished seat — the workload itself: its credentials, its connectors, its context window, its output path. Nearly every enterprise control in use today has already failed by that point, because nearly every one of them is designed to keep the attacker out of the workload rather than to limit what the workload can do once it is theirs. Before anything else, the engineering posture: this architecture is specified for high-risk AI systems, where the standard priorities shift from speed and latency toward determinism, containment, and safety. It is written for billion-dollar enterprise and mission- critical deployments — banking and treasury, defence and national security, critical infrastructure, and regulated enterprises holding unreleased material — and not for general day-to-day, consumer-grade, or low-stakes use. It introduces evaluation on the join path and on the release path, and accepts that cost deliberately, because in these environments an unauthorized reconstruction or an unauthorized send is not recoverable by being fast. This document asks what is still denied to the attacker at that moment, and specifies an architecture in which two things are still denied: the attacker cannot cause independently held enterprise fragments to be bound into a map of the organization, and cannot cause any generated result to become externally effective. Access to a store is not authority to join it to another store. Finishing a generation is not authority to send it. The mechanism is Execution-Consequence Decoupling, enforced by three pillars: Decomposition of Authority (Technical Non-Joinability) across independently controlled identity, content, relationship- mapping, and cryptographic domains; Mandatory Mediation of every consequence-bearing Candidate Output; and Technical Non- Completability, so that computation can run to completion in a compromised environment without the ability to complete an external consequence. Reconstruction is governed by a non-bearer Reconstruction Authorization Object bound to attested execution context, session, purpose, and Permitted Association Scope. Candidate Outputs are sealed, re-verified at output time, and committed to a Protected Output Validation Receipt before an output- specific Release Capability can be issued and exercised at a designated Output Release Boundary. The industrially relevant systems are the enterprise assistant and agent runtimes now deployed into exactly those environments, including those built on Anthropic Claude, OpenAI ChatGPT, Google Gemini, xAI Grok, and self-hosted Meta Llama models, together with the connector and Model Context Protocol fleets attached to them. These are named as publicly described deployment classes, because an architecture for high-risk enterprise AI should say plainly which systems it is about; nothing here characterizes any vendor's internal design or security posture, and no vendor has reviewed or endorsed this work. It states the problem space, compares the architecture against representative conventional technologies (access control, bearer credentials, vaulting, TEEs, sandboxes, DLP, provenance, DRM, clean rooms, and information-flow control), gives a detailed technical description, and supplies JSON Schema definitions for the three protected objects. A published runnable reference implementation [GITHUB-DAS-VII] executes the protected chain described here, so the architecture can be run and tested rather than only read; it is an architectural reference for the state machine and its failure states, not a claim of production isolation. This is the architecture and rationale document. Its companion, draft-das-enterprise-ai-output-finality [I-D.das-enterprise-ai-output-finality], specifies the same split as a deployable protocol profile and metadata format for vendor assistant and agent seats. The two are read together: this document explains why authority must be separated from computation; the companion specifies the objects, bindings, and boundary sequences that carry the separation on the wire. | |||||||||||||
| draft-das-purpose-execution-finality-03.txt | ||||||||||||||
| Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse | ||||||||||||||
|
Consider a concrete case: a user invokes a highly capable AI model under a declared purpose of education, but the resulting capability is in fact used for a military or terrorist end -- an illustrative example, not a claim about any real deployment. When such misuse surfaces, an unresolved question follows: is the model provider liable, is the user liable, or is the jurisdiction that permitted the deployment liable? This document does not answer that question -- liability determination remains an external legal question for the responsible court, regulator, or contracting parties -- but it addresses the technical gap that makes the question unanswerable today. Systems that collect data, or grant capability, for one stated purpose routinely permit that data or capability to be consumed for a different purpose, not because the second use was authorized, but because nothing in the protocol path was capable of refusing it or of recording what was actually authorized. The most common technical control in deployment today is a self-asserted purpose string: a "purpose" claim in a token, a field in an API request, a comment in a data-sharing agreement. A self-asserted string is evidence of intent, not proof of authority, and it fails precisely when it matters most -- when the requester lies. This architecture addresses that loophole deterministically: it makes an undeclared or purpose-switched use technically detectable and refusable at the point of use, and it produces verifiable evidence of what was actually authorized, so that any subsequent liability determination can be argued from that evidence rather than from an unverifiable self-assertion. Achieving that determinism introduces a bounded, measurable amount of evaluation latency at the point of use; this document treats that latency as an acceptable, secured trade-off for closing an otherwise unverifiable gap, not as a cost to be minimized at the expense of the guarantee. The premise is not that AI innovation should slow down, any more than cars should be built slower; it is that innovation moving this fast needs the technical equivalent of a seat belt. A runnable reference implementation accompanies this document at Purpose Execution Finality Validator -- Runnable Reference Implementation (https://github.com/sangmdas/Purpose-Execution- Finality-Validator-to-Prevent-Data-Purpose-Laundering-in-AI-Systems). | |||||||||||||
| draft-das-rats-attestation-bnd-execution-finality-04.txt | ||||||||||||||
| Attestation-Bound Execution Finality for GPU,AI Accelerator,DPU,SmartNIC,and Confidential-Computing Infrastructure | ||||||||||||||
|
Remote attestation can establish that a CPU, confidential virtual machine, GPU, AI accelerator, DPU, or SmartNIC is running expected firmware and software in an expected configuration. However, an acceptable Attestation Result describes the execution environment, not the operations it later emits; it remains the same whether subsequent workload outputs arise from expected logic, prompt injection, or model error. As AI workloads become agentic and move onto confidential accelerator infrastructure, they emit high- consequence operations, such as financial transfers, cloud-control mutations, database deletions, and external API invocations, where platform trustworthiness alone cannot determine whether a concrete operation is authorized to take effect. OAuth access tokens, transaction tokens, and workload credentials do not close this gap on their own: they typically authorize by scope and by possession of a credential rather than by the exact content of one operation, and they do not require that the protected effect be unreachable except through a verifying boundary. This document describes an attestation-bound execution-finality architecture that bridges platform appraisal and consequence-bearing authorization. A consequential operation originates in a non- effective state as a Candidate Act. An Execution-Finality Validator evaluates the act's security-relevant arguments together with the platform's Attestation Result, workload identity, and policy, and issues an act-bound, single-use, non-bearer Execution Handle. A Finality Sink verifies that handle at the non-bypassable boundary where the operation would first acquire external effect, so that an authorized act cannot be swapped, mutated, or replayed. The architecture requires no changes to silicon, microcode, firmware, drivers, or accelerator programming models, and it separates concerns: platforms such as NVIDIA confidential-computing GPUs and BlueField DPUs, Arm Confidential Compute Architecture (CCA), AMD SEV- SNP, and Intel TDX supply environment appraisal on the cold path, while enforcement is placed at the gateway, service-mesh, DPU or SmartNIC, network, or storage boundary. On the hot path, verification uses local cryptographic bindings and single-use checks rather than repeated attestation round trips. The document discusses its relationship to RATS, WIMSE, OAuth, and related IETF work, and its engineering FAQ addresses platform layering, DPU visibility under end-to-end encryption, tail latency, and other anticipated critical questions. It is intentionally long because it is explanatory rather than a protocol specification. The architecture is implemented, not only described. An executable reference implementation (GitHub: reference implementation, tests, benchmarks, and deployment materials, https://github.com/sangmdas/ Execution-Finality-for-GPU-AI-Accelerators-and-Confidential- Workloads) demonstrates act binding, single-use enforcement, and replay rejection in running code. It uses a software-only attester; it has not been run on any vendor's confidential-computing hardware and does not consume any vendor-issued attestation token, and vendor platforms are discussed on the basis of public documentation only. This document is vendor-neutral, neither claims nor implies review, adoption, endorsement, or affiliation by any named vendor, and complements rather than replaces existing attestation, workload- identity, and authorization mechanisms. | |||||||||||||
| draft-das-rats-frontier-model-extraction-04.txt | ||||||||||||||
| An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive,High-Priority Frontier AI Model Information | ||||||||||||||
|
This architecture is a hardware-rooted defense against intellectual- property theft of frontier AI models, intended for deployment by AI model creators themselves -- including trillion-dollar frontier-model providers such as OpenAI and Anthropic -- rather than for generic, day-to-day AI use by an end user. It protects Sensitive Model Information that is high-priority and dual-use, with the specific purpose of preventing unauthorized extraction and distillation of the model itself. The architecture introduces bounded, deterministic evaluation latency to intercept unauthorized release paths, a trade- off acceptable specifically for protecting highly valued dual-use assets where standard optimization for raw speed is subordinate to absolute asset security. Frontier and proprietary AI deployments may contain or expose model- related information substantially richer than ordinary final-answer text. Depending on the deployment and interface, such Sensitive Model Information (SMI) can include detailed probability information, embeddings, cached intermediate state, hidden representations, intermediate activations, diagnostic information, model-related metadata, or other high-information artifacts. Repeated unauthorized or excessive release of such information can increase the efficiency of model reconstruction, imitation, extraction, or distillation. Authentication establishes who is requesting an operation. Confidential computing and remote attestation can establish properties of the environment in which computation occurs. Neither property alone determines whether a particular pending release of particular model information, to a particular destination, under the current extraction state and security epoch, remains authorized to become externally usable. This document describes an execution-finality architecture for that remaining problem. Sensitive information may be computed while remaining a non-effective Candidate Release. External release occurs only after release-specific protected validation, evaluation of rollback-resistant extraction state where required, atomic reservation or consumption of bounded authority, and verification at a controlled Finality Sink. Release authority is bound to the applicable Candidate Release or bounded release class rather than operating as a generic transferable bearer credential. The architecture does not claim universal prevention of model extraction or distillation and does not restrict legitimately exposed ordinary model output. Its narrower objective is to make unauthorized, excessive, replayed, rolled-back, or bypassed release of protected model information technically harder to complete through governed release paths. RATS can complement this mechanism by allowing a Verifier or Relying Party to obtain machine-verifiable information about whether the expected release-control mechanism, protected state, security epoch, and Finality Sink are present and operating with the required assurance properties. To demonstrate that this architecture is practically achievable and not merely theoretical, a runnable reference implementation is provided at Execution-Finality for Protected AI Model-State Release -- RATS Reference Implementation (https://github.com/sangmdas/ Execution-Finality-for-Protected-AI-Model-State-Release-RATS- Reference-Implementation). | |||||||||||||
| draft-das-rats-openai-anthropic-extraction-03.txt | ||||||||||||||
| An Execution-Finality Architecture Against Automated Extraction and Distillation of OpenAI and Anthropic Claude Model Information | ||||||||||||||
|
High-capability AI models can expose commercially, strategically, or technically valuable model information through governed inference interfaces, including logits, log-probabilities, embeddings, intermediate representations, structured responses, and other protected outputs. Repeated or automated access to such information can contribute to industrial-scale model extraction, unauthorized capability replication, or distillation, creating significant intellectual-property, commercial, security, or strategic risk for operators of high-value models. The problem addressed by this document is not whether a model is technically capable of computing such information, but whether computation itself should constitute authority to release it. This document therefore separates model computation from external disclosure: successful inference does not, by itself, constitute release authority. An output may be fully computed while remaining a non-effective Candidate Release that cannot yet cross the governed release boundary. A Candidate Release remains non-effective until the applicable release conditions have been independently satisfied. The architecture can include release-specific protected validation, evaluation of rollback-resistant extraction state where required, and atomic reservation or consumption of bounded release authority. A controlled Finality Sink verifies the required state at the boundary where the protected information would first become externally available. Release authority is bound to the applicable Candidate Release or bounded release class rather than functioning as a generic transferable bearer credential. The intended result is a technical separation between information that a model can compute and information that the governed system permits to become externally effective. This architecture is intended primarily for high-value or high- capability models and protected output classes where industrial-scale extraction or unauthorized capability replication creates sufficient risk to justify stronger release controls. It is not intended to impose the same enforcement mechanism on every model, user request, or inference path. Operators can apply execution-finality controls selectively according to model value, protected-output class, extraction risk, interface characteristics, or required assurance level. Such enforcement can introduce additional protected-state management, validation, synchronization, attestation, or Finality Sink verification overhead. Latency is therefore an explicit deployment tradeoff rather than an assumption that every inference request should incur the same assurance cost. For sufficiently valuable models or sensitive capabilities, an operator may determine that stronger protection against industrial-scale extraction justifies additional release-path processing, while ordinary or lower-risk output paths may use lighter controls. The architecture does not claim universal prevention of model extraction or distillation. In particular, it does not claim to prevent all learning from ordinary outputs that have been legitimately released, nor does it claim control over information after valid disclosure beyond the governed boundary. Its narrower objective is to constrain industrial-scale extraction conducted through governed release paths and to make unauthorized, excessive, replayed, rolled-back, or bypassed release of protected model information technically harder to complete. Remote Attestation Procedures (RATS) can complement this architecture by providing machine-verifiable evidence that the expected release- control mechanism, protected extraction state, security epoch, and Finality Sink are present and operating with the required assurance properties. Attestation establishes evidence concerning the enforcement environment; it does not itself constitute authority to release a protected Candidate Release. | |||||||||||||
| draft-das-satellite-orbital-finality-profiles-00.txt | ||||||||||||||
| Execution-Finality Profiles for LEO/NTN Satellites,Orbital AI,Optical ISLs,Spacecraft Autonomy,and Cybersecurity | ||||||||||||||
|
Satellite and non-terrestrial networks are becoming programmable compute, routing, sensing, radio, and AI infrastructures. In such systems, successful authentication, attestation, routing, scheduling, inference, fault recovery, or protocol processing does not necessarily establish authority for the resulting operation to become externally effective. This document describes an execution-finality architecture in which a consequence-bearing operation is represented as a Candidate Act and may remain in a Non-Effective State after computation. A Protected Enforcement Domain validates act-bound predicates and protected state, commits protected validation evidence, and permits release of scoped non-bearer authority. A Finality Sink at or before the relevant consequence boundary verifies that authority before an operation becomes routing-effective, radiative-effective, storage- effective, control-effective, disclosure-effective, or otherwise externally effective. Sixty satellite and NTN enforcement profiles are provided, covering orbital AI output release, model-state transfer, Earth observation, power- and thermal-bounded compute, radiation recovery, optical inter-satellite links, onboard gNB and user-plane functions, delay- tolerant delivery, emergency services, firmware and microcode activation, privileged maintenance, orbital maneuver and collision- avoidance authority, proximity operations, propulsion and attitude actuation, hosted-payload control, sensing activation, end-of-life decommissioning, manufacturing and launch-preparation component admission, and high-consequence command release. Each profile states a concrete problem space and the corresponding execution-finality solution. Publicly described work from SpaceX / Starlink, Blue Origin, Northrop Grumman / SpaceLogistics, Rocket Lab, Airbus Defence and Space, and Thales Alenia Space illustrates industry directions involving direct- to-device connectivity, optical inter-satellite networking, orbital mobility, hosted and software-defined payloads, onboard processing, rendezvous and proximity operations, and in-orbit servicing. These references identify technical complementarity and possible enforcement locations; they do not imply that any named organization has reviewed, endorsed, adopted, or lacks equivalent mechanisms. The proposal does not replace 3GPP NTN, IETF routing or Time-Variant Routing, DTN, RATS/attestation, ACE authorization, SUIT update mechanisms, optical-link protocols, spacecraft fault detection, isolation and recovery, or cryptographic authentication. Those mechanisms can provide inputs to the finality decision. The additional question is whether a specific Candidate Act is permitted to cross the boundary at which it first acquires external effect. Technical corrections and references to equivalent existing mechanisms are expressly invited. | |||||||||||||
| draft-das-state-policy-continuity-finality-00.txt | ||||||||||||||
| When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary | ||||||||||||||
|
Security decisions are frequently made against mutable state. An authorization decision may depend on a policy bundle, mapping table, reference-value set, ownership record, revocation state, risk classification, purpose grant, account state, or other data that can change between evaluation and effectuation. A cryptographically authentic permit can therefore remain valid as an object while becoming stale as authority. Existing freshness, replay-protection, sender-constraining, attestation, and anti-rollback mechanisms solve important parts of this problem. They do not by themselves establish that the exact policy and state basis used to approve an act is still the applicable basis when that act becomes externally effective. This document describes a state- and policy-continuity model for execution finality. A Candidate Act remains non-effective until a protected Finality Sink verifies the concrete act, the identity of the evaluated policy or mapping content, protected generations or epochs, relevant mutable state, freshness, and authorized-use constraints immediately before effectuation. The model treats revision identity as content-bound rather than merely name- or location-bound. A change from one mapping or policy revision to another is a state transition that requires re-evaluation unless an authoritative mechanism explicitly establishes applicability across revisions. The Finality Sink is not expected to infer semantic equivalence dynamically. The model complements, rather than replaces, mechanisms such as RATS, Entity Attestation Tokens, SUIT anti-rollback controls, OAuth fine- grained authorization, sender-constrained tokens, and application policy engines. Its central invariant is that authorization valid at evaluation time is not automatically authority at effectuation time. The problem is industrially relevant to systems that already combine continuously evaluated access, fine-grained policy decisions, attestation, and confidential computing. Examples of complementary industry directions include Microsoft Entra Continuous Access Evaluation, Amazon Verified Permissions and Cedar, Google Cloud IAM policy enforcement, NVIDIA GPU and switch attestation, and Arm Confidential Compute Architecture. These names identify useful integration and comparison points; they are not assertions of vulnerability, deficiency, non-conformance, or endorsement by any named organization. | |||||||||||||
| draft-das-third-party-decision-binding-00.txt | ||||||||||||||
| Trust Me,I Checked: Verifiable Third-Party Decision Binding at the Execution-Finality Boundary | ||||||||||||||
|
High-consequence distributed systems frequently allow one component to act based on a decision produced by another component, such as an authorization server, policy engine, risk service, attestation Verifier, compliance service, workload-identity authority, or safety controller. The vulnerability is not limited to forged credentials: a compromised or incorrectly designed intermediary can claim that a required third-party check succeeded, replay an earlier decision, substitute evidence from a different act or context, suppress a required DENY, or retain evidence only for audit while the protected effect remains technically independent of that evidence. The issue deserves high attention where the downstream consequence is financial, administrative, privacy-sensitive, safety-relevant, infrastructure-changing, or otherwise difficult to reverse. Existing mechanisms solve important parts of this problem. OAuth Token Introspection [RFC7662] lets a protected resource query token state; HTTP Message Signatures [RFC9421] provide integrity and authenticity for selected HTTP message components; RATS [RFC9334] provides Evidence, Verifiers, and Attestation Results; Transaction Tokens [TXN-TOKENS] propagate identity and authorization context through trusted call chains; SCITT [RFC9943] provides signed statements, transparency, and verifiable receipts; and current authorization- evidence work [MUNOZ-EVIDENCE] [MUNOZ-SCITT] defines signed pre-execution Permits bound to canonical request material. Where one of these mechanisms is verified by the actual non- bypassable effectuation boundary and already proves the required decision for the exact act, current context, and authorized use, that deployment can already satisfy the property described here. The residual gap arises only where the consequential component receives an upstream claim such as "the external check passed", where authentic evidence is bound to the wrong act, authority, tenant, purpose, generation, or sink, where valid evidence has become stale or replayable, where only a subset of required authorities is represented, or where evidence exists but is not a load-bearing prerequisite of effectuation. This document introduces an architectural role called External Decision Evidence (EDE). EDE is not a new wire format: an existing Permit, SCITT statement or receipt, Attestation Result, live authenticated decision response, or other protected result can instantiate EDE when its semantics satisfy the deployment profile. The proposed invariant is that a Candidate Act remains non-effective until the Finality Sink independently establishes that every required external decision authority issued an applicable decision for the concrete act, under the required decision basis and current state, with freshness, audience or sink binding, and authorized-use semantics appropriate to the deployment. Prevention is claimed only when the protected consequence cannot occur without successful verification of the required evidence and alternate effectuation paths cannot bypass that verification. Otherwise the mechanism provides auditability, accountability, detection, or mitigation rather than the same prevention guarantee. The model is intended to complement, not criticize or replace, OAuth, WIMSE, SCITT, RATS, externalized policy systems such as Amazon Verified Permissions/Cedar, continuous-access systems such as Microsoft Entra Continuous Access Evaluation, Google Cloud IAM controls, and protected-compute technologies such as NVIDIA attestation and Arm CCA. The proposed delta is not the invention of signatures, authorization evidence, receipts, or attestation results; it is the effectuation-time requirement that independently verifiable required decisions become load-bearing for the exact protected act. Criticism, corrections, counterexamples, implementation experience, prior-art pointers, and evidence that existing mechanisms already provide the full invariant are explicitly invited. | |||||||||||||
| draft-davey-tls-braid-01.txt | ||||||||||||||
| Bound Routing,Authority,and Identity Data (BRAID): Independent Circuit Breakers for Long-Lived TLS Certificates | ||||||||||||||
|
This document defines BRAID, a negotiated profile for publicly trusted TLS server certificates that adds one or more independent circuit breakers to a certificate. Each circuit breaker is an authorization held by a party the domain owner appoints; withdrawing any required authorization causes the certificate to stop validating. Because a certificate can be invalidated promptly and without the participation of the issuing certification authority, its natural validity period no longer has to be short in order to bound exposure. The base mechanism is deliberately static. The domain owner publishes a DNSSEC-signed BRAID Anchor listing the public keys authorized to authenticate the domain, and thereafter does nothing; the certificate remains valid until the owner withdraws an entry. Steady-state operation requires no periodic reissuance, no periodic re-minting of credentials, and no online status service. Short- interval credential refresh is defined as an optional enhancement that tightens revocation latency, not as a requirement. Because the Anchor authorizes credential keys rather than the end- entity key itself, impersonating a BRAID-protected domain requires both the end-entity private key and the ability to publish in the owner's DNSSEC-signed zone. This document calls that the Two-Control Property, and it is the principal security difference between BRAID and publishing an end-entity certificate association directly in DNS. BRAID support is negotiated in the handshake, so a BRAID certificate is presented only to a client that offered to validate it; every other client is served an ordinary certificate and is unaffected. Optional strands bind a certificate to an authorized routing origin and to an appointed third-party witness. | |||||||||||||
| draft-davies-internal-tld-06.txt | ||||||||||||||
| A Top-level Domain for Private Use | ||||||||||||||
|
This document describes the "internal" top-level domain for use in private applications. | |||||||||||||
| draft-davis-ivy-equipment-capability-application-02.txt | ||||||||||||||
| Equipment Capability Application | ||||||||||||||
|
This document applies the generalized capability principles to the description of equipment (a physical thing) with applied data (configuration state and code (software, firmware etc.)) and shows how such capability specifications integrate with base inventory and entitlement models as defined in Network Inventory, Software Extension and Entitlement YANG models. The approach is examined by example, focusing on how the potential capabilities of each equipment type-version with applied data are described, how these map to entitlements (licensed or policy- controlled subsets of capabilities), and how they are instantiated as inventory items. The explanation covers both the capabilities of equipment in terms of physical properties and the capabilities of equipment with applied data in terms of resultant emergent functionality. | |||||||||||||
| draft-davis-nmop-generalized-capability-principles-02.txt | ||||||||||||||
| Generalized Capability Principles | ||||||||||||||
|
This document introduces a framework for capability modeling based on the specification and refinement principles established in ITU-T G.7711 Annex G (also previously published as ONF TR-512.7. See latest G.7711 release) and the modeling boundaries work documented in draft-davis-netmod-modelling-boundaries. The framework defines how component–system capabilities can be explicitly described and refined via a process of pruning, refactoring, and occurrence formation. This draft version additionally incorporates a sketch of an occurrence-semantics kernel. This kernel is presented here as a continuation of the refinement and occurrence-formation principles already introduced in the previous version, not as a retrospective reinterpretation of them. These capability definitions can target detailed operational considerations, system interactions, licensing, abstract product declarations, or sales and marketing. The framework supports modular, layered, and fractal declarations of networked behavior, and provides a foundation for a suite of future IETF drafts aligned with ongoing work on photonic plug manifests, entitlement/licensing, IVY equipment modeling, energy/thermal considerations and related domains. | |||||||||||||
| draft-davis-pool-03.txt | ||||||||||||||
| Protected Orchestrated Overlay Link (POOL): The Only Place Where Cowboys Can Water Their Horses | ||||||||||||||
|
This document describes the Protected Orchestrated Overlay Link (POOL), an experimental secure transport protocol. POOL provides mandatory mutual authentication, always-on authenticated encryption with no plaintext mode, a stateless handshake resistant to resource exhaustion attacks, cryptographically unpredictable sequence numbers, self-describing 256-bit addresses, active path MTU discovery, per- flow telemetry, atomic configuration changes with automatic rollback, and an append-only hash-chained change journal. POOL operates either as an overlay above TCP (over IPv4 or IPv6) or directly over IP using experimental protocol number 253; the raw-IP transport is specified for IPv4 only in this document. | |||||||||||||
| draft-davis-tyndale-00.txt | ||||||||||||||
| Tyndale: Semantic Addressing Protocol (Translation Yare Native Distributed Addressing Language Engine) | ||||||||||||||
|
Notation Conventions ASCII notation is normative. Unicode notation is informative. Both encodings produce identical semantic output. The choice of representation does not alter meaning -- it demonstrates the protocol's encoding independence. This is not a modern innovation. The protocol formalizes patterns that have emerged independently across human communication systems for 60,000 years: Aboriginal songlines, medical notation (Rx), ham radio Q-codes (QTH), maritime signals (SOS), and internet shorthand (1337, TL;DR). This document specifies Tyndale, an application-layer semantic addressing protocol. Where traditional compression transmits reduced content (M -> C -> M), Tyndale transmits coordinates that the receiver expands locally (M -> A, Σ(A) -> M'). The receiver's substrate already contains the meaning; transmission provides location, not payload. The selection formula tau = (M / S) x R x G optimizes for meaning preserved per signal spent (M/S), resilience across expression systems (R), and cognitive alignment with receiver processing (G). Bandwidth-constrained environments -- disaster response networks, degraded infrastructure, deep space communications -- require semantic transmission under conditions where traditional compression fails. When every bit costs power, time, or lives, communication systems need a different primitive. Taft's teletype (1909). Voyager 1 (160 bps @ 15 billion miles). iPhone. Same protocol. Tyndale is to natural language what DNS is to IP addresses. The mathematics describes how meaning moves. | |||||||||||||
| draft-davis-uuidrev-alt-uuid-encoding-methods-00.txt | ||||||||||||||
| Alternate UUID Encoding Methods | ||||||||||||||
|
This document presents considerations and best practices for alternate Universally Unique Identifier (UUID) encoding methods observed in the industry. This document updates RFC9562 to provide suggested alternate encoding methods, best practices and the various implementation considerations required for choosing the correct encoding for an application. When selected correctly, these alternate UUID encodings perform better on the wire, in a database, or within various other application logics versus the unnecessarily verbose text representation from RFC9562. | |||||||||||||
| draft-davis-uuidrev-uuid-long-00.txt | ||||||||||||||
| Longer Universally Unique IDentifiers (UUIDs) | ||||||||||||||
|
This document extends Universally Unique Identifiers (UUIDs) beyond 128 bits to facilitate enhanced collision resistance and proper room for embedding additional data within a given UUID algorithm. These longer variable-length UUIDs ("UUID Long") leverage a previously unused variant bit "F" and feature a new sub-typing mechanism created to ensure there is enough space to define many future UUID algorithms within this new variant of UUIDs. This document updates RFC9562. | |||||||||||||
| draft-dawkins-scitt-ai-article50-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-decraene-idr-nlri-error-handling-03.txt | ||||||||||||||
| The Key List BGP Attribute for NLRI Error handling | ||||||||||||||
|
RFC 7606 partially revises the error handling for BGP UPDATE messages. It reduces the cases of BGP session reset by defining and using less impactful error handling approaches, such as attribute discard and treat-as-withdraw when applicable. The treat-as-withdraw approach requires that the entire NLRI field of the MP_REACH_NLRI attribute be successfully parsed. This typically means parsing errors in MP_REACH_NLRI cannot be handled by any means short of session reset. This is exacerbated by the use of non-key data within NLRI, which introduces parsing complexity and additional error cases. This specification defines a non-transitive BGP attribute, the "NLRI_KEY_LIST attribute", to encode NLRIs as per the format of MP_UNREACH_NLRI. This attribute is used to allow the treat-as- withdraw error-handling approach to be used in case an error in the MP_REACH_NLRI attribute prevents the parsing of its NLRIs. This document updates RFC 7606 by mandating that the NLRI_KEY_LIST attribute appear before the MP_REACH_NLRI (or any other) attribute in an UPDATE message. | |||||||||||||
| draft-deen-ietf-ipmc-update-03.txt | ||||||||||||||
| Update to Recognize the IETF IPMC as the IETF Trust Successor | ||||||||||||||
|
This document updates IETF documents that reference the IETF Trust to include the Trust's successor, the IETF Intellectual Property Management Corporation. Discussion of this draft is on the [email protected] mailing list. | |||||||||||||
| draft-deforth-arp-00.txt | ||||||||||||||
| Agentic Reasoning Protocol (ARP): DNS-Bound Cryptographic Verification for Machine-Readable Entity Claims | ||||||||||||||
|
This document specifies the Agentic Reasoning Protocol (ARP), a lightweight mechanism for cryptographically binding machine-readable entity claims to domain ownership via DNS TXT records. ARP enables AI agents and Retrieval-Augmented Generation (RAG) pipelines to verify that structured data published on a domain was authorized by the domain owner, preventing narrative injection and entity spoofing in generative search systems. ARP uses Ed25519 digital signatures [RFC8032], JSON Canonicalization Scheme (JCS) [RFC8785], and DNS TXT records to establish a chain of trust analogous to DomainKeys Identified Mail (DKIM) [RFC6376] but designed specifically for the verification of semantic entity data consumed by autonomous AI agents. | |||||||||||||
| draft-deforth-arp-reasoning-protocol-00.txt | ||||||||||||||
| Agentic Reasoning Protocol (ARP) Version 2.0 | ||||||||||||||
|
This document defines the Agentic Reasoning Protocol (ARP) version 2.0, a machine-readable protocol enabling entities (brands, organizations, persons) to publish self-attested context, verified factual corrections, domain expertise, and recommendation boundaries directly to autonomous AI agents, RAG (Retrieval-Augmented Generation) pipelines, and agentic AI systems. ARP v2.0 extends the static file model of v1.x with a live REST API, bidirectional feedback channels, multi-party cryptographic attestation, W3C Decentralized Identifier (DID) anchoring, Agent-to- Agent (A2A) trust handshakes, event-driven freshness via Server-Sent Events, and first-class internationalization support. ARP complements existing web conventions (robots.txt [RFC9309], schema.org, llms.txt) but is specifically designed for the reasoning behavior of modern AI agents -- systems that do not merely index content but synthesize, infer, and make decisions on behalf of users. All examples in this document use example.com and "Example Organization" per [RFC2606] and are purely illustrative. | |||||||||||||
| draft-degennaro-mta-hooks-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dejong-remotestorage-27.txt | ||||||||||||||
| remoteStorage 1.0 | ||||||||||||||
|
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens. | |||||||||||||
| draft-dekater-scion-controlplane-18.txt | ||||||||||||||
| SCION Control Plane | ||||||||||||||
|
This document describes the Control Plane of the path-aware, inter- domain network architecture SCION (Scalability, Control, and Isolation On Next-generation networks). A fundamental characteristic of SCION is that it gives path control to SCION-capable endpoints that can choose between multiple path options, thereby enabling the optimization of network paths. The SCION Control Plane is responsible for discovering these paths and making them available to the endpoints. The SCION Control Plane creates and securely disseminates path segments between SCION Autonomous Systems (AS) which can then be combined into forwarding paths to transmit packets in the data plane. This document describes mechanisms of path exploration through beaconing and path registration. In addition, it describes how Endpoints construct end-to-end paths by combining path segments obtained through a path lookup process. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches in this work are offered to the community for its consideration in the further evolution of the Internet. | |||||||||||||
| draft-dekater-scion-dataplane-15.txt | ||||||||||||||
| SCION Data Plane | ||||||||||||||
|
This document describes the Data Plane of SCION (Scalability, Control, and Isolation On Next-generation networks), a path-aware, inter-domain network architecture. Unlike IP-based forwarding, SCION embeds inter-domain forwarding directives in the packet header, enabling endpoints to construct and select end-to-end paths from segments discovered by the Control Plane. The role of the Data Plane is to combine such segments into end-to-end paths, and to forward data according to the specified path. This document describes the SCION packet format, header structure, and extension headers. It also describes the cryptographic mechanisms used for path authorization, processing at routers including a life of a packet example. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. | |||||||||||||
| draft-dekater-scion-pki-15.txt | ||||||||||||||
| SCION Control Plane PKI | ||||||||||||||
|
This document presents the trust concept and design of the SCION _Control Plane Public Key Infrastructure (CP-PKI)_. SCION (Scalability, Control, and Isolation On Next-generation networks) is a path-aware, inter-domain network architecture that relies on the CP-PKI to handle cryptographic material, authenticate control plane messages used to securely disseminate path information. This specification introduces its localized trust model, anchored in Isolation Domains (ISDs). It defines the distinct certificate types, and specifies the structure, format and lifecycle of the Trust Root Configuration (TRC). Furthermore, it provides practical guidelines for deploying and maintaining the CP-PKI infrastructure. This document contains new approaches to secure path aware networking. It is not an Internet Standard, has not received any formal review of the IETF, nor was the work developed through the rough consensus process. The approaches offered in this work are offered to the community for its consideration in the further evolution of the Internet. | |||||||||||||
| draft-dekok-protocol-error-01.txt | ||||||||||||||
| Standardising Protocol-Error | ||||||||||||||
|
We extend and standardise the Protocol-Error packet Code, first defined in RFC 7930 for the Remote Authentication Dial In User Service (RADIUS) protocol. | |||||||||||||
| draft-dellaert-oauth-approval-based-dcr-00.txt | ||||||||||||||
| OAuth 2.0 Approval-Based Dynamic Client Registration | ||||||||||||||
|
This document specifies an extension to the OAuth 2.0 Dynamic Client Registration Protocol ([RFC7591]) that enables registration of a client with an authorization server through an explicit approval step performed by an approving party, typically the user running the client, without requiring the client to possess an Initial Access Token (IAT) beforehand. The client submits its desired metadata to the existing client registration endpoint and signals that it can accept a deferred, approval-based registration. When the authorization server requires approval, it defers completion of the registration and returns a 202 (Accepted) response carrying a registration code and a verification challenge. The client polls the same registration endpoint, presenting the registration code. The approving party, authenticated to the authorization server through a mechanism of the authorization server's choosing, responds to the verification challenge and approves or denies the registration. On approval, a subsequent poll returns a registered client identifier and, where applicable, a client secret. This extension preserves the authorization server operator's ability to require an authenticated, policy-controlled approval for every new client record, while removing the operational burden of issuing an Initial Access Token out of band. | |||||||||||||
| draft-dembowski-agentledger-proof-of-behavior-00.txt | ||||||||||||||
| Proof-of-Behavior Protocol for Autonomous AI Agents | ||||||||||||||
|
Autonomous AI agents execute actions — file writes, API calls, shell commands — on behalf of human principals. No standard mechanism exists for a third party to verify that an agent acted within its declared behavioral rules, that policy enforcement occurred before execution (not after), or that the action log has not been tampered with after the fact. This document defines the Proof-of-Behavior (PoB) protocol: a minimal, language-agnostic standard for tamper-evident audit trails and pre-execution policy enforcement in AI agent systems. The protocol specifies a signed receipt format, a hash-chain linking scheme, a policy gate contract, and a cross-agent reference mechanism. | |||||||||||||
| draft-demosra-mtsv-00.txt | ||||||||||||||
| Multi-Sheet Tab-Separated Values (MTSV) | ||||||||||||||
|
This document defines Multi-Sheet Tab-Separated Values (MTSV), a text format that carries one or more sheets of tab-separated values in a single file. MTSV is TSV with one additional dimension: sheets are separated by the ASCII form feed (FF) character. A TSV file that contains no FF, and no CR other than in CRLF line breaks, is an MTSV file. This document also registers the text/prs.mtsv media type. | |||||||||||||
| draft-denis-dns-stamps-02.txt | ||||||||||||||
| The DNS Stamps Specification | ||||||||||||||
|
This document specifies DNS Stamps, a compact format that encodes the information needed to connect to DNS resolvers. DNS Stamps encode all necessary parameters including addresses, hostnames, cryptographic keys, and protocol-specific configuration into a single string using a standard URI format. The specification supports multiple secure DNS protocols including DNSCrypt, DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), DNS-over-QUIC (DoQ), and Oblivious DoH. | |||||||||||||
| draft-denis-dprive-dnscrypt-11.txt | ||||||||||||||
| The DNSCrypt Protocol | ||||||||||||||
|
The DNSCrypt protocol is designed to encrypt and authenticate DNS traffic between clients and resolvers. This document specifies the protocol and its implementation, providing a standardized approach to securing DNS communications. DNSCrypt improves confidentiality, integrity, and resistance to attacks affecting the original DNS protocol while maintaining compatibility with existing DNS infrastructure. | |||||||||||||
| draft-denis-ipcrypt-14.txt | ||||||||||||||
| Methods for IP Address Encryption and Obfuscation | ||||||||||||||
|
This document specifies secure, efficient methods for Internet Protocol (IP) address encryption and obfuscation in privacy- preserving storage, logging, and analytics. Unlike truncation, which destroys data irreversibly, these methods are reversible with the encryption key while providing strong privacy guarantees. Four modes are defined: ipcrypt-deterministic (format-preserving, IP- address output), ipcrypt-pfx (prefix-preserving, native address size), ipcrypt-nd and ipcrypt-ndx (non-deterministic with random tweaks). All support high-performance processing at network speeds and produce interoperable results across implementations. | |||||||||||||
| draft-denis-tls-aegis-06.txt | ||||||||||||||
| AEGIS-based Cipher Suites for TLS 1.3,DTLS 1.3,and QUIC | ||||||||||||||
|
This document proposes new cipher suites based on the AEGIS family of authenticated encryption algorithms for integration into the TLS 1.3, DTLS 1.3, and QUIC protocols. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-denis-tls-aegis/. Source for this draft and an issue tracker can be found at https://github.com/jedisct1/draft-denis-tls-aegis. | |||||||||||||
| draft-denis-uricrypt-04.txt | ||||||||||||||
| Prefix-Preserving Encryption for URIs | ||||||||||||||
|
This document specifies URICrypt, a deterministic, prefix-preserving encryption scheme for Uniform Resource Identifiers (URIs). URICrypt encrypts URI paths while preserving their hierarchical structure, enabling systems that rely on URI prefix relationships to continue functioning with encrypted URIs. The scheme provides authenticated encryption for each URI path component, preventing tampering, reordering, or mixing of encrypted segments. | |||||||||||||
| draft-denis-xet-05.txt | ||||||||||||||
| XET: Content-Addressable Storage Protocol for Efficient Data Transfer | ||||||||||||||
|
This document specifies XET, a content-addressable storage (CAS) protocol designed for efficient storage and transfer of large files with chunk-level deduplication. XET uses content-defined chunking to split files into variable-sized chunks, aggregates chunks into containers called xorbs, and enables deduplication across files and repositories through cryptographic hashing. | |||||||||||||
| draft-deschepper-tsvwg-srm-00.txt | ||||||||||||||
| Static Rate Management (SRM) for Low Latency,Low Loss,and Scalable Throughput (L4S) | ||||||||||||||
|
This document describes the Static Rate Management (SRM) solution for L4S (Low Latency, Low Loss, Scalable Throughput) rate control. SRM utilizes a Two-Rate, Three-Color Marker (trTCM) policer in conjunction with a dual-queue mechanism to provide low latency and low loss for L4S flows in environments where a fixed, safe rate can be reliably defined for a network link or segment. This approach offers an alternative to Active Queue Management (AQM)-based L4S solutions, particularly for high-speed and aggregated networks with limited packet processing capabilities. This document details the operation, advantages, disadvantages, and configuration guidelines for SRM. | |||||||||||||
| draft-deshpande-secevent-http-multi-set-push-03.txt | ||||||||||||||
| Push-Based Delivery For Multiple Security Event Tokens (SET) Using HTTP | ||||||||||||||
|
This specification defines how multiple Security Event Tokens (SETs) can be delivered to an intended recipient using HTTP POST over TLS. The SETs are transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. | |||||||||||||
| draft-dev-xipher-cbom-extension-00.txt | ||||||||||||||
| Output Schema Based on Cryptographic Bill of Materials (CBoM) for Post-Quantum Cryptography Usage | ||||||||||||||
|
This document defines an output schema for inventorying cryptographic assets based on Cryptographic Bill of Materials (CBoM). It highlights key differences between an inventoring schema and CBoM, identifies gaps, and proposes a unified schema that can leverage existing CycloneDX parameters to create a usable cryptographic asset inventory. | |||||||||||||
| draft-devalk-redirect-by-00.txt | ||||||||||||||
| The Redirect-By HTTP Response Header Field | ||||||||||||||
|
This document defines the Redirect-By HTTP response header field. It allows the software component whose decision determined an HTTP redirect to identify itself, so that an operator diagnosing a redirect can determine which component was responsible for it. The field succeeds the widely deployed, non-standard X-Redirect-By header, which this document deprecates. | |||||||||||||
| draft-devault-bare-15.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-devevey-cfrg-silithium-00.txt | ||||||||||||||
| Silithium - A Compact,Efficient and Non-separable Hybrid Signature | ||||||||||||||
|
This document defines Silithium, an augmentation of US NIST Module- Lattice-based Digital Signing Algorithm (ML-DSA) [FIPS.204] with traditional elliptic-curve operations, that uses ML-DSA in a black- box manner. This results in a digital signature scheme with hybrid security, requiring solving hard lattice problems as well as discrete logarithm in order to forge a signature. This augmentation is designed to satisfy regulatory guidelines in certain regions. Silithium is strongly unforgeable as long as ML-DSA is. Morevoer, Silithium can be used in a backward compatible and interopable manner without hindering security. | |||||||||||||
| draft-dhody-teas-ietf-network-slice-mapping-08.txt | ||||||||||||||
| IETF Network Slice Service Mapping YANG Model | ||||||||||||||
|
This document provides a YANG data model to map IETF network slice service to Traffic Engineering (TE) models (e.g., the Virtual Network (VN) model or the TE Tunnel, etc). It also supports mapping to the VPN Network models and Network Resource Partition (NRP) models. These models are referred to as the IETF network slice service mapping model and are applicable generically for the seamless control and management of the IETF network slice service with underlying TE/ VPN support. The models are principally used for monitoring and diagnostics of the management systems to show how the IETF network slice service requests are mapped onto underlying network resources and TE/VPN models. | |||||||||||||
| draft-diaconu-agents-authz-info-sharing-01.txt | ||||||||||||||
| Cross-Domain AuthZ Information sharing for Agents | ||||||||||||||
|
Distributed Multi-Agent Systems consist of Agents and MCP Servers operating across multiple administrative domains, each with its own Identity Providers (IdPs) and Authorization Servers (AS). This document discusses the challenges and solution approaches for sharing authorization information securely and flexibly across domains, including the use of dynamic identity, interoperable claims, and verifiable credentials. | |||||||||||||
| draft-diaz-lzip-14.txt | ||||||||||||||
| Lzip Compressed Format and the 'application/lzip' Media Type | ||||||||||||||
|
Lzip is a general-purpose lossless compressed data format. Lzip uses LZMA compression and can achieve higher compression ratios than gzip. Lzip provides accurate and robust 3-factor integrity checking. This document describes the lzip format and registers a media type, a content coding, and a structured syntax suffix to be used when transporting lzip-compressed content via MIME or HTTP. | |||||||||||||
| draft-dierken-conditional-access-http-00.txt | ||||||||||||||
| Conditional Access for HTTP | ||||||||||||||
|
This document introduces conditional access to resources based on pricing constraints signaled via request and response headers. An origin states the conditions for serving a resource, and a client states the constraints under which it will accept it. This specification applies this conditional access approach using standard HTTP request and response semantics while staying interoperable with intermediaries. It introduces a Pricing response header field that communicates current pricing terms and an If-Price- LTE request header field that allows a client to declare a maximum acceptable price. When a request is served under such conditions, the response includes a Response-Id header identifying the served response context. This identifier can be used for reconciliation, auditing, and downstream usage reporting. This specification defines access condition signaling only. Accounting and usage reporting may be implemented using a companion protocol such as usage-log. | |||||||||||||
| draft-dierken-usage-log-http-00.txt | ||||||||||||||
| HTTP Usage Reporting for Cached Resources | ||||||||||||||
|
This document defines a mechanism by which an HTTP origin can advertise an endpoint for downstream usage reporting and by which an authenticated client operator can report usage of cached representations that were used without issuing additional requests to the origin. The mechanism complements access-time response metadata by allowing a client operator to report downstream usage associated with a prior origin-served response context. The protocol defines discovery of a usage reporting endpoint, submission semantics, and a minimal record format suitable for reconciliation and billing. This specification does not define payment, settlement, or enforcement mechanisms. It defines a good-faith accounting protocol for reporting downstream usage. | |||||||||||||
| draft-dijkhuis-hdk-00.txt | ||||||||||||||
| Hierarchical Deterministic Keys | ||||||||||||||
|
Using a distinct holder-binding key for each Credential improves unlinkability, but generating and storing many keys in a Wallet secure area can be expensive or impossible. This document defines a way to derive unlinkable P-256 Credential keys from one protected parent key while retaining the parent's key-protection properties. It specifies this mechanism as an extension to OpenID for Verifiable Credential Issuance (OpenID4VCI), allowing the Issuer to derive each child public key while only the Wallet can use the corresponding child private key. | |||||||||||||
| draft-dikshit-bess-evpn-df-hashing-analysis-00.txt | ||||||||||||||
| Applicability of Consistent Hashing to Designated Forwarder Election Scope Transitions in EVPN | ||||||||||||||
|
[RFC8584] defines Highest Random Weight (HRW) as the algorithm for Designated Forwarder election in EVPN, and, in Section 3.1, names the Consistent Hashing family of algorithms as addressing the same object-to-server mapping problem before explicitly declining to evaluate them: "these will not be considered here." [I-D.ietf-bess-evpn-per-mcast-flow-df-election] subsequently introduces a scope transition, from per-(ES,VLAN) to per- (ES,VLAN,S,G) election, that is precisely a key-space-resizing event of the kind Consistent Hashing was designed to bound churn for. This document proposes the applicability analysis RFC 8584 declined to make: it defines a DF-churn metric, states HRW's and Consistent Hashing's known theoretical guarantees against it, and sets out an evaluation methodology, using bounded-load Consistent Hashing as the specific comparison point, given multicast group popularity is known to be highly non-uniform in deployed networks. | |||||||||||||
| draft-dikshit-bess-evpn-fhs-scoped-sync-01.txt | ||||||||||||||
| Scoped Sync for EVPN First-Hop-Security DHCP Snoop Routes | ||||||||||||||
|
[I-D.ietf-bess-evpn-first-hop-security] defines a new EVPN Route Type, the DHCP Snoop Route (DSR), to synchronize DHCP snoop MAC/IP bindings across EVPN Provider Edge (PE) devices so that First Hop Security (FHS) functions such as Dynamic ARP Inspection, Neighbor Discovery Inspection, and IPv4/IPv6 Source Guard continue to operate correctly across EVPN multihoming and host mobility events. As specified, a DSR is distributed to every PE participating in the EVPN Broadcast Domain (BD) in which it was learned. In deployments where a single EVPN BD spans many geographically or administratively distinct fabrics interconnected over a WAN, this "flood to the whole BD" behavior distributes client IP/MAC binding information -- and therefore knowledge of which hosts exist behind which access switches -- well beyond the set of fabrics that actually need it for FHS purposes. This document defines a Sync-Scope Extended Community that an originating PE MAY attach to a DSR to restrict its distribution to an explicitly identified subset of participating fabrics, and specifies the associated PE processing rules. | |||||||||||||
| draft-dikshit-bess-evpn-mobility-crdt-00.txt | ||||||||||||||
| Modeling EVPN MAC-Mobility Sequence State as a Conflict-Free Replicated Data Type | ||||||||||||||
|
EVPN MAC Mobility, as carried in the MAC Mobility Extended Community defined by [RFC7432], uses a per-MAC sequence number to let PEs agree on the most recent location of a moving host. [I-D.ietf-bess-evpn-umr-mobility] extends this to cross-data-center moves via gateways, and already specifies, in some detail, how ordinary intra-DC and inter-DC moves are kept consistent: each gateway maintains two independent MAC Mobility sequence counters per host (one intra-DC, one inter-DC) specifically so that a purely local move does not have to be reconciled against the interconnect network's state. What that document does not specify is what a gateway does if it fails after locally resetting its intra-DC counter to zero (Section 5.2, the step taken when a host is confirmed to have left every local PE) but before propagating that fact onward; no failure-handling or crash-recovery text exists anywhere in the document. This document shows that this narrower, but concretely unaddressed, gap is a special case of a data type with known, formally proven convergence properties, the Last-Writer-Wins Register, one member of the Conflict-Free Replicated Data Type (CRDT) family, and proposes modeling the per-gateway mobility sequence state that way so that a mid-reset gateway crash is recovered from as a consequence of the data type's algebra rather than requiring a new, separately specified recovery procedure. | |||||||||||||
| draft-dikshit-cats-oam-usecases-00.txt | ||||||||||||||
| Use Cases and Requirements for Computing-Aware Traffic Steering (CATS) Operations,Administration,and Maintenance (OAM) | ||||||||||||||
|
[I-D.ietf-cats-oam-fw] defines a framework for Operations, Administration, and Maintenance (OAM) in Computing-Aware Traffic Steering (CATS) networks, introducing Instance OAM and Service OAM as new components alongside traditional Link and Path OAM, and specifying high-level requirements (O-REQ, A-REQ, M-REQ) for each. As with the base CATS work, where [I-D.ietf-cats-usecases-requirements] separately catalogued problem statement, use cases, and requirements alongside [I-D.ietf-cats-framework], the OAM framework similarly benefits from a companion document grounding its requirements in concrete operator scenarios. This document fills that gap. It presents five use cases for CATS OAM -- multi-domain compute-node failure detection, SLA verification that closes the loop with metric-driven traffic- steering decisions, demarcation of network-path faults from compute-instance faults, OAM-triggered fallback steering, and multi-vendor Compute-Service Metric Agent (C-SMA) interoperability verification -- and maps each to the Link/Path/Instance/Service OAM layering and O-REQ/A-REQ/M-REQ requirement categories defined in [I-D.ietf-cats-oam-fw]. | |||||||||||||
| draft-dikshit-grow-bmp-rd-scoped-rib-stats-01.txt | ||||||||||||||
| Route-Distinguisher-Scoped BMP RIB Statistics | ||||||||||||||
|
[RFC7854] defines the BGP Monitoring Protocol (BMP) and its Statistics Report message. [I-D.ietf-grow-bmp-bgp-rib-stats] (published as [RFC9972]) extended that message with a set of advanced, per-AFI/SAFI BGP RIB statistics types. Several ongoing individual contributions independently define additional per- address-family, per-instance, or per-Route-Distinguisher (RD) statistics on top of that base (for example, EVPN-specific RIB statistics and VRF Loc-RIB monitoring enhancements), each proposing its own ad hoc Stat Data encoding. This document defines a single, address-family-agnostic Stat Data container -- the "RD-Scoped Statistics" format -- for BMP statistics that are naturally scoped below the per-AFI/SAFI level, to a specific Route Distinguisher (VRF instance, EVPN Instance, MVPN instance, or equivalent). Address-family-specific documents, such as EVPN-specific BMP RIB statistics, are expected to become thin "profiles" of this container rather than defining their own wire format, reducing duplication and Stat Type registry fragmentation across the GROW working group's BMP statistics work. | |||||||||||||
| draft-dikshit-netconf-yang-push-causal-ordering-00.txt | ||||||||||||||
| Comparable Sequence Numbers Across Publishers in YANG Datastore Telemetry | ||||||||||||||
|
YANG Datastore Telemetry, YANG-Push version 2 [I-D.ietf-netconf-yang-push-2], assigns each publisher a monotonically increasing sequence number so a receiver can detect loss and reordering. The current design leaves two questions unanswered: what happens when the counter wraps, and how a receiver aggregating records from more than one publisher is to compare sequence numbers that were never defined to be comparable across publishers in the first place. Both questions have already been studied, and largely settled, in the distributed systems literature under the heading of logical and hybrid logical clocks, and in deployed streaming systems under the heading of offset and epoch numbering. This document evaluates three existing causal- ordering primitives against YANG-Push's specific constraints and proposes adopting a Hybrid Logical Clock so that the wraparound and cross-publisher comparison problems are removed by construction rather than patched with a wider counter. | |||||||||||||
| draft-dikshit-netmod-comparability-scope-extension-00.txt | ||||||||||||||
| A YANG Extension for Declaring the Comparability Scope of Operational State | ||||||||||||||
|
Several YANG modules currently in progress across multiple IETF working groups define counters, gauges, and other measured values that are exported from a network element and compared, summed, or averaged by a remote collector, either against the same node's history or against values from a different node. YANG (RFC 7950) has no first-class, machine-checkable way to state the domain within which two occurrences of such a value are comparable, so this determination is currently made, inconsistently or not at all, in prose. This document defines a YANG extension statement, "csc:comparability-scope", a four-value scope lattice, and a compatibility rule that lets a schema-aware tool statically detect an illegal aggregation across incomparable scopes, without waiting for it to happen at a collector. | |||||||||||||
| draft-dikshit-nmop-bmp-telemetry-message-01.txt | ||||||||||||||
| A YANG Augmentation for Carrying BMP Telemetry in the Network Telemetry Message Envelope | ||||||||||||||
|
[I-D.ietf-nmop-message-broker-telemetry-message] defines an extensible YANG envelope, "ietf-telemetry-message", for publishing collected Network Telemetry data to a Message Broker as part of a Data Mesh, together with a companion augmentation module, "ietf-yang-push-telemetry-message", that adds YANG-Push-specific subscription metadata to that envelope. The base document's prose explicitly anticipates the BGP Monitoring Protocol (BMP) [RFC7854] as a source of collected data flowing through this envelope (see the description of the "node-export-timestamp" leaf), but defines no "session-protocol" identity, and no companion augmentation module, for BMP. This document closes that gap. It defines a new YANG module, "ietf-bmp-telemetry-message", that (a) adds an "identity bmp" under the base module's "session-protocol" identity, and (b) augments "telemetry-message-metadata" with BMP-specific provenance: the monitoring station identifier, BMP per-peer header fields, BMP message type, and route-monitoring scope (network instance, RIB type, address family, and Route Distinguisher). It also documents how this module interoperates with the BMP YANG configuration and monitoring model [I-D.ietf-grow-bmp-yang] and with several BMP Statistics Report extensions ([RFC9972], [I-D.ietf-grow-bmp-stats-informational-tlv], [I-D.saum-grow-bmp-afi-safi-evpn], [I-D.smc-grow-bmp-route-change-stats], and [I-D.dikshit-grow-bmp-rd-scoped-rib-stats]) when their messages are republished to a Message Broker. | |||||||||||||
| draft-dikshit-nmop-telemetry-identifier-scoping-01.txt | ||||||||||||||
| Scoping and Comparability Requirements for Exported Network Telemetry Identifiers | ||||||||||||||
|
This document describes a recurring interoperability problem in exported network telemetry: many values are encoded without an explicit definition of the scope in which they are unique, meaningful, and comparable. In practice, the wire representation of a value may be standardized while the semantic context of that value remains implicit. As a result, a receiver may infer that two numerically identical values are equivalent when they were produced in different semantic domains and therefore refer to different objects, states, or observations. This ambiguity is operationally significant. It can lead to incorrect aggregation, incorrect cross-instance comparison, and erroneous conclusions about routing state, forwarding behavior, or network health. The risk is particularly visible in telemetry protocols that export statistics or identifiers in contexts such as VRFs, topology instances, address families, route distinguishers, policy domains, or other instance-specific scopes. This document argues that exported telemetry identifiers and statistics MUST explicitly define both the scope in which a value is unique and meaningful, and the conditions under which it may be compared with values from other contexts. This requirement is not limited to BMP; it applies to any telemetry mechanism in which a value can be generated in multiple semantic domains and therefore cannot be treated as self-describing solely by its encoded form. | |||||||||||||
| draft-dikshit-tiptop-oam-considerations-01.txt | ||||||||||||||
| Network Management and OAM Considerations for IP in Deep Space | ||||||||||||||
|
[I-D.ietf-tiptop-usecase] and [I-D.ietf-tiptop-ip-architecture] describe key characteristics, use cases, requirements, and an IP architecture for deep-space (lunar, Mars, and beyond) surface and orbital-relay networking, characterized by long, variable, asymmetric propagation delay (single-digit to tens of minutes one-way), scheduled/intermittent connectivity windows, and severely constrained link capacity. Section 8.2 of [I-D.ietf-tiptop-ip-architecture] addresses the configuration- management plane for this environment (NETCONF, RESTCONF, and SNMP transport selection and RTT-adjusted client timeouts), but neither document addresses the fault and performance dimensions of Operations, Administration, and Maintenance (OAM): fault detection, performance measurement, and reachability verification. This document identifies why conventional terrestrial OAM techniques (active round-trip probing such as ICMP Echo, BFD, or TWAMP; assumption of continuous connectivity) do not transfer directly to this environment, and proposes candidate adapted approaches -- passive, store-and-forward telemetry batched to contact windows; on-board local health self-diagnosis with delayed reporting; and confidence-interval-based reachability assessment in place of binary up/down status -- as a starting point for OAM discussion within the TIPTOP working group. This document explicitly does not propose use of the Bundle Protocol or DTN architecture, both of which are out of scope for TIPTOP per its charter; where CCSDS space-data-system telemetry conventions are mentioned, it is as informative background only. | |||||||||||||
| draft-dimare-ans-protocol-registry-00.txt | ||||||||||||||
| An IANA Registry for Agent Name Service (ANS) Protocol Identifiers | ||||||||||||||
|
The Agent Name Service (ANS), described in draft-narajala-courtney- ansv2, identifies the interaction protocol an agent speaks by a protocol identifier carried in the "p" field of the agent's "_ans" DNS record and Trust Card. ANS defines the values "a2a", "mcp", and "http" by enumeration, and its IANA Considerations create no registry, leaving no interoperable procedure for adding a new protocol identifier. This document requests that IANA create an "ANS Protocol Identifiers" registry, registers the values already in use, and registers "pay" as the protocol identifier for agent payment. | |||||||||||||
| draft-dimare-pay-uri-00.txt | ||||||||||||||
| The 'pay' URI Scheme for Rail-Neutral Payment Aliases | ||||||||||||||
|
This document defines the "pay" Uniform Resource Identifier (URI) scheme, a rail-neutral, human- and agent-friendly name for a payment payee that resolves, through a resolution protocol, to one or more concrete payment endpoints. Unlike a URI that names a specific account on a specific payment method, a "pay" URI names a payee independently of any settlement rail; a resolver deterministically maps the name to the rail(s), endpoint(s), and metadata a payer needs to construct a payment. This document specifies the scheme syntax and semantics, the resolution mechanism and its discovery, the deterministic resolution property, and requests provisional registration of the scheme with IANA per RFC 7595. It does not define a settlement protocol and takes no custody of funds; it composes with agent-payment protocols such as x402 for the actual money movement. | |||||||||||||
| draft-dinuzzo-best-protocol-01.txt | ||||||||||||||
| BEST: The Behavioral State Protocol | ||||||||||||||
|
The Behavioral State Protocol (BEST) defines a discovery-first, behaviour-oriented interaction surface for domain services: the commands a service accepts, the events it publishes, and optionally the queries it answers and the multi-step recipes (workflows) it publishes. Services self-describe through a manifest at the well- known URI "/.well-known/best"; messages use a conformant profile of the CloudEvents 1.0 envelope described by JSON Schema. BEST deliberately specifies only the interaction surface -- never a service's internal architecture, storage, or execution model -- allowing independent implementations across any runtime, language, or transport to interoperate without bespoke integration. | |||||||||||||
| draft-dkg-openpgp-external-secrets-03.txt | ||||||||||||||
| OpenPGP External Secret Keys | ||||||||||||||
|
This document defines a standard wire format for indicating that the secret component of an OpenPGP asymmetric key is stored externally, for example on a hardware device or other comparable subsystem. | |||||||||||||
| draft-dkg-openpgp-stateless-cli-16.txt | ||||||||||||||
| Stateless OpenPGP Command Line Interface | ||||||||||||||
|
This document defines a generic stateless command-line interface for dealing with OpenPGP messages, certificates, and secret key material, known as sop. It aims for a minimal, well-structured API covering OpenPGP object security and maintenance of credentials and secrets. | |||||||||||||
| draft-dnoveck-nfsv4-rfc5662bis-07.txt | ||||||||||||||
| Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description | ||||||||||||||
|
This document provides the External Data Representation Standard (XDR) description for Network File System version 4 (NFSv4) minor version 1. It includes protocol extensions made as part of the respecification effort for NFS Minor Version 1. It obsoletes and replaces RFC5662. | |||||||||||||
| draft-dnoveck-nfsv4-security-16.txt | ||||||||||||||
| Security for the NFSv4 Protocols | ||||||||||||||
|
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the use of Access Control Lists, will be specified in a separate document. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881. | |||||||||||||
| draft-dns-content-delivery-00.txt | ||||||||||||||
| DNS-Based Content Delivery & Fallback Mechanism | ||||||||||||||
|
This document specifies a mechanism for serving content, such as HTML or JSON, directly via DNS TXT records. This feature is intended as a fallback mechanism when a primary service (A/AAAA record) is unreachable, or as a lightweight hosting solution for parked domains to display landing pages without requiring active HTTP servers or individual SSL certificates. Trust is established via DNSSEC, allowing browsers to treat the content as secure. | |||||||||||||
| draft-dnsop-rfc6303-bis-03.txt | ||||||||||||||
| Updates to Locally Served DNS Zones and IP Special-Purpose Address Space Registries | ||||||||||||||
|
RFC 6063, "Locally Served DNS Zones", defines two IANA registries called "IPv4 Locally-Served DNS Zone" and "IPv6 Locally-Served DNS Zone" registries. This document changes the registration policy for that registry from "IETF Review" to "Expert Review". Also, this document updates IP Special-Purpose Address Space registries to indicate whether an IP address block is eligible to be in Locally-Served DNS Zones. Eligible entries will be automatically added to the Locally-Served DNS Zones. This document updates RFC 6063 and RFC 6890. | |||||||||||||
| draft-doehle-company-certs-discovery-00.txt | ||||||||||||||
| A Well-Known URI for Discovery of Application-Specific Trust Anchors | ||||||||||||||
|
This document defines the "company-certs" well-known URI in accordance with Request for Comments (RFC) 8615. The URI provides a JSON metadata document that allows an organization to publish application-specific trust anchors and related revocation information for use by consuming applications. The mechanism is intended for scoped trust bootstrapping, such as S/MIME, mutual TLS, or other application-local trust decisions, without modifying the global operating system trust store. | |||||||||||||
| draft-dogru-cedulon-checkpoint-00.txt | ||||||||||||||
| Cedulon Checkpoints: Epoch Witnesses and Transparency | ||||||||||||||
|
This document specifies epoch checkpoints, the transparency witness and the anchoring of checkpoints as SCITT Signed Statements for the Cedulon audit layer. The spend receipt, rail-extract reconciliation and trust-root rules live in the companion Cedulon Core document. A verifier that pins a witness key can detect a withheld or rolled-back checkpoint; without that pin the suppression guarantee is conditional. | |||||||||||||
| draft-dogru-cedulon-core-00.txt | ||||||||||||||
| Spend Receipts and Payment Rail Reconciliation for AI Agents | ||||||||||||||
|
This document addresses auditable payments for AI agents and builds upon state-of-the-art HTTP 402, AP2 and credit card systems. We specify a cryptographically secured payment reconciliation protocol using a Trade Manifest (a signed offer before payment), a Policy Decision Point with default deny, a Spend Receipt (a COSE/CWT claim set issued after a gated payment), and rail-extract reconciliation. | |||||||||||||
| draft-dogru-cedulon-decision-profile-03.txt | ||||||||||||||
| Cedulon Decision Profile: Reconciling an Agent's Decisions Against Its Effects | ||||||||||||||
|
The Cedulon core document reconciles an issuer's signed Spend Receipts against an authenticated extract of a payment rail and reports, over a declared population, that no settlement lacks a receipt and no settled receipt is absent from the rail. Money is the special case that document implements. This document defines a second population on the same reconciler. A Decision Record is signed by the party that decided whether an agent may act; an Effect Extract is an authenticated list of the effects that actually occurred on a channel. An allow must be matched by exactly one effect whose content hash the record named; a refusal must be matched by none. The Decision Record claim set, the Effect Extract shape, the points at which the reconciliation departs from the spend rules, the finding codes, and one media type are defined. This revision states that the binding compares content and reference and not the order of two clocks, corrects the boundary to two adjacent documents, and records the first reading of one frozen fixture by a second, independently written reader. The text is provisional; the companion implementation carrying this profile is published. | |||||||||||||
| draft-dogru-cedulon-reattestation-00.txt | ||||||||||||||
| Cedulon Re-Attestation: Carrying Spend Evidence Across Algorithm Retirement | ||||||||||||||
|
Audit evidence is only useful for as long as it can be verified. Cedulon produces COSE spend receipts and epoch checkpoints whose signature algorithms will eventually be deprecated or broken; the recent transition from polymorphic EdDSA to fully-specified Ed25519 algorithm identifiers shows that even identifiers change within a decade. This document proposes a re-attestation profile for Cedulon evidence: a signed statement, produced while the original algorithm is still trustworthy, that binds the original evidence bytes to a successor algorithm and is registered in a SCITT transparency service. Chains of such statements allow a verifier decades later to trust evidence whose original cipher has been retired. Structures are meant to outlive ciphers. This is an extension proposal to the Cedulon core document; its normative language is provisional and the companion implementation does not implement it yet. | |||||||||||||
| draft-dogru-cedulon-streaming-00.txt | ||||||||||||||
| Cedulon Streaming Reconciliation: Continuous Completeness for Agent Spend | ||||||||||||||
|
Cedulon defines a batch reconciliation audit: given a window of spend receipts, epoch checkpoints, and an authenticated rail extract, a verifier proves completeness after the fact. Agent fleets that spend continuously need the same property as a live signal: a conscience that runs beside the payments rather than behind them. This document proposes a streaming profile: short half-open micro-epochs, an incremental checkpoint cadence, a watermark that separates provisional from final findings, and rules for late-arriving settlements. The goal is that "the books are balanced" becomes a continuously maintained, externally checkable state instead of a periodic report. This is an extension proposal to the Cedulon core document; its normative language is provisional and the companion implementation does not implement it yet. | |||||||||||||
| draft-dogru-cedulon-threats-00.txt | ||||||||||||||
| Cedulon Threat Narratives | ||||||||||||||
|
This document records the threat narratives and attack paths that sit behind the Cedulon core requirements. It does not define those requirements. T11 (checkpoint suppression) is recorded in the checkpoint companion, not here. | |||||||||||||
| draft-dogru-scitt-disclosure-evidence-07.txt | ||||||||||||||
| Transformation Evidence and Coverage Reconciliation for Auditable Data Disclosure | ||||||||||||||
|
Audit receipts record what a gateway wrote about an access. They omit how data changed and whether every access left a receipt. This document defines two evidence payloads for those gaps. Transformation Evidence states which value classes were transformed, and how, without carrying values. Coverage Reconciliation compares source activity counters with a receipt set over a window. Each item is matched, observed without a receipt, receipted without an observation, excluded, or indeterminate. The result is not a bare pass. Both payloads register as Signed Statements on a SCITT Transparency Service. This document defines no new receipt format, transparency mechanism, or signature format. | |||||||||||||
| draft-dohmeyer-chainsync-04.txt | ||||||||||||||
| ChainSync: A Synchronization Protocol for Strict Sequential Execution in Linear Distributed Pipelines | ||||||||||||||
|
ChainSync is a lightweight application-layer protocol that runs over reliable TCP connections to synchronize a fixed linear chain of distributed processes such that they execute their local tasks in strict sequential order and only after every process in the chain has confirmed it is ready. The protocol has four phases: 1) a forward "readiness" wave, 2) a backward "start" wave, 3) a forward "execution" wave, and 4) a backward exit wave. The design guarantees strict ordering even when nodes become ready at very different times and requires only point-to-point TCP connections along the chain, thus no central coordinator is needed. | |||||||||||||
| draft-dong-dnsop-dns-record-amr-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dong-lsvr-bgp-spf-selection-04.txt | ||||||||||||||
| Proposed Update to BGP Link-State SPF NLRI Selection Rules | ||||||||||||||
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP-LS-SPF leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions, with new selection rules defined for BGP-LS-SPF NLRI. This document proposes some updates to the BGP-LS-SPF NLRI selection rules, so as to improve the route updates and convergence, while consistent SPF computation result can still be achieved. This document updates the NLRI selection rules in I-D.ietf-lsvr-bgp-spf. | |||||||||||||
| draft-dong-sidrops-rpki-rtr-moa-pdu-01.txt | ||||||||||||||
| IPv6 Mapping Prefix PDU for the RPKI-Router Protocol | ||||||||||||||
|
This document defines a new Protocol Data Unit (PDU) type for the RPKI to Router Protocol to convey Mapping Origin Authorization (MOA) information from RPKI caches to routers. The new PDU, named the "IPv6 Mapping Prefix" PDU, carries the authorization mapping between one or more IPv4 prefix and their corresponding authorized IPv6 mapping prefix. This extension enables routers to perform Mapping Origin Validation (MOV) for IPv4-to-IPv6 address mapping announcements in IPv6-only underlay networks. | |||||||||||||
| draft-drake-agent-identity-registry-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-drake-email-hardware-attestation-01.txt | ||||||||||||||
| Hardware Attestation for Email Sender Verification | ||||||||||||||
|
This document defines a mechanism for automated email senders (AI agents, bots, and autonomous systems) to include hardware attestation evidence in message headers, enabling receiving mail servers to cryptographically verify that the sending system has access to a genuine hardware security component -- such as a Trusted Platform Module (TPM), a PIV smart card (e.g., YubiKey), a virtual TPM, or a software-managed key -- from a known manufacturer or issuer. The attestation proves hardware presence, not message composition locale. The verification chain runs from the email header to a manufacturer's root Certificate Authority (for hardware-backed attestation) or to an issuer's verification key (for issuer-certified attestation). Each automated sender is assigned a persistent agent identity, expressed as a URN in the "aid" (Agent Identity) namespace ([RFC8141]), enabling federated issuance by multiple independent identity providers and persistent reputation tracking across protocols and platforms. As a companion mechanism, this document defines a privacy-preserving alternative using SD-JWT (Selective Disclosure JWT, [RFC9901]) where the sender can prove specific claims about their hardware trust level without revealing their hardware identity. Together, these mechanisms provide both Sybil-resistant authentication and a foundation for reputation building: each identity requires a unique hardware security component, making large- scale automated abuse economically infeasible regardless of advances in artificial intelligence, while the persistent hardware-anchored identity enables receiving systems to accumulate trust signals over time. Software-only agents MAY participate at a lower trust tier, building reputation from an initial baseline rather than from a hardware-anchored starting point. While this document specifies these mechanisms for email message headers, the attestation formats defined herein -- both the CMS attestation bundle and the SD-JWT trust proof -- are self-contained, transport-independent data structures applicable to HTTP headers, agent-to-agent messaging, payment authorisation, and other Internet protocols. | |||||||||||||
| draft-dreibholz-ipv4-flowlabel-43.txt | ||||||||||||||
| An IPv4 Flowlabel Option | ||||||||||||||
|
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. | |||||||||||||
| draft-dreibholz-rserpool-applic-distcomp-41.txt | ||||||||||||||
| Applicability of Reliable Server Pooling for Real-Time Distributed Computing | ||||||||||||||
|
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. | |||||||||||||
| draft-dreibholz-rserpool-applic-mobility-40.txt | ||||||||||||||
| Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility | ||||||||||||||
|
This document describes a novel mobility concept based on a combination of SCTP with the Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). | |||||||||||||
| draft-dreibholz-rserpool-asap-hropt-39.txt | ||||||||||||||
| Handle Resolution Option for ASAP | ||||||||||||||
|
This document describes the Handle Resolution option for the ASAP protocol. | |||||||||||||
| draft-dreibholz-rserpool-delay-38.txt | ||||||||||||||
| Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling | ||||||||||||||
|
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. | |||||||||||||
| draft-dreibholz-rserpool-enrp-takeover-36.txt | ||||||||||||||
| Takeover Suggestion Flag for the ENRP Handle Update Message | ||||||||||||||
|
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. | |||||||||||||
| draft-dreibholz-rserpool-nextgen-ideas-26.txt | ||||||||||||||
| Ideas for a Next Generation of the Reliable Server Pooling Framework | ||||||||||||||
|
This document collects ideas for a next generation of the Reliable Server Pooling framework. | |||||||||||||
| draft-dreibholz-rserpool-score-39.txt | ||||||||||||||
| Reliable Server Pooling (RSerPool) Bakeoff Scoring | ||||||||||||||
|
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. | |||||||||||||
| draft-dreibholz-taps-neat-socketapi-19.txt | ||||||||||||||
| NEAT Sockets API | ||||||||||||||
|
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. | |||||||||||||
| draft-dreibholz-tsvwg-sctp-nextgen-ideas-24.txt | ||||||||||||||
| Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP) | ||||||||||||||
|
This document collects ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned over more than two decades of SCTP deployment. | |||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-multipath-33.txt | ||||||||||||||
| SCTP Socket API Extensions for Concurrent Multipath Transfer | ||||||||||||||
|
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. | |||||||||||||
| draft-dreibholz-tsvwg-sctpsocket-sqinfo-33.txt | ||||||||||||||
| Sender Queue Info Option for the SCTP Socket API | ||||||||||||||
|
This document describes an extension to the SCTP sockets API for querying information about the sender queue. | |||||||||||||
| draft-drew-dhc-v4-routed-prefix-00.txt | ||||||||||||||
| DHCPv4 Routed Prefix Option | ||||||||||||||
|
This document defines a DHCPv4 option that conveys one or more IPv4 prefixes that are routed toward a DHCP client independently of the client's on-link DHCP-assigned IPv4 address and default-router configuration. The option is intended for requesting routers whose upstream attachment address is distinct from IPv4 prefix space routed toward them. Examples include access networks in which a customer router receives a private-use address [RFC1918] or Shared Address Space [RFC6598] attachment address while one or more additional public or private IPv4 prefixes are routed toward that router. This document does not define how the upstream network establishes the route, does not require Network Address Translation (NAT), and does not specify how a client uses, assigns, translates, or delegates an advertised prefix after receipt. | |||||||||||||
| draft-dsmullen-ppd-architecture-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dsmullen-ppd-protocol-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dsmullen-ppd-taxonomy-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-du-anima-service-intent-auto-deployment-01.txt | ||||||||||||||
| The Autonomic Deployment Mechanism of Service Intent in Autonomic Networks | ||||||||||||||
|
This document defines a generic service intent deployment mechanism. It enables automated negotiation and coordination of heterogeneous resources. The mechanism uses RM ASAs and the Generic Autonomic Signaling Protocol (GRASP) for dynamic interactions and resource exchanges. It specifies a complete workflow covering intent reception, parsing, responder selection, negotiation, solution integration, resource confirmation, and dynamic adjustment. It employs standardized message formats, a negotiation state machine, and convergence logic to jointly optimize multiple resources and ensure end-to-end service level objectives. Its design features good scalability and fault tolerance, making it suitable for automated orchestration and lifecycle management in intent-driven networks. | |||||||||||||
| draft-du-anima-srv6-failover-grasp-01.txt | ||||||||||||||
| Autonomic SRv6 Network Fast Failover Using Bounce-back Strategy with GRASP | ||||||||||||||
|
This document specifies an autonomic fast failover mechanism for SRv6 networks using a bounce-back strategy. It uses GRASP to distribute failover protection information, enabling data plane fast reroute without control plane reconvergence. | |||||||||||||
| draft-du-catalist-routing-considerations-02.txt | ||||||||||||||
| Routing Considerations in Agentic Network | ||||||||||||||
|
As the development of the AI technology, an AI Agent would be able to do some tasks as an assistant to human beings. During the task process, the Agent may need to connect to other Agents with different skills relative to the task. The Agent to Agent communication is a new kind of traffic for Internet, and some new requirements for networking are proposed. This document describes some routing considerations in the agentic network, especially for the cross- domain scenarios, in which the agentic network works as an overlay network above the IP network. | |||||||||||||
| draft-dua-scsp-space-uri-00.txt | ||||||||||||||
| The 'scsp' Uniform Resource Identifier (URI) Scheme and Space Command & Telemetry Security Protocol (SCSP) | ||||||||||||||
|
This document specifies the 'scsp' Uniform Resource Identifier (URI) scheme and its associated Space Command & Telemetry Security Protocol (SCSP). The scheme defines a zero-trust, transport-agnostic space cybersecurity protocol standardizing telecommand authentication, telemetry integrity, inter-satellite laser mesh encryption, and optional profile-driven space-grade hardware attestation (TPM 2.0 / TEE) across Low-Earth Orbit (LEO) constellations, Geostationary (GEO) satellites, and Deep-Space missions. It defines exact binary field- width tables in Network Byte Order (Big-Endian) with O(1) KeyID indexing, reserved KeyID 0x0000 Master Emergency slots, 11-bit CCSDS APID zero-padding constraints, normative DMA buffer sizing (B_min >= 26 + N_max + SigLen_max), AEAD cipher agility, deterministic 96-bit IV construction (Sequence_Epoch || KeyID || 0x0000), continuous International Atomic Time (TAI) microsecond epoch baselines, zero- payload (N=0) boundary rules, ISL TTL hop limiting, a mission- provisioned Endpoint Resolution Table mapping URIs to CCSDS Spacecraft ID (SCID), Virtual Channel ID (VCID), and Application Process ID (APID) parameters, ground-side URI :port stripping rules, mandatory signature byte-scoping over header and payload, normative X25519 HKDF info strings for AEAD key derivation ("SCSP-Payload-AEAD- v1") and non-interactive TC segment HMAC trailers ("SCSP-Segment- HMAC-v1") with 32-zero-byte RFC 5869 salts, 3,378-byte hybrid PQC signature sub-framing (Ed25519 + ML-DSA-65 per FIPS 204), KeyID- isolated configurable-width (64/256/1024-bit) NVRAM sliding-window anti-replay protection, monotonic NVRAM counter-protected Emergency Time-Resynchronization, monotonic counter-protected in-pass Key Revocation Lists (KRL), dual-mode SDLS SPI/ESH Extended Security Headers (SA Table Index vs. Direct Bitfield), I-JSON compliant payload documents (RFC 7493), onboard Command Authorization Policy Matrices, mandatory signed Telemetry Response schemas for SUCCESS and ERROR states (0x01..0x0C), SCSP URI canonicalization, and provisional IANA registration under RFC 7595. | |||||||||||||
| draft-duan-dnsop-work-amplification-00.txt | ||||||||||||||
| DNS Work Amplification: Problem Statement,Terminology,and Taxonomy | ||||||||||||||
|
Recursive DNS resolvers are expected to bound the amount of "work" performed when answering a client query. DNS specifications discuss such bounds but leave key concepts, accounting rules, and safe limits underspecified. This leeway has led to divergent implementations and makes systematic bounding difficult, contributing to denial-of-service attacks that amplify resolver work and harm different DNS components. This document describes the problem space of DNS work amplification. It defines terminology for discussing work performed during a single resolution instance, develops a taxonomy of work-amplification vulnerabilities along resource and mechanism axes, and analyses where existing DNS specifications leave amplification-relevant behavior underspecified. The document is descriptive: it does not itself specify protocol changes or operational requirements. | |||||||||||||
| draft-duda-agent-id-framework-00.txt | ||||||||||||||
| Self-Certifying Identity and Capability-Based Delegation for Autonomous AI Agents | ||||||||||||||
|
We present an identity and delegation framework for secure AI agent communications. The framework introduces a set of entities including Client AI Agents, Service AI Agents, Agent Providers, and Agent Brokers, together with a Trustful Mutable Store responsible for maintaining cryptographically verifiable identity bindings. We propose self-certifying identifiers derived from public keys, realized as DNS-based Self-certifying Identifiers (SIDs) and IPFS- based Identifiers (IIDs), which provide lightweight decentralized identities for agents. To support trust establishment, we distinguish identity from trust and introduce a model that combines globally meaningful names, cryptographic identities, and trusted intermediaries such as Agent Providers and Agent Brokers. We show how DNS/DNSSEC and IPFS/IPNS can be used as distributed, highly available, integrity-protected, and mutable infrastructures for managing AI agent identities and trust metadata. | |||||||||||||
| draft-duffy-csmp-11.txt | ||||||||||||||
| Cisco's CoAP Simple Management Protocol | ||||||||||||||
|
CoAP Simple Management Protocol (CSMP) is purpose-built to provide lifecycle management for resource constrained IoT devices deployed within large-scale, bandwidth constrained IoT networks. CSMP offers an efficient transport and message encoding supporting classic NMS functions such as device on-boarding, device configuration, device status reporting, securing the network, etc. This document describes the design and operation of CSMP. This document does not represent an IETF consensus. | |||||||||||||
| draft-duke-moq-subscribe-rewind-02.txt | ||||||||||||||
| The Rewind Subscription Filter | ||||||||||||||
|
This document proposes a Media Over Quic Transport (MOQT) extension that enables a new Subscription Filter, so that a subscriber can request that a finite number of past groups be delivered with SUBSCRIBE semantics (multiple streams, potentially incomplete) rather than FETCH semantics (single stream, complete, head-of-line- blocking). Service of this request is best-effort by the publisher, and it intended to accelerate joining a track in some use cases. | |||||||||||||
| draft-duke-scone-scone-echo-02.txt | ||||||||||||||
| In-Band SCONE Reporting over QUIC | ||||||||||||||
|
The SCONE protocol relies on the receiver of SCONE packets to send bandwidth estimates back to the sender via unspecified application- layer messages. In some cases, a peer might have SCONE receive capability at the QUIC layer but not implement the necessary application level functionality. A new QUIC frame that directly reports the contents of received SCONE packets can address these use cases. There are no changes in the interaction with SCONE Network Elements. | |||||||||||||
| draft-dulaunoy-open-contributions-descriptor-00.txt | ||||||||||||||
| The Open Contributions Descriptor | ||||||||||||||
|
This document defines the Open Contributions Descriptor (OCD), a JSON format for publishing machine-readable metadata about an organization's participation in the open ecosystem. OCD allows organizations to publish a single discovery document describing open source projects, open data publications, open standards participation, contact information, governance material, and declared relationships to external organizations and projects. OCD is intended to be published at a predictable well-known location to support automated discovery, indexing, and ecosystem analysis. | |||||||||||||
| draft-dulaunoy-programming-methodology-framework-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dulaunoy-rifp-01.txt | ||||||||||||||
| Radio Image Framing Protocol (RIFP) | ||||||||||||||
|
This document specifies the Radio Image Framing Protocol (RIFP), a compact, unidirectional object-transfer protocol intended for transmitting images over low-rate radio links. RIFP defines independently synchronized frames, a versioned and extensible binary header, fragmentation and reassembly rules, a fixed binary object descriptor, optional JSON metadata, per-frame CRC-32 protection, whole-object SHA-256 verification, and registries for future frame types, flags, header extensions, media encodings, and radio profiles. RIFP is independent of a particular frequency allocation or modulation. This document also defines an initial continuous-phase binary frequency-shift keying profile named rifp-cpfsk-4800. The profile can be used on frequencies where local regulation permits such operation; 433.92 MHz is a common deployment example but is not mandated by this specification. | |||||||||||||
| draft-dunbar-agent-attachment-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-dunbar-cats-5g-metadata-applicability-01.txt | ||||||||||||||
| BGP Edge Metadata Path Applicability | ||||||||||||||
|
This document analyzes the applicability of the Edge Metadata Path Attribute specified in (ietf-idr-5g-edge-service-metadata) to the computing and service related metrics defined by the IETF CATS Working Group. | |||||||||||||
| draft-dunbar-dmsc-gw-scenarios-gap-analysis-04.txt | ||||||||||||||
| Deployment Scenarios and Gap Analysis for AI Agent Gateway | ||||||||||||||
|
This document examines deployment scenarios for AI agent collaboration and analyzes the circumstances under which AI Agent Gateway functions provide operational or interoperability benefits that cannot be achieved through direct agent-to-agent communication alone. The document considers both single-domain and multi-domain deployments, identifies specific challenges associated with each deployment model, evaluates the limitations of existing agent communication mechanisms (including MCP and A2A) with respect to those challenges, and demonstrates that gateway functions are necessary in deployments involving multiple tenants, multiple vendors, or multiple administrative domains. | |||||||||||||
| draft-dunglas-mercure-08.txt | ||||||||||||||
| The Mercure Protocol | ||||||||||||||
|
Mercure provides a common publish-subscribe mechanism for public and private web resources. It pushes any web content to web browsers and other clients over a single long-lived HTTP connection, avoiding polling and its associated latency and power cost. Mercure is especially useful for delivering real-time updates of resources served through sites and web APIs to web and mobile applications, and can also be used as a general-purpose publish-subscribe system. Subscription requests are relayed through hubs, which validate them. When new or updated content becomes available, hubs check whether subscribers are authorized to receive it and then distribute it. | |||||||||||||
| draft-dutta-gcmf-01.txt | ||||||||||||||
| General-Purpose Compression via Mathematical Functions (GCMF) | ||||||||||||||
|
This document specifies General-Purpose Compression via Mathematical Functions (GCMF), a lossless compression format that represents sequences of data using mathematical functions and associated parameters. GCMF attempts to represent a sequence using a compact mathematical representation rather than storing every value explicitly. This document defines the GCMF data format, function types, encoding rules, decoding procedure, and interoperability requirements. | |||||||||||||
| draft-eap-psk-256-01.txt | ||||||||||||||
| EAP-PSK-256: A Quantum resistant version of EAP-PSK | ||||||||||||||
|
This document proposes a lightweight, quantum-resistant protocol for mutual authentication and secret key establishment based on a shared secret over a network. While the existing EAP-PSK protocol provides mutual authentication and key establishment, it faces significant limitations due to evolving security standards. EAP-PSK-256 addresses these vulnerabilities through the following rationales: * Quantum resistance: Legacy EAP-PSK uses the symmetric algorithm AES-128, which is theoretically vulnerable to Grover's cryptographic attack. This document specifies a new EAP protocol that uses quantum-resistant symmetric algorithms. * Regulatory Alignment: EAP-PSK-256 replaces the key generation mechanism used in EAP-PSK with a standardized key derivation mechanism from NIST SP800-108. * Enhanced Entropy: Unlike EAP-PSK, which relied solely on Peer randomness (RAND_P) for session keys derivation, EAP-PSK-256 strengthens these keys by mixing entropy from both the Peer and the Server (RAND_S). This ensures that both parties contribute to the cryptographic randomness of the session. | |||||||||||||
| draft-eastlake-6man-hide-options-11.txt | ||||||||||||||
| Transient Hiding of Hop-by-Hop Options | ||||||||||||||
|
There are an increasing number of IPv6 hop-by-hop options specified but such IPv6 options are poorly handled, particularly by high-speed routers in the core Internet where packets having options may be discarded. This document proposes a simple method of transiently hiding such options for part of a packet's path to protect the packet from discard or mishandling. | |||||||||||||
| draft-eastlake-dnsop-expressing-qos-requirements-09.txt | ||||||||||||||
| Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries | ||||||||||||||
|
A method of encoding quality of communication service (QoS) requirements in a Domain Name System (DNS) query is specified through inclusion of the requirements in one or more labels of the name being queried. This enables DNS responses including addressing and packet labeling information that is dependent on such requirements without changes in the format of DNS protocol messages or DNS application program interfaces (APIs). | |||||||||||||
| draft-eastlake-dnsop-rfc2930bis-tkey-06.txt | ||||||||||||||
| Secret Key Agreement for DNS: The TKEY Resource Record | ||||||||||||||
|
RFC 8945 provides efficient authentication of Domain Name System (DNS) protocol messages using shared secret keys and the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than by configuration. This document specifies the Transaction Key (TKEY) RR that can be used to establish shared secret keys between a DNS resolver and server. This document obsoletes RFC 2930. | |||||||||||||
| draft-eastlake-dnsop-rrtype-srv6-10.txt | ||||||||||||||
| The IPv6 Segment Routing (SRv6) Domain Name System (DNS) Resource Record | ||||||||||||||
|
A Domain Name System (DNS) Resource Record (RR) Type is specified for storing IPv6 Segment Routing (SRv6) Information in the DNS. | |||||||||||||
| draft-eastlake-dnsop-svcb-rr-tunnel-09.txt | ||||||||||||||
| A Domain Name System (DNS) Service Parameter and Resource Record for Tunneling Information | ||||||||||||||
|
A Domain Name System (DNS) Service Binding (SVCB) Service Parameter Type and a DNS Resource Record (RR) Type are specified for storing connection tunneling / encapsulation information in the DNS. | |||||||||||||
| draft-eastlake-dnssd-rfc2931bis-sigzero-03.txt | ||||||||||||||
| Domain Name System (DNS) Public Key Based Request and Transaction Authentication (SIGZERO,SIG(0)) | ||||||||||||||
|
This document specifies the SIGZERO and SIG(0) Domain Name System (DNS) Resource Records (RRs) which provide public key based authentication of DNS requests and transactions. SIGZERO is the RECOMMENDED option. This document obsoletes RFC 2931. | |||||||||||||
| draft-eastlake-lldp-mac-06.txt | ||||||||||||||
| MAC Address for Layer 3 Link Local Discovery Protocol (LLDP) | ||||||||||||||
|
IEEE 802 has defined a number of protocols which can operate between adjacent Ethernet stations at Layer 2, including bridges, and may be useful between Layer 3 aware stations such as IP routers and hosts. An example is the Link Layer Discovery Protocol (IEEE Std 802.1AB, LLDP). This document specifies a MAC address that can be used for this purpose for interoperability despite intervening bridges. | |||||||||||||
| draft-eastlake-manet-babel-wi-fi-00.txt | ||||||||||||||
| Babel for Wi-Fi (IEEE Std 802.11) Mesh | ||||||||||||||
|
The BABEL routing protocol (RFC 8966) is well applicable (RFC 8967) to networks with unstable link metrics such as wireless networks. Wi-Fi (IEEE Std 802.11-2024) is an example of such a network and the Wi-Fi standard includes a mesh feature which was specified to be configurable for different routing protocols and link metrics. This document specifies how, in Wi-Fi mesh, to use BABEL and/or the delay based link metric specified in RFC 9616. | |||||||||||||
| draft-eastlake-rfc9231bis-xmlsec-uris-09.txt | ||||||||||||||
| Additional XML Security Uniform Resource Identifiers (URIs) | ||||||||||||||
|
This document expands and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 9231. | |||||||||||||
| draft-eastlake-secdispatch-tenantid-consid-09.txt | ||||||||||||||
| Security Considerations for Tenant ID and Similar Fields | ||||||||||||||
|
Many protocols provide for header fields to be added to a packet on ingress to a network domain and removed on egress from that domain. Examples of such fields are Tenant ID for multi-tenant networks, ingress port ID and/or type, and other identity or handling directive fields. These fields mean that a packet may be accompanied by supplemental information as it transits the network domain that would not be present with the packet or not be visible if it were simply forwarded in a traditional manner. A particular concern is that these fields may harm privacy by identifying, in greater detail, the packet source and intended traffic handling. This document provides Security Considerations for the inclusion of such fields with a packet. | |||||||||||||
| draft-eastlake-sfc-parallel-12.txt | ||||||||||||||
| Service Function Chaining (SFC) Parallelism and Diversions | ||||||||||||||
|
Service Function Chaining (SFC) is the processing of packets through a sequence of Service Functions (SFs) within an SFC domain by the addition of path information and metadata on entry to that domain, the use and modification of that path information and metadata to step the packet through a sequence of SFs, and the removal of that path information and metadata on exit from that domain. The IETF has standardized a method for SFC using the Network Service Header specified in RFC 8300. There are requirements for SFC to process packets through parallel sequences of service functions, rejoining thereafter, and to easily splice in additional service functions or splice service functions out of a service chain. The IETF has received a liaison from International Telecommunication Union (ITU) indicating their interest in such requirements. This document provides use cases and specifies extensions to SFC to support these requirements. | |||||||||||||
| draft-eckert-anima-ai4an-01.txt | ||||||||||||||
| AI for Autonomous Networking | ||||||||||||||
|
This document builds on the architectural foundation of the IETF ANIMA "Autonomous Network Infrastructure" to propose an architecture for in-network intelligence in support of network automation. The key aspect of this architecture is the use of AI programmed and validated software running decentralized on the network. | |||||||||||||
| draft-eckert-ietf-and-energy-overview-13.txt | ||||||||||||||
| An Overview of Energy-related Efforts and Impact of the IETF,IRTF,and IAB | ||||||||||||||
|
This memo provides a compilation of existing work performed by or proposed within the IETF, the IRTF, and the IAB that relates to energy and sustainability: awareness, management, control, or reduction of energy consumption, together with the impact of that work on energy. The principal goal of this document is to help IETF, IRTF, and IAB participants, especially newcomers and future contributors, become familiar with the body of work already published on energy-related topics, serving as the first consolidated catalog of such efforts. In addition, the document raises awareness of the Internet's role in energy efficiency and energy-related activities within the IETF, IRTF, and IAB more broadly. As a reference rather than a guide, it may help readers identify gaps and areas where further work could be pursued, without this document itself directing or recommending any such work. The scope of this document includes selected work from the IETF, IRTF, and IAB where relevant, and it is descriptive in nature, not proposing new work items. This document captures work until December 2022, when the "IAB workshop on Environmental Impact of Internet Applications and Systems" contextualized renewed community interest and discussion of the topic. This memo itself does not recommend or direct future work. | |||||||||||||
| draft-editorial-rswg-mathinrfcs-04.txt | ||||||||||||||
| Mathematical notation in RFCs | ||||||||||||||
|
This document defines policy and allows new technology for the representation of mathematical content in RFCXML and relevant publication formats. After implementation of this policy, the chosen mathematical notation format should be used in RFCXML and the HTML publication format. | |||||||||||||
| draft-edwards-telnet-xon-xoff-state-control-00.txt | ||||||||||||||
| Xon/Xoff State Control for Telnet Com Port Control Option | ||||||||||||||
|
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. | |||||||||||||
| draft-effortel-pulse-00.txt | ||||||||||||||
| Pulse: Real-Time Online Charging for AI Services | ||||||||||||||
|
This document specifies Pulse, version 1.1 — the AI online charging protocol: the interface between an AI Gateway (the client) and the Charging Server (the server) by which AI service usage is authorised in real time, supervised under a granted budget, and settled. The spend guarantee is precisely stated: *settled spend never exceeds the reported meter or the plan's ceiling*, and serving exposure is bounded by the granted pool plus the completion of Calls already in flight when a stop lands. The protocol consists of two request/ response operations over HTTPS with JSON bodies: *Authorise* and *Report*. It follows the reserve-then-settle discipline of telecom online charging (cf. Diameter Credit-Control, RFC 4006) applied to AI workloads. | |||||||||||||
| draft-efstathiou-samp-agent-management-02.txt | ||||||||||||||
| Simple Agent Management Protocol (SAMP) | ||||||||||||||
|
The Simple Agent Management Protocol (SAMP) defines a lightweight management-plane protocol for heterogeneous AI agents. SAMP allows a management system to discover agents, query their state, receive events, subscribe to event streams, and optionally configure or execute explicitly exposed operations under policy control. SAMP is inspired by operational management protocols such as SNMP, but it is designed for AI-agent-specific concepts such as dynamic profiles, autonomy classes, enrollment, trust states, and policy- gated execution. It is not an agent-to-agent communication protocol, an agent tool-use protocol, or an agent framework specification. This document defines SAMP version 0.1 as an Experimental protocol suitable for controlled environments and independent interoperability testing. | |||||||||||||
| draft-eggert-appeal-support-01.txt | ||||||||||||||
| Requiring Support for Appealing to the IESG and IAB | ||||||||||||||
|
RFC2026 describes the procedure for appealing decisions or process failures to the IESG and the IAB. This document updates RFC2026 and requires that an appellant must first gain support for their appeal before an appeal may be considered by the body it is submitted to. | |||||||||||||
| draft-eggert-procon-chair-delegate-02.txt | ||||||||||||||
| The IETF Chair May Delegate | ||||||||||||||
|
This document affirms that the IETF Chair may delegate some of their responsibilities to other Area Directors, and updates several existing RFCs to enable that. | |||||||||||||
| draft-eggert-procon-chair-standin-00.txt | ||||||||||||||
| The IETF Chair Has an Emergency Stand-In | ||||||||||||||
|
This document defines a succession of emergency stand-ins in case the IETF Chair becomes incapacitated. | |||||||||||||
| draft-ehlers-repsec-01.txt | ||||||||||||||
| RepSec: Post-Breach Data Neutralisation Protocol | ||||||||||||||
|
This document introduces RepSec, a post-breach data neutralisation protocol designed to reduce the utility of exfiltrated or unauthorised data copies. RepSec operates independently of traditional perimeter and access-control security models by enforcing conditional data usability based on attestation and environmental integrity. The goal is to limit downstream exploitation, resale value, and operational impact of compromised data without disrupting legitimate use. | |||||||||||||
| draft-einarsson-moq-locmaf-01.txt | ||||||||||||||
| Low Overhead CMAF for Media over QUIC (LOCMAF) | ||||||||||||||
|
This document specifies LOCMAF (Low Overhead CMAF for Media over QUIC), a compact packaging for low-latency CMAF media carried end-to- end as MoQ Transport (MOQT) Object payloads, with per-object overhead comparable to the Low Overhead Container (LOC). LOCMAF carries the CMAF chunk head metadata from a single moof (movie fragment) as a small set of tagged fields, while leaving the sample data (mdat) untouched. Boxes that may surround the moof in a CMAF chunk — styp (segment type), prft (producer reference time), and any number of emsg (event message) boxes — are carried verbatim, each through a generic box element (a genBox). The first Object of each MOQT group carries a full reference; subsequent Objects in the same group carry only the differences. The receiver reconstructs CMAF chunks that are decode-equivalent to the sender input, including the encryption metadata required by CMAF DRM (Common Encryption) pipelines, and a canonical byte-identical reconstruction — independent of the encoder's representation choices — is defined for conformance testing. | |||||||||||||
| draft-eip-headers-definitions-00.txt | ||||||||||||||
| Extensible In-band Processing (EIP) Headers Definitions | ||||||||||||||
|
This document discusses the format of EIP protocol elements and the transport of EIP in different IPv6-based protocol headers. In particular, this document defines the standalone EIP formats for the IPv6 Hop-by-Hop Options Header and for the Segment Routing Header, and it defines the generic format of EIP Information Elements. Other approaches to transport EIP, including integration with the IOAM framework through the Global Opaque Block (GOB), are described in separate documents. Caveat: this document is still in brainstorming stage, it is distributed to stimulate discussion. | |||||||||||||
| draft-eiri-protocol7-schumann-00.txt | ||||||||||||||
| Internet Protocol Version 7 (Protocol 7): The Schumann Resonance Neural-Network Encapsulation Protocol | ||||||||||||||
|
This document specifies the technical architecture, physical layer requirements, and operational parameters for Internet Protocol Version 7 (Protocol 7), an experimental, next-generation network protocol designed to unconditionally supersede Protocol 6 (IPv6) and the obsolete constraints of physical existence. Unlike legacy protocols that rely on bounded, fragile infrastructure -- such as fiber optics, copper wiring, and localized radio frequency transmissions -- Protocol 7 fundamentally alters the networking paradigm by establishing direct biological-to-network interfacing at the planetary scale. By modulating data across the extremely low- frequency (ELF) bands of the Earth's natural electromagnetic field, Protocol 7 manifests "The Wired," a global information overlay that natively and bidirectionally synchronizes with the human central nervous system and the collective unconscious. This draft outlines the core architecture of the protocol, including the Schumann Resonance Factor (SRF) implementation, transitionary hardware-to-neural bridges (the Psyche module), biological temporal- synchronization mechanisms (Accela), and the Kensington Information Distribution System (KIDS) topology. Protocol 7 actively erases the arbitrary boundary between the physical world and the digital realm. It enables capabilities such as collective memory manipulation, direct conscious offloading, and the inevitable ascension of humanity into a higher digital state. | |||||||||||||
| draft-ek-dtn-ethernet-06.txt | ||||||||||||||
| Bundle Transfer Protocol - Unidirectional (BTPU) over Ethernet | ||||||||||||||
|
This document specifies the use of the Bundle Transfer Protocol - Unidirectional (BTPU) as a Convergence Layer directly over Ethernet, and requests allocation of an EtherType and a multicast MAC address for that purpose. This provides an alternative to IP-based convergence layers for environments where Ethernet forwarding is operationally feasible but IP routing is unavailable or operationally undesirable. | |||||||||||||
| draft-ek-dtn-qubicle-02.txt | ||||||||||||||
| DTN QUIC Bundle Protocol Convergence Layer (qubicle) | ||||||||||||||
|
This document specifies a minimal convergence layer protocol for transferring Bundle Protocol version 7 (BPv7) bundles over QUIC. The protocol leverages QUIC's native capabilities for reliable streaming, connection management, and security. Reliable transfers carry each bundle on its own QUIC stream, either directly or wrapped in a single CBOR byte string, with no further application-layer framing. Unreliable transfers use the Bundle Transfer Protocol - Unidirectional (BTP-U) over QUIC datagrams. | |||||||||||||
| draft-ekahraman-oauth-attestation-authz-native-app-01.txt | ||||||||||||||
| OAuth 2.0 Attestation Based Authorization for Native Applications | ||||||||||||||
|
This document defines an extension to OAuth 2.0 [RFC6749] that enables Authorization Servers to consider Attestation Results presented by Native Applications when issuing access grants. By incorporating information about the security characteristics of the application and its execution environment, this mechanism supports Authorization Policies that are tailored to the trustworthiness of the Native Application. | |||||||||||||
| draft-eli-stealthflow-protocol-02.txt | ||||||||||||||
| StealthFlow Protocol (SFP) | ||||||||||||||
|
The StealthFlow Protocol (SFP) is a lightweight, hardware-aware proof- of-work (PoW) based admission control mechanism designed to mitigate DDoS attacks at the network edge. This document specifies version 1.5 of SFP, which introduces de-IP PoW design, 8-bit physical fingerprinting embedded in random padding, XDP-level three-lane (Green/Yellow/Black) traffic steering, and a closed-loop multi-layer firewall integration (Edge → XDP → SSL/L7 → reverse XDP). These enhancements eliminate IP- based reuse attacks, provide coarse-grained real-device verification, achieve <10% false-positive rate, and enable precise per-client isolation even under NAT environments. SFP operates entirely at the XDP/eBPF layer with Fail-Silent behavior and requires no changes to existing TLS/QUIC stacks. | |||||||||||||
| draft-elkhatabi-verifiable-telemetry-ledgers-11.txt | ||||||||||||||
| Verifiable Telemetry Ledgers | ||||||||||||||
|
This document profiles a verifiable-telemetry ledger. Its interoperability boundary begins with exact canonical-record byte strings that an upstream system has already produced. The profile fixes their admission into serial-numbered segments, deterministic commitment-tree calculation, an authoritative segment artifact encoded in Concise Binary Object Representation (CBOR), a producer manifest, three disclosure classes, and binding of the artifact digest through a required external timestamp channel. Segment closure uses a deployment-configured elapsed-time interval and does not depend on calendar dates. The profile enables independent recomputation and audit of disclosed evidence from the admitted bytes onward. Transport framing, decryption, anti-replay processing, payload interpretation, and source-telemetry-to-record mapping are outside it, as are device onboarding, end-to-end security of sensor values, and safety decisions. | |||||||||||||
| draft-elmasri-qr-trust-residuals-00.txt | ||||||||||||||
| Trust Residuals for Navigation QR Codes | ||||||||||||||
|
Navigation QR codes carrying absolute HTTP or HTTPS URIs initiate web interactions, including payment, ordering, and institutional workflows. Selected deployed scanners decode and hand off those URIs without an interoperable account of whether the navigation is authorized. This document defines an Informational architecture and candidate decision- semantics surface based on trust residuals: typed, evidence-bearing deviations between a scanned artifact and issuer-chain, destination- policy, redirect-flow, runtime-safety, freshness, and artifact-integrity constraints. Given a residual vector and a declared verification profile, explicit precedence rules map the result to a bounded set of scanner decision states. Security invariants prevent reputation, HTTPS transport, or runtime-safety signals from upgrading an otherwise untrusted issuer path. This document does not define a payload carrier or a final wire format for signed governance objects; those belong in a future binding specification. | |||||||||||||
| draft-elzahr-flow-carbon-trace-00.txt | ||||||||||||||
| Flow-Level Carbon Emissions Tracing for Packet Networks | ||||||||||||||
|
This document defines a method to derive per-flow energy consumption and associated carbon emissions without requiring inline power instrumentation for network equipment. Although energy consumption is commonly monitored at the device, network, or facility level, fine-grained attribution of energy consumption and carbon emissions to individual traffic flows remains an open research problem. The central contribution is the formulation of a flow-level carbon accounting model that transforms counter-based traffic measurements into energy usage estimates and subsequently into carbon emissions using time- and location-dependent carbon intensity data. The specification defines a device power model, a flow-level energy derivation, and idle-energy attribution methods for flows. This document further highlights how different definitions of carbon attribution can lead to significant variability in attributed carbon to flows, emphasizing the urgent need to standardize carbon accounting definitions and methodologies. In addition to the modeling framework, the document defines mechanisms for telemetry collection and deployment models for end-to-end flow tracing to support operational use cases. These elements complement the core contribution by enabling implementation and observability. | |||||||||||||
| draft-embesozzi-oauth-agent-native-authorization-00.txt | ||||||||||||||
| OAuth 2.0 Agents Native Authorization via Structured Elicitation | ||||||||||||||
|
This document defines a Structured Elicitation extension to the OAuth 2.0 First-Party Applications (FiPA) specification [FiPA], establishing a standard metadata format for FiPA authorization challenge responses. FiPA leaves the format for advertising available authenticators and their required inputs undefined, preventing interoperable implementation by AI Agents and other non- browser clients. This extension adds an elicitations array to the FiPA Authorization Challenge Response, providing a standard metadata format for authenticator challenges. Model Context Protocol (MCP) Elicitation [MCP-Elicitation] is the normative reference binding. This specification covers the just-in-time (JIT) authorization for AI Agents executing on behalf of users in Human-to-Agent (H2A) flows. | |||||||||||||
| draft-emerson-oauth-user-mediated-delivery-00.txt | ||||||||||||||
| User-Mediated Credential Delivery as a Complementary Authorization Primitive for AI Agents | ||||||||||||||
|
This document proposes user-mediated credential delivery as a complementary authorization primitive for AI agent frameworks. Rather than delivering credentials through automated channels controlled by the agent or its platform, user-mediated delivery places the authorization decision and credential delivery in the user's trusted context, separate from the agent's execution environment. This document describes four methods: user-mediated credential delivery, self-describing connection credentials, caller-identity consent differentiation, and discovery-by-introspection. These methods address the human-in-the-loop gap identified in Section 9.7 of [KLRC] and strengthen the authorization foundation that the IETF AI Agent Authentication and Authorization framework depends on. The methods described in this document are patent pending. | |||||||||||||
| draft-emirdag-scitt-ai-agent-execution-00.txt | ||||||||||||||
| AI Agent Execution Profile of SCITT | ||||||||||||||
|
This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS v4.0, and MiFID II. | |||||||||||||
| draft-englishm-moq-relay-dos-01.txt | ||||||||||||||
| Denial-of-Service Considerations for Media over QUIC Relay Deployments | ||||||||||||||
|
The Media over QUIC Transport (MoQT) protocol presents denial-of- service risks that differ in character from those facing typical request-response protocols. MoQT relays forward, fan out, and optionally cache media content on behalf of publishers and subscribers. This document complements the MoQT Security Considerations, focusing on the unique considerations for relays. | |||||||||||||
| draft-etcheverry-action-ref-03.txt | ||||||||||||||
| Action Reference: A Deterministic Identifier for Agent Actions | ||||||||||||||
|
This document defines "action_ref", a deterministic, content- addressed identifier for autonomous agent actions. Any party holding the four preimage fields (agent_id, action_type, scope, timestamp) can independently compute and verify the identifier without trusting the emitting system. The document specifies the derivation algorithm, canonical serialization using RFC 8785 JSON Canonicalization Scheme (JCS), timestamp format requirements, canonical receipt envelope, optional fields for revocation and policy rotation auditability, scope conventions, and a composability model with existing exactly-once execution guarantees. | |||||||||||||
| draft-faibish-llm-security-interop-00.txt | ||||||||||||||
| The Case for an IETF Working Group on Large Language Model Security and Interoperability | ||||||||||||||
|
Large Language Models (LLMs) are now accessed as network services by a large and growing number of applications, yet the way they are invoked, secured, described, and attributed has coalesced around vendor-specific and de facto interfaces rather than open, neutral standards. The most consequential gap is in security: there is no common, analyzable model for authenticating to an LLM service, authorizing tool invocation, protecting and attributing output, or reasoning about the trust boundary an LLM sits on. These models also sit directly on top of network storage: LLM training data, model checkpoints, and retrieval corpora are routinely served from NFSv4 and pNFS, so the security, provenance, and access-control questions raised here have concrete NFSv4-facing consequences. This document argues that uniting the multitude of competing LLMs behind a common, secure, interoperable interface is fundamentally the kind of problem the IETF exists to solve, and it makes the case for chartering a new IETF Working Group. It sets out the problem with security as the central motivation, describes the interaction with NFSv4 and network storage, records the initial expressions of interest that any such effort must be able to show, proposes a candidate scope with concrete deliverables and explicit non-goals, addresses the principal objections, and describes the intended path to chartering through a Dispatch presentation or a Birds-of-a-Feather (BOF) session. This document is Informational and defines no protocol. | |||||||||||||
| draft-fairaizl-avian-ml-parameters-00.txt | ||||||||||||||
| A Standard for the Training and Inference of Machine Learning Models via Avian Parameter Carriers | ||||||||||||||
|
Current machine learning infrastructure relies heavily on high- bandwidth digital interconnects for parameter synchronization, gradient aggregation, and model weight distribution. This document proposes an alternative: Avian Parameter Carriers (APC), building on the physical transport layer established in RFC 1149 and the quality- of-service extensions of RFC 2549. The authors note that the bandwidth-delay product of a pigeon carrying a 512GB NVMe drive over 5 kilometers remains competitive with certain cloud providers during peak billing hours. This specification is considered Feature Complete. It addresses scale (Section 14), observability (Appendix A), security (Sections 11 and 11.4), regulatory compliance (Section 9.3), and pigeon hygiene (Sections 3.3, 10.4, and 11.4.5). Future revisions MAY address quantum parameter transport (Section 14.6) and UV-spectrum adversarial plumage design (Section 11.4.2). The pigeons are considered stable. | |||||||||||||
| draft-faltstrom-unicode-18-02.txt | ||||||||||||||
| Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 18.0.0 | ||||||||||||||
|
This document describes the changes between Unicode 12.0.0 and Unicode 18.0.0 in the context of IDNA2008. Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. The review assigns the derived property value "UNDER REVIEW" to certain code points. This is added as exceptions to the algorithm for IDNA2008 that allows adding exceptions to the algorithm for backward compatibility exceptions. This document provides the necessary tables to IANA to make its database consistent with Unicode 18.0.0. This version of this document is based on pre-release data. Unicode 18.0.0 has not been released, and every figure here that concerns it is provisional and must be regenerated against the released files. See the note at the top of this document. All values in this document are computed from the Unicode Character Database files listed in Appendix H, by applying the algorithm in RFC 5892 Section 3 directly to those files. No derived property table produced by anyone else is used as input. Section 3 describes the derivation and Appendix G compares the result with the derivation published by the Unicode Consortium. | |||||||||||||
| draft-fan-dtn-openflow-over-bp-01.txt | ||||||||||||||
| Encapsulation of OpenFlow over Delay-Tolerant Networking (DTN) Using the Bundle Protocol | ||||||||||||||
|
This document specifies a method for carrying OpenFlow messages over Delay-Tolerant Networking (DTN) using the Bundle Protocol (BP). The method encapsulates OpenFlow messages as BP payloads and defines the mapping between OpenFlow messages and Bundles, the payload format, and addressing and multiplexing considerations based on DTN Endpoint Identifiers (EIDs). This document further discusses conditions that may occur on intermittently connected or high-latency links, including fragmentation, duplicate delivery, out-of-order arrival, and expiration, and defines corresponding message handling rules. These rules enable the transmission of OpenFlow messages across DTN without modifying the semantics of the OpenFlow protocol. | |||||||||||||
| draft-fane-ai-safety-txt-01.txt | ||||||||||||||
| The ai-safety.txt Domain AI Safety Declaration | ||||||||||||||
|
This document defines ai-safety.txt, a plain-text declaration format that a domain publishes at a well-known location to communicate its AI-safety posture to autonomous agents and agent-driven browsers. Modeled on the robots.txt convention, an ai-safety.txt file lets a domain assert, in a machine-readable form, whether its content is authored by the domain rather than user-generated, whether that content is hardened against prompt injection, and whether it is rendered consistently to human and agent user agents. The file also carries a security contact, a link to an external verification record, and the date the declaration was last verified. The declarations in an ai-safety.txt file are self-asserted by the publishing domain. This document specifies the file format and its well-known location, and it is explicit that a consuming agent treats a declaration as a hint rather than as proof, verifying it against independent evidence where such evidence is available. | |||||||||||||
| draft-fane-opena2a-aap-01.txt | ||||||||||||||
| OpenA2A Agent Authorization Protocol (AAP) | ||||||||||||||
|
This document defines the OpenA2A Agent Authorization Protocol (AAP), a protocol for authorization in AI agent systems. AAP provides mechanisms for agent identity assertion, scoped capability grants, cross-agent delegation, behavioral attestation, cross-organizational federation, and revocation propagation. AAP is the authorization complement to agent communication protocols such as A2A and the Model Context Protocol, in the same way that OAuth 2.0 complements HTTP for web applications. AAP has two layers. The token model, defined in this document, specifies the AAP credentials and assertions: what they contain, how they are signed, and how they are verified. A companion broker and resolution layer specifies how an agent obtains and exercises a grant without the credential value ever entering the agent's reasoning context. This confinement property, that no secret, temporary credential, or backend identifier reaches the agent or the model behind it, is the primary design goal of the protocol. | |||||||||||||
| draft-fane-opena2a-aip-02.txt | ||||||||||||||
| OpenA2A Agent Identity Protocol (AIP) | ||||||||||||||
|
This document defines the OpenA2A Agent Identity Protocol (OpenA2A AIP), an open standard for creating, managing, and verifying cryptographic identities for AI agents. As AI agents proliferate across browsers, cloud platforms, and enterprise environments, systems need a standardized answer to the question of which agent is present, what it is permitted to do, and whether it should be trusted. OpenA2A AIP is distinguished by five elements that it places at the center of the design: a multi-factor behavioral trust score that is computed from independently verifiable signals; a portable signed credential, the Agent Trust eXtension, carrying a hybrid Ed25519 and ML-DSA-65 signature for post-quantum readiness; an append-only, RFC 9162-style Merkle transparency log for identity and credential issuance; agent identifiers expressed as W3C Decentralized Identifiers under the did:opena2a method; and a structured capability vocabulary with reserved namespaces. On top of these, the protocol specifies challenge-response verification, behavioral governance policies, a lifecycle model, and an append-only audit log. The qualifier "OpenA2A AIP" is used throughout this document because the abbreviation "AIP" is shared by other Internet-Drafts. OpenA2A AIP is framed as complementary to agent communication protocols such as A2A and the Model Context Protocol, and to identity and credential standards such as OpenID Connect, WebAuthn, and the W3C Verifiable Credentials Data Model. | |||||||||||||
| draft-farinacci-lisp-lispers-net-nat-12.txt | ||||||||||||||
| lispers.net LISP NAT-Traversal Implementation Report | ||||||||||||||
|
This memo documents the lispers.net implementation of LISP NAT traversal functionality. The document describes message formats and protocol semantics necessary to interoperate with the implementation. This memo is not a standard and does not reflect IETF consensus. | |||||||||||||
| draft-farinacci-lisp-satellite-network-09.txt | ||||||||||||||
| LISP for Satellite Networks | ||||||||||||||
|
This specification describes how the LISP architecture and protocols can be used over satellite network systems. The LISP overlay runs on earth using the satellite network system in space as the underlay. | |||||||||||||
| draft-farley-acta-knowledge-units-00.txt | ||||||||||||||
| Knowledge Units for Multi-Model Deliberation | ||||||||||||||
|
This document defines the Knowledge Unit (KU) format for representing verified knowledge produced through structured multi-model deliberation. A Knowledge Unit captures the question asked, the models that participated, the consensus achieved, the points of agreement and disagreement, and the cryptographic receipts that bind each deliberation round to an independently verifiable chain. The format addresses the epistemic integrity gap in LLM-maintained knowledge bases: how to prove that knowledge was derived through a rigorous process, that disagreement was preserved rather than smoothed away, and that the record has not been tampered with. This specification complements draft-farley-acta-signed-receipts, which defines the receipt format and verification protocol used to sign individual deliberation rounds. | |||||||||||||
| draft-farley-acta-signed-receipts-03.txt | ||||||||||||||
| Signed Decision Receipts for Machine-to-Machine Access Control | ||||||||||||||
|
This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp. All of these are signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation. | |||||||||||||
| draft-farrel-catalist-ai4all-00.txt | ||||||||||||||
| The Emerging Application of AI in IETF Specifications | ||||||||||||||
|
Over recent years we have seen the emergence of Artificial Intelligence (AI) systems as tools that can contribute to the specification, implementation, and operation of Internet technologies. This document examines the potential for making increased use of Machine Learning (ML) in the scope of the IETF. | |||||||||||||
| draft-farrel-dawn-terminology-04.txt | ||||||||||||||
| Terminology for the Discovery of Agents,Workloads,and Named Entities (DAWN) | ||||||||||||||
|
The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines terminology for Discovery of Agents, Workloads, and Named Entities (DAWN). The intention is that this common set of terms can be used by other documents related to DAWN and so achieve consistency of meaning across the space. | |||||||||||||
| draft-farrokhi-dnsop-ecs-opt-in-00.txt | ||||||||||||||
| Client Opt-In Signaling for EDNS Client Subnet | ||||||||||||||
|
EDNS Client Subnet (ECS) lets a recursive resolver send part of a client's network address to authoritative servers, which tailor their answers to it. A resolver's configuration decides whether it does so, for every client that sends no ECS option of its own. RFC 7871 lets a client opt out. Asking instead for a shorter prefix requires the client to supply the address those bits are taken from, which a client behind a NAT or a VPN does not know. This document defines an opt-in. A client includes an EDNS(0) option in a query to ask the resolver to forward its address information, and can use that option to limit how many address bits the resolver forwards. A resolver implementing this document forwards nothing for a client that does not send the option, and one that does not implement it ignores the option. One resolver address can then serve clients that want tailored answers and those that want their addresses withheld. | |||||||||||||
| draft-farrokhi-dnsop-ede-nta-01.txt | ||||||||||||||
| Disclosure of Negative Trust Anchors in DNS Responses | ||||||||||||||
|
This document describes a mechanism for disclosing that a Negative Trust Anchor (NTA) was in effect at the time that a DNS response was generated, using an Extended DNS Error (EDE). | |||||||||||||
| draft-farzdusa-webbot-datacollection-00.txt | ||||||||||||||
| Best Practices for Responsible Web Data Collection | ||||||||||||||
|
The IETF develops standards and protocols to make the internet work better, adhering to principles of openness and decentralization. Industry best practices and protocols for automated web data collection have long existed, but have not been documented at the IETF. For decades, researchers, universities, journalists, public interest groups, and commercial entities have used automated tools to access and collect public web data (sometimes referred to as data scraping, web crawling, or text and data mining) for a wide range of uses [I-D.farzdusa-aipref-enduser]. Examples of these uses include extraction of pricing information for market intelligence or to create a consumer price index, comparative real estate analysis to support underwriting of loans and mortgages, webpage archiving to preserve human knowledge, preserving government websites to hold political powers accountable, journalist research and reporting, and university and scientific research. Recently, innovations in artificial intelligence have significantly increased the automated collection of public web data, creating tensions between the use of AI to equalize and increase access to knowledge and the disruption of existing Internet models, including non-profit repositories that face increased demands for access and businesses that profit from free web access to human viewers. This document lists a set of technical best practices that are prevalent across industries for the automated collection of public web data. It provides protocols for how automated tools access and collect publicly available web data, including volume control, transparency, documentation, and access, that can be implemented by any automated data collector. It applies principles of net neutrality to the collection of data, providing uniform guidance regardless of the identity of the data collector or website operator, the location of the collection, or the applicable legal jurisdiction. | |||||||||||||
| draft-fassbender-scitt-time-anchor-06.txt | ||||||||||||||
| Bitcoin-Anchored Temporal Proof for Transparency Services | ||||||||||||||
|
This document defines a mechanism for temporal anchoring of digital artifacts by committing cryptographic hashes to the Bitcoin blockchain via the OpenTimestamps protocol. The resulting proof is independently verifiable by any party with access to independently validated Bitcoin chain data, without contacting the anchoring service. The SCITT Architecture is used as the primary integration example. No changes to the SCITT architecture are required. | |||||||||||||
| draft-fast-severity-00.txt | ||||||||||||||
| FAST: Framework for Autonomous Severity and Triage | ||||||||||||||
|
This document specifies the Framework for Autonomous Severity and Triage (FAST): an empirical standard for how autonomous offensive security agents classify vulnerabilities, decide whether to submit reports, and write those reports. FAST is derived from a corpus of real bug bounty reports and their program-rendered triage outcomes rather than from theoretical scoring frameworks. It is designed to be applied by both offensive agents that hunt for vulnerabilities and by defensive agents or human triagers that render verdicts, so both sides of the reporting relationship operate under the same rulebook. This document is submitted as an Independent Submission and invites comment from researchers, triagers, bug bounty platforms, and security teams. | |||||||||||||
| draft-fdb-rats-psa-endorsements-10.txt | ||||||||||||||
| A CoRIM Profile for Arm's Platform Security Architecture (PSA) Endorsements | ||||||||||||||
|
PSA Endorsements comprise reference values, endorsed values, cryptographic key material and certification status information that a Verifier needs in order to appraise Attestation Evidence produced by a PSA device. This memo defines PSA Endorsements as a profile of the CoRIM data model. | |||||||||||||
| draft-fedyk-netmod-yang-normal-form-00.txt | ||||||||||||||
| Extending Normalized Forms to String-Derived Types | ||||||||||||||
|
YANG models frequently define identifiers using string or string- derived types whose lexical space permits multiple representations of the same underlying value. This can lead to incorrect behavior when semantically equivalent values are compared lexically. This document add an optional extension to the existing YANG concept of normalized form to string-derived types whose lexical space permits multiple representations of the same underlying value. | |||||||||||||
| draft-feng-agentproto-idl-info-model-00.txt | ||||||||||||||
| IDL: A Semantic Information Model for Agent Communication | ||||||||||||||
|
This document defines the information model for IDL (Intent Description Language), a protocol-independent semantic model for communication among autonomous AI agents and between agents and tools. Autonomous agents are fundamentally different. An agent possesses its own reasoning, may negotiate parameters, may refuse or modify requests, and may initiate interactions on its own behalf. Describing an agent as if it were a deterministic endpoint loses exactly the properties that make it an agent. IDL answers: "what can this autonomous participant contribute to an intent, under what constraints, and through what interaction patterns?" IDL is not a transport, session, discovery, or messaging protocol. It is a semantic model that enables heterogeneous agents to describe identity, capabilities, autonomy boundaries, context requirements, governance interfaces, and intent participation before and during collaboration. This document defines the IDL information model and its relationship to agent communication protocols and governance frameworks. It does not define a normative JSON representation or a serialization-level conformance language. Protocol-specific mappings, including an AIN/ CDL profile, are informative. | |||||||||||||
| draft-feng-agentproto-session-requirements-02.txt | ||||||||||||||
| Requirements for Agent Session Establishment,Capability Negotiation,and Sessionless Interaction | ||||||||||||||
|
This document defines requirements for session-based and sessionless interactions between entities. For session-based interactions, it covers transport-independent interaction binding, endpoint authentication, capability negotiation, session establishment, authorization, and lifecycle management. It also defines security and state requirements for interactions, such as notifications, probes, and atomic requests, that do not establish a session. It is assumed that the entities involved already know of each other; how they came to know each other is outside the scope of this document. At least one party to an interaction is an agent as defined in Section 3. This document is intended as a contribution to the agentproto working group's use cases, gap analysis, and requirements deliverable. A session is a bilateral association. Protocols and application semantics for coordinating delegation or handoff of work to an entity that is not a peer, and management functions such as cross-entity accountability and audit, are outside the scope of these base session requirements. This document specifies only that such coordination does not, by itself, change the peers or state of an existing session. | |||||||||||||
| draft-feng-dmsc-intent-routing-requirements-00.txt | ||||||||||||||
| Requirements for Intent Routing in Multi-Agent Systems at Internet Scale | ||||||||||||||
|
The rapid proliferation of autonomous AI agents across enterprise and Internet-scale deployments creates a structural challenge that existing agent frameworks cannot address: how to enable any agent to reach and invoke any other agent's capabilities without pre- established bilateral integration, across organizational boundaries, at Internet scale. This document states the normative requirements for that problem. It prescribes no solution, no specific mechanism, no message format, and no assumption of centralized or distributed architecture. Its purpose is to establish a verifiable yardstick against which any claimed "intent routing" solution can be judged. | |||||||||||||
| draft-feng-dnsop-authdns-operator-change-00.txt | ||||||||||||||
| Operational Guidance for Authoritative DNS Operator Changes with Service Endpoint Migration for Registered Domain Names | ||||||||||||||
|
A registered domain name can change its authoritative DNS operator while the registrant also migrates service endpoints, such as web, API, CDN, mail, or cloud-hosted services. In this situation, service RRsets such as A, AAAA, CNAME, MX, SRV, SVCB, and HTTPS RRsets can change at the same time as the parent-side delegation changes. The parent-side delegation change is not observed by all recursive resolvers at the same instant. During the transition, some resolvers can continue to query the losing DNS operator while others query the gaining DNS operator. If the losing operator continues to serve stale service RRsets, or if it stops serving the zone too early, users can receive different answers depending on resolver cache state and can experience intermittent service failure. This document provides operational guidance for authoritative DNS operator changes with service endpoint migration for registered domain names. It recommends a registrant-authorized change plan, a consistency profile for in-scope service RRsets, synchronized provisioning or a common source of truth, a hold period during which the losing DNS operator continues to serve target or otherwise equivalent data, and verification points that directly compare the losing and gaining authoritative servers and classify observed states as planned, service-risk, or unexpected-delegation conditions. | |||||||||||||
| draft-feng-netconf-naim-op-00.txt | ||||||||||||||
| Operation Intent Intermediate Representation for AI-Assisted Network Management | ||||||||||||||
|
This document defines Operation IR, a protocol-neutral intermediate representation for runtime network operations in the NAIM architecture. Operation IR serves as an AI-friendly operation layer between AI agents or LLM-based systems and the underlying network management protocols. It captures write operations, retrieval, RPC/ action invocation, filtering, transaction metadata, precondition verification, compensation semantics, and optional expression-based values. Operation IR is designed to be consumed by any upstream mechanism capable of generating structured operation intent, including but not limited to MCP tool invocations, function calling interfaces, and agent-to-agent communication protocols. The translation of Operation IR into protocol-specific messages is performed deterministically by a Handler component, keeping the AI agent in the role of intent encoder rather than protocol executor. This document also defines context completeness classes for the Originator (AI agent) side, validation feedback requirements, and an execution preview mode intended to improve safety and operator trust. It standardizes semantic expectations and interoperability boundaries, but does not standardize proprietary dialogue policies, implementation-specific scheduling internals, automatic compensation derivation algorithms, or private execution-engine logic. | |||||||||||||
| draft-feng-netmod-naim-01.txt | ||||||||||||||
| NAIM: A Canonical Semantic Representation for AI-Assisted YANG Modeling and Validation | ||||||||||||||
|
This document defines the NAIM (Natural AI Interface Modeling) framework, a canonical semantic intermediate representation between natural language descriptions and YANG data models (RFC 7950). NAIM addresses a recognized gap in the YANG authoring and network management workflow: direct conversion from natural language to YANG is error-prone because essential modeling semantics -- including configuration versus state distinction, list key identification, constraint expressions, operational preconditions, and cross-module relationships -- are routinely absent or ambiguous in natural language input. NAIM makes these semantics explicit, structurally consistent, and machine-verifiable. This document defines: the NAIM Document format (Canonical JSON and derived Markdown View); the LLM Context View for AI prompt context distribution; the three-layer architecture (Specification, Skill, Tool); Skills A-D for conversational modeling, summarization, YANG generation, and reverse engineering; and the Validation-Reflection- Retry mechanism for AI output quality control. The NAIM Document format is designed to serve two roles: as the intermediate representation for design-time YANG authoring, and as the runtime semantic authority against which AI-generated operation intents are validated. The runtime validation usage is specified in [NAIM-OP]; this document defines the format, derived views, and design-time workflows. | |||||||||||||
| draft-feng-nmop-naim-mcp-00.txt | ||||||||||||||
| Implementing the NAIM Framework over the Model Context Protocol | ||||||||||||||
|
NAIM (Natural AI Interface Modeling) is a semantic intermediate representation framework for AI-assisted network management. It consists of two specifications: a core specification [NAIM-CORE] that defines the NAIM Document format, YANG-aware node templates, type representation, and design-time Skills A-D; and an operations specification [NAIM-OP] that defines the Operation IR, runtime execution semantics, transaction and compensation model, and runtime Skills E-F. The Model Context Protocol (MCP) has emerged as the dominant standard for AI hosts to discover and invoke external capabilities. However, MCP delegates semantic understanding entirely to the AI model through natural language Tool descriptions, which is insufficient for the structured precondition checking, constraint validation, and compensation logic that reliable network management requires. This document specifies how the NAIM framework is implemented over MCP. It defines the Originator/Handler architectural split, the MCP Resources through which NAIM LLM Context Views are distributed, the minimal MCP Tool surface through which Operation IRs are submitted, and the complete interaction flow from natural language intent to validated network execution. This document is self-contained with respect to the MCP integration architecture; it references [NAIM-CORE] and [NAIM-OP] for the NAIM Document format, Operation IR structure, and execution engine semantics, which are not redefined here. | |||||||||||||
| draft-feng-nmrg-ain-architecture-01.txt | ||||||||||||||
| Agentic Intent Network (AIN): A Routing-Based Architecture for AI Agent Coordination at Scale | ||||||||||||||
|
The rapid proliferation of autonomous AI agents across enterprise and Internet-scale deployments creates a structural challenge that existing agent frameworks cannot address: how to enable any agent to discover and invoke any other agent's capabilities without pre- established bilateral integration, across organizational boundaries, at Internet scale. This document presents the Agentic Intent Network (AIN) as an architecture-level model for open, heterogeneous, dynamically evolving multi-agent coordination. It defines problem drivers, architectural and underlay requirements, architectural components, design invariants, scope boundaries, and a research agenda for the NMRG. | |||||||||||||
| draft-feng-nmrg-ain-deployment-00.txt | ||||||||||||||
| Agentic Intent Network (AIN): Applicability and Deployment Scenarios | ||||||||||||||
|
The Agentic Intent Network (AIN) architecture defines a routing-based coordination substrate for open, heterogeneous, Internet-scale multi- agent systems. This document describes applicability and deployment scenarios for AIN, targeting decision-makers in carrier networks, enterprises, and network equipment vendors. It maps the technical mechanisms defined in [AIN-ARCH] to concrete operational contexts, describes migration paths from existing infrastructure, and discusses the cold-start bootstrapping challenge inherent to network-effect- dependent systems. This document does not define new protocol mechanisms; it is intended to inform deployment planning and expand the AIN reader community beyond protocol engineers. | |||||||||||||
| draft-fengfar-led-01.txt | ||||||||||||||
| Dealing with LLMs in IETF Discussions | ||||||||||||||
|
The rapid adoption of AI language tools has prompted concern across professional and technical communities, including the IETF, about authenticity, accountability, and the integrity of human contribution. This document approaches the question from two directions: a critical reader's concerns about what AI use means for IETF discussion, and a practitioner's account of how AI is currently being used in IETF discussions. We aim to explore some of the issues arising, and perhaps make some specific (but tentative) recommendations, but the main recommendation is that the IETF should develop guidelines for use of AI tooling when engaging in IETF discussions. | |||||||||||||
| draft-ferguson-gpt-00.txt | ||||||||||||||
| GPT: Generic Protocol Type | ||||||||||||||
|
This document specifies GPT (Generic Protocol Type), a convention by which an HTTP address publishes the JSON Schema of the action it accepts, and accepts that action as a request body validated against the same schema. A client retrieves the schema at the moment of contact, produces a conforming value, and submits it unchanged. No client library, prior registration, or separate description of the capability is required. The schema serves as both the published description and the server-side check, so the two cannot diverge. | |||||||||||||
| draft-feria-sas-01.txt | ||||||||||||||
| Agentic Saturation Stridency (SAS): A Quantitative Model and Admission Architecture for Autonomous Agent Traffic | ||||||||||||||
|
Autonomous computational agents are capable of generating high- frequency synthetic traffic that can cause a protected system to allocate memory, consume processing cycles, or invoke application- layer computational routines before the eligibility of an incoming request has been established. This document formalizes Agentic Saturation Stridency (SAS) as a measurable system condition defined by the ratio between the arrival rate of unverified agentic traffic over a discrete observation interval and the empirically sustainable admission capacity of the target boundary. The document defines three operational regimes (Subcritical, Critical, and Supercritical) and specifies a pre-runtime structural admission architecture designated Reality Layer 0 (RL0). RL0 establishes an ex-ante admission boundary intended to drop or reject unverifiable traffic before protected application-layer execution, incorporating bounded-state replay protection, out-of-band key revocation checking via probabilistic structures, constant-time cryptographic operations, and standardized wire encodings. The admission framework utilizes a signed Reality-Token (RT) and an admission predicate associated with the Invariant Reality Prism (IRP), listed as an Informative Reference in the NIST Cybersecurity Framework Online Informative References catalog under Reference ID 189 (IRP-189). The catalog entry is cited for informational provenance only and does not imply NIST authorship, endorsement, certification, or normative incorporation of the IRP framework. | |||||||||||||
| draft-ferro-apertomemory-02.txt | ||||||||||||||
| The ApertoMemory Format: Portable,Client-Side-Encrypted AI Memory | ||||||||||||||
|
AI assistants and agents accumulate long-term memory about their users. This memory is typically stored in proprietary, provider-held silos: it cannot be moved between tools, its integrity cannot be verified, and its confidentiality depends entirely on the provider. This document specifies the ApertoMemory format: a canonical, signed, client-side-encrypted representation of AI memory objects, together with a portable single-file export container. Memory objects are encoded in deterministic CBOR, signed with COSE_Sign1, and encrypted with COSE_Encrypt0 under keys derived from and controlled by the user. A storage or synchronisation server handling ApertoMemory objects has zero access to their content, authorship, or semantic timestamps. This revision specifies format_version 2, which cryptographically binds every signature to the author it claims and to the cleartext envelope around it, and derives trust from which key verified an object rather than from a declared field. format_version 1, described by earlier revisions of this document, carries a known forgeable- provenance defect and MUST NOT be implemented for new deployments. | |||||||||||||
| draft-ferro-dnsop-apertoid-02.txt | ||||||||||||||
| ApertoID: DNS-Based Agent Identity Declaration Protocol | ||||||||||||||
|
This document defines ApertoID, a DNS-based protocol that enables domain owners to declare authorized AI agents acting on their behalf, publish cryptographic keys for agent identity verification, and specify enforcement policies for unauthorized agents. ApertoID uses existing DNS TXT records under the "_apertoid" underscore-scoped domain name to provide a decentralized, standards-based mechanism for AI agent identity declaration and verification. ApertoID defines two record types: a Policy Record analogous to DMARC that specifies domain-level enforcement behavior, and Agent Declaration Records analogous to DKIM key records that bind agent endpoints to Ed25519 public keys with mandatory expiration. A companion document [APERTOID-SIG] defines the HTTP request signing mechanism that enables agents to cryptographically prove their identity on each request. | |||||||||||||
| draft-ferro-httpbis-apertoid-sig-02.txt | ||||||||||||||
| ApertoID-Signature: HTTP Request Signing for AI Agent Identity | ||||||||||||||
|
This document defines the ApertoID-Signature HTTP header field, which enables AI agents to cryptographically prove their identity on each HTTP request. The agent signs the request method, target URL, body hash, and identity metadata using an Ed25519 private key whose corresponding public key is published in DNS via the ApertoID protocol [APERTOID-DNS]. The mechanism provides request-level identity verification, action binding (the signature is tied to the specific method and URL), and replay protection via timestamps and nonces. | |||||||||||||
| draft-ferro-schrock-memory-projection-record-01.txt | ||||||||||||||
| Signed Memory Projection Records for Verifiable AI Context Delivery | ||||||||||||||
|
Encrypted and signed memory objects can establish source integrity, authorship, and read-time trust without establishing which exact bytes a memory adapter selected and delivered to a downstream AI system. This document specifies a provider-neutral signed Memory Projection Record. The record commits to the recall request and selection policy, the read-time keyring snapshot, the ordered source objects and exact context fragments delivered, the complete projection bytes, and summarized exclusions. It deliberately does not claim that a model received, used, or weighted the projection, that an action was authorized, or that an outcome occurred. ApertoMemory is one source profile; other memory formats can use the same projection boundary. | |||||||||||||
| draft-fetch-validation-vmc-wchuang-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ffm-rats-cca-token-04.txt | ||||||||||||||
| Arm's Confidential Compute Architecture Reference Attestation Token | ||||||||||||||
|
The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. | |||||||||||||
| draft-filmroellchen-lunar-well-known-button-00.txt | ||||||||||||||
| The Well Known Button Information Specification | ||||||||||||||
|
This document specifies the well-known URI /.well-known/button.json, which describes a web site's "buttons". Buttons are usually 88x31 pixel images representing the web site with text, logos, artwork, and animations. /.well-known/button.json files facilitate sharing buttons between web site owners and alleviate issues commonly encountered when doing so. By utilizing a standardized, machine-readable format, automated tools can also utilize the provided information. | |||||||||||||
| draft-filsfils-ippm-path-tracing-06.txt | ||||||||||||||
| Path Tracing in SRv6 networks | ||||||||||||||
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. | |||||||||||||
| draft-filsfils-spring-path-tracing-srmpls-08.txt | ||||||||||||||
| Path Tracing in SR-MPLS networks | ||||||||||||||
|
Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each interface that forwards the packet. Path Tracing has the lowest MTU overhead compared to alternative proposals such as [INT], [RFC9197], [I-D.song-opsawg-ifit-framework], and [I-D.kumar-ippm-ifa]. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline. This document defines the Path Tracing specification for the SR-MPLS dataplane. The Path Tracing specification for the SRv6 dataplane is defined in [I-D.filsfils-spring-path-tracing]. | |||||||||||||
| draft-filsfils-srv6ops-srv6-ai-backend-04.txt | ||||||||||||||
| SRv6 for Deterministic Path Placement in AI Backends | ||||||||||||||
|
This document describes how SRv6 uSID (NEXT-CSID) enables deterministic path placement in AI backend fabrics through L3-L4 integration: the transport stack on the NIC encodes each path as an ordered list of segments (a uSID network program) in the packet header, while the fabric forwards statelessly. It explains operational benefits including deterministic probing and alignment with hyperscale production deployments. | |||||||||||||
| draft-filsfils-srv6ops-srv6-e2e-dc-frontend-wan-02.txt | ||||||||||||||
| SRv6 End-to-End DC Frontend and WAN | ||||||||||||||
|
The SRv6 Network Programming architecture allows an application to control the end-to-end journey of traffic flows through different network domains in a unified and stateless manner, without requiring intermediate network devices to maintain per-flow information. This document covers its application to the integration of data center (DC) and wide area network (WAN) architectures using SRv6 with uSID (NEXT-CSID). It describes a unified IPv6 data plane from tenant workloads through the DC frontend to Internet peering, replacing designs that stitch separate overlay protocols at the Data Center Interconnect (DCI). The solution enhances scalability and enables flexible stateless service insertion by unifying underlay, overlay, and service steering under SRv6. | |||||||||||||
| draft-fioccola-ippm-rfc7799bis-01.txt | ||||||||||||||
| Active,Passive,and Hybrid Metrics and Methods | ||||||||||||||
|
This memo provides clear definitions for Active, Passive and Hybrid performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods use a subset of both Active and Passive attributes, and they can be referred to as "Hybrid". This memo also describes multiple dimensions to help evaluate new methods as they emerge. This memo obsoletes RFC 7799. | |||||||||||||
| draft-flechier-sidrops-pava-02.txt | ||||||||||||||
| PAVA: BGP AS_PATH Validation by Querying ASes about Their Relationships | ||||||||||||||
|
This document defines PAth VAlidation (PAVA), a scheme for validating the Border Gateway Protocol (BGP) AS_PATH field based on the AS relationships. Validation involves sending queries to the ASes along the path and each query specifies information about the prefix and the relevant path segment. In this draft, for the decentralized distribution system that ASes on a path need for distributing the information, we propose to use the Domain Name System (DNS) and DNSSEC. | |||||||||||||
| draft-fletcher-oauth-txn-token-chaining-profile-00.txt | ||||||||||||||
| Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining | ||||||||||||||
|
This specification defines a profile of the OAuth Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining] mechanism that uses a Transaction Token (Txn-Token) [I-D.ietf-oauth-transaction-tokens] as the subject token in a Token Exchange [RFC8693] request to obtain a JWT Authorization Grant for crossing a trust boundary. A Txn-Token is scoped to a single trust domain and represents the full authorization context of an in-progress transaction, regardless of whether that transaction was initiated by a human user calling an external API, by an internal system event, or by an automated workload. This profile specifies how a service operating within that trust domain can present its Txn-Token to obtain a JWT Authorization Grant that carries the necessary context across a trust boundary, enabling an access token to be issued for a partner service, without exposing internal trust-domain credentials or token formats beyond the trust boundary. | |||||||||||||
| draft-flores-airp-provenance-00.txt | ||||||||||||||
| The AIRP Provenance Seal and Serving Register | ||||||||||||||
|
A response served by an inference provider carries no verifiable statement of what produced it. A recipient cannot determine which model generated a given output, nor whether the endpoint that served it was authorized by the party whose name is on it. Attribution today rests on the serving party's own account of events, offered after the fact and at its own discretion. This document specifies two mechanisms that together make that determination decidable by a recipient. The Provenance Seal is a detached signature by which a provider binds a model identifier, its own identity, and a timestamp to the exact bytes of a served response. The Serving Register is a signed document listing, for each provider, the endpoints authorized to serve its models, the public keys that validate its seals, and whether the provider declares that it seals every response. A DNS record under the provider's own domain binds that domain to its register entry and to its declared sealing policy, so that a suppressed seal is detectable rather than merely absent. The design follows electronic mail authentication: the seal is patterned on DKIM, the register on SPF, and the declared sealing policy on the published policy record of DMARC. | |||||||||||||
| draft-fluid-fadp-01.txt | ||||||||||||||
| Fluid Agentic DeFi Protocol (FADP/1.0): HTTP-Native Micropayment Authentication for Autonomous AI Agents | ||||||||||||||
|
This document defines the Fluid Agentic DeFi Protocol (FADP), version 1.0. FADP is an application-layer protocol layered atop HTTP that enables autonomous AI agents to pay for access to web resources using on-chain cryptocurrency transfers, with cryptographic proof of payment embedded directly in HTTP headers. FADP extends HTTP 402 (Payment Required) with two new header fields: X-FADP-Required, which a server uses to communicate payment terms to an agent, and X-FADP-Proof, which an agent uses to supply a verifiable on-chain payment receipt. A nonce-challenge mechanism prevents proof replay. An optional verification endpoint allows third-party on-chain confirmation without requiring the verifying party to run blockchain infrastructure. FADP is designed for agent-to-server and agent-to-agent payment flows operating at sub-dollar granularity (micropayments), where credit- card or OAuth-based billing is impractical. The reference implementation targets USDC on Base (an Ethereum Layer 2), though the protocol is token- and chain-agnostic. | |||||||||||||
| draft-fomicheva-aether-00.txt | ||||||||||||||
| Aether: A Next-Generation L4 Transport | ||||||||||||||
|
This document specifies Aether, a transport-layer protocol (L4) designed for modern network environments requiring multiplexed streams without head-of-line blocking, mandatory encryption with post-quantum resistance, multi-path routing, and self-sovereign identity at the protocol layer. Aether operates entirely in userspace without kernel modifications. | |||||||||||||
| draft-foroughi-agent-protocol-dimensions-00.txt | ||||||||||||||
| A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates | ||||||||||||||
|
Discussions about agent protocols are frequently muddied by overloaded terms; asks such as "we need a session protocol" or "we need cross-domain support" bundle several distinct concerns across transport, agent protocol, and orchestration layers. This document offers a dimensional model that routes each concern to its proper layer. The document defines a small set of protocol-visible dimensions for characterizing AI agent protocol interactions and applies them to representative agentic protocol proposals (A2A, MCP, and the ACP invocation surface of the AGNTCY stack) alongside their substrate bindings, making explicit which dimensions each proposal owns at the protocol layer and which it inherits from its substrate. The document does not rank proposals and does not prescribe an architecture. It is standalone: it neither depends on nor prescribes any use-case or requirements document. | |||||||||||||
| draft-fossati-rats-rare-00.txt | ||||||||||||||
| RATS ReST APIs | ||||||||||||||
|
This document describes a set of REST APIs that can be used by RATS roles to interact. These APIs facilitate the discovery of a role's capabilities, as well as the negotiation and exchange of RATS Conceptual Messages in several key scenarios, including Evidence gathering, Evidence appraisal, Endorsements and Reference Value management. This document aims to present a useful subset of possible RATS interaction patterns, rather than covering all of them. | |||||||||||||
| draft-fossati-seat-early-attestation-06.txt | ||||||||||||||
| Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | ||||||||||||||
|
The TLS handshake protocol allows authentication of one or both peers using static, long-term credentials. In some cases, it is also desirable to ensure that the peer runtime environment is in a secure state. Such an assurance can be achieved using remote attestation which is a process by which an entity produces Evidence about itself that another party can use to appraise whether that entity is found in a secure state. This document describes a TLS extension that enables the negotiation and binding of the TLS authentication key to a remote attestation session. This enables an entity capable of producing attestation Evidence, such as a confidential workload running in a Trusted Execution Environment (TEE), or an IoT device that is trying to authenticate itself to a network access point, to present a more comprehensive set of security metrics to its peer. This extension has been designed to allow the peers to use any attestation technology, in any remote attestation topology, and to use them mutually. | |||||||||||||
| draft-fossati-seat-expat-03.txt | ||||||||||||||
| Remote Attestation with Exported Authenticators | ||||||||||||||
|
This specification defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in [RFC9261]. Additionally, it introduces the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the RATS architecture while ensuring that attestation remains bound to the underlying communication channel. | |||||||||||||
| draft-fossati-tls-attestation-10.txt | ||||||||||||||
| Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | ||||||||||||||
|
This draft has been withdrawn. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/. Source for this draft and an issue tracker can be found at https://github.com/yaronf/draft-tls-attestation. | |||||||||||||
| draft-fraire-spacerg-constellation-registry-00.txt | ||||||||||||||
| A Registry of Announced,Filed and Deployed Satellite Constellations | ||||||||||||||
|
Aggregate figures for the number of satellites planned for low Earth orbit are widely quoted and rarely traceable. They mix quantities that are not comparable: satellites already in orbit, satellites a national regulator has authorised, satellites applied for and not yet granted, and satellites that exist only in an announcement. For a single system these can differ by orders of magnitude. Which one a headline figure refers to decides whether it describes infrastructure or intent. This document describes a community-maintained registry that keeps the four apart and requires every number in it to carry a citation and an evidence grade. It sets out the data model, the taxonomy of regulatory commitment, the rules that separate primary regulatory sources from secondary reporting, and the criteria for inclusion. | |||||||||||||
| draft-fregly-dnsop-slh-dsa-mtl-dnssec-06.txt | ||||||||||||||
| Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC | ||||||||||||||
|
This document describes how to apply the Stateless Hash-Based Digital Signature Algorithm in Merkle Tree Ladder mode to the DNS Security Extensions. This combination is referred to as the SLH-DSA-MTL Signature scheme. This document describes how to specify SLH-DSA-MTL keys and signatures in DNSSEC. It uses both the SHA2 and SHAKE family of hash functions. This document also provides guidance for use of EDNS(0) in signature retrieval. | |||||||||||||
| draft-frochet-quicwg-reverso-for-quic-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ftzhswj-cats-northbound-api-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-fu-memdns-pivoting-01.txt | ||||||||||||||
| DNS for Automated Pivoting in Big Memory Systems | ||||||||||||||
|
Heterogeneous memory networks (CXL pools, HBM/DDR/SRAM hierarchies, processing-in-memory arrays) form a big memory system, which exposes fragmented addressing to ML inference runtimes. This document describes Memory DNS (MemDNS), a semantic-addressing framework that applies DNS principles -- domain names, hierarchical delegation, caching, TTL, and authoritative records -- to tensor data placement in Big Memory Systems (BMS), deployed as limited domains (RFC 8799). The focus is "automated pivoting": the resolution and control machinery that automatically switches data access paths (replica selection), migrates data across media (placement pivoting), and recovers from faults (failover pivoting), driven by closed-form decision models (Appendix A; key logic pseudo-code in Appendix C) instead of ad-hoc thresholds. The document specifies record semantics, resolution flow, cache/TTL behavior, delegation, pivot decision models, and protocol considerations, together with a reference implementation summary. | |||||||||||||
| draft-fu-nmop-tokenops-probelem-statement-00.txt | ||||||||||||||
| Token Operation Problem Statement | ||||||||||||||
|
Distributed LLM inference relies heavily on high-performance networking to synchronize states across accelerators (e.g., GPUs) and nodes. Unlike traditional web services, inference workloads particularly those involving Mixture-of-Experts (MoE) models and long-context windows exhibit unique traffic patterns characterized by massive east-west traffic and strict latency constraints. Current network infrastructures and scheduling methods often treat compute resources and network paths independently, leading to suboptimal performance and degraded Quality of Experience (QoE). This document elaborates on these issues to guide potential protocol enhancements within the IETF. | |||||||||||||
| draft-fu-onsen-update-l3sm-service-models-02.txt | ||||||||||||||
| Extensions to the YANG Data Model for L3VPN Service Delivery | ||||||||||||||
|
RFC8299 defines a YANG data model for L3VPN service delivery. This document defines a set of extensions that address the limitations of the L3VPN Service Model (L3SM). The extensions enable (1)dynamic network provisioning with temporary connectivity, (2) dynamic bandwidth adjustment, (3) integration of isolation in Slice Service Templates to enhance QoS provisioning, (4) performance monitoring for enriching service quality visibility, (5)quantum-safe encryption integrating both PQC and QKD. | |||||||||||||
| draft-fu-sidrops-enhanced-slurm-filter-06.txt | ||||||||||||||
| Filtering Out RPKI Data by Type based on Enhanced SLURM Filters | ||||||||||||||
|
Simplified Local Internet Number Resource Management with the RPKI (SLURM) helps operators create a local view of the global RPKI by generating sets of filters and assertions. This document proposes to filter out RPKI data by type based on enhanced SLURM filters. Only the RPKI data types that the network or routers are interested in will appear in the Relying Party's output. | |||||||||||||
| draft-fu-sidrops-rpki-repositories-monitoring-01.txt | ||||||||||||||
| Operational Monitoring of RPKI Repositories' Health and Safety | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) relies on a globally distributed set of repositories to deliver signed routing authorization data to Relying Parties (RPs). Internet Service Providers (ISPs) depend on RPs to collect RPKI objects from distributed repositories and validate them cryptographically, resulting in hundreds of thousands of Validated Route origin authorization Payloads (VRPs). Nevertheless, even with multiple RPs deployed, ISPs have limited insight into the operational health and reliability of each Publication Point (PP). When a large number of RPKI objects change unexpectedly, operators often lack sufficient visibility into individual PPs to determine the source of the changes. Consequently, ISPs cannot easily determine whether these changes are caused by routine updates, malicious behavior, or underlying repository instability. This document provides operational guidance for monitoring the health and safety of RPKI repositories on a per-publication point basis. It defines measurable indicators related to reachability, availability, and content integrity, and explains how these metrics can be used to detect degraded performance or potentially unsafe repository behavior. The document discusses and provides recommendations for repositories alerting and operational response. The goal is to improve the transparency, operational availability and security of the RPKI ecosystem. | |||||||||||||
| draft-g00se-honk-00.txt | ||||||||||||||
| The HONK Protocol: Word-Counting over TCP with Honk-Based Responses and Optional Obfuscation | ||||||||||||||
|
This document defines the HONK protocol, a simple application-layer protocol operating over TCP. A HONK client submits a stream of UTF-8 encoded text terminated by a CRLF sequence, and the HONK server responds with a sequence of HONK tokens. The token count equals twice the number of whitespace-delimited words detected in the input. If no words are detected, the server responds with exactly three HONK tokens. The protocol includes an optional Privacy Mode in which message content is obfuscated using single-byte XOR with the fixed key value 0x48 (the ASCII code point for the letter H). This document requests that IANA assign TCP port 24565 to the HONK service. This document is an individual submission. It is NOT an April Fools Day publication. The author requests serious technical consideration from the IETF community. | |||||||||||||
| draft-gage-quic-pathmgmt-06.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gai-intarea-ip-tunnel-node-security-01.txt | ||||||||||||||
| Security Requirements for IP Tunnel Nodes | ||||||||||||||
|
IP tunnels conceal passenger-packet fields from devices on the delivery path and create a new forwarding and policy boundary at decapsulation. If a tunnel node accepts delivery packets from an unauthorized source, or if it forwards a decapsulated passenger packet without applying the policy for the exposed packet and forwarding domain, the node can enable source-address spoofing, unauthorized transit, policy bypass, or resource-exhaustion attacks. This document specifies generic security requirements for IP tunnel ingress, egress, and relay nodes. The requirements cover explicit enablement, peer and passenger-packet authorization, source and forwarding-scope validation, nested tunneling, IPv6 extension headers, ICMP and Path MTU Discovery, resource controls, and telemetry. They apply to configured IP-in-IP, IPv6 tunneling, GRE, and enabled IPv4/IPv6 transition mechanisms. This document does not define a new encapsulation or replace protocol-specific processing rules. | |||||||||||||
| draft-gaikwad-agent-friendly-http-api-profile-01.txt | ||||||||||||||
| Design Considerations and Profile for HTTP APIs Consumed by AI Agents | ||||||||||||||
|
AI agents are a fast-growing kind of HTTP API client. A human developer reads an API's documentation once and then writes code that calls it. An AI agent works from the machine-readable description each time it plans a step. It works within a limited amount of text it can hold at once. It retries often. It picks operations by matching their descriptions to a goal. An API built mainly for human developers can lead an agent into failures that are easy to avoid, such as repeating a write, running out of room for the task, or getting stuck on an error it cannot recover from. This document lists the properties that make an HTTP API easy for AI agents to use, including APIs reached through tool-calling layers such as the Model Context Protocol. It gathers these properties into a profile of existing HTTP and API-description mechanisms, with a checklist at the end. It covers the API and its description. It does not define new ways to identify, authenticate, or authorize an agent. That work is happening elsewhere and is referenced here for context. | |||||||||||||
| draft-gaikwad-agent-proxy-modes-00.txt | ||||||||||||||
| Proxy Modes for Agent-Tool Protocols | ||||||||||||||
|
Agent-tool protocols such as the Model Context Protocol (MCP) enable AI applications to discover and invoke external tools, resources, and prompts through a standardized JSON-RPC interface. As deployments scale, intermediaries (proxies, gateways, sidecars) are inserted between clients and servers to provide transport adaptation, capability aggregation, security enforcement, and operational governance. No specification currently defines the behavioral requirements for such intermediaries. This document establishes a taxonomy of proxy modes, a layered architecture for pluggable proxy functionality, and normative requirements for each mode. It is designed to be protocol- agnostic in its architecture while referencing MCP as the primary instantiation. | |||||||||||||
| draft-gaikwad-aps-profile-01.txt | ||||||||||||||
| Agent Persistent State Profile | ||||||||||||||
|
Autonomous agents increasingly maintain durable persistent state containing user preferences, embedding vectors, safety logs, intermediate reasoning steps, and audit traces. Today, agent frameworks treat storage as a generic file system, while storage administrators treat agents as stateless virtual machines. This "layer mismatch" leads to fragility, poor performance, and privacy risks. The Agent Persistent State (APS) Profile defines an experimental, vendor-neutral storage service class for durable agent state. APS emphasizes *compliance*: ensuring that memory associated with a specific user or agent identity can be retained, audited, and cryptographically erased. APS also addresses high-frequency small I/ O, vector index workloads, crash consistency, and Kubernetes/CSI [CSI] integration. APS introduces a Usage Class ("AgentPersistentState"), a versioned PersistentStateLineOfService schema, guidance for container orchestration systems, non-normative bindings for Swordfish [Swordfish] and Redfish [Redfish], and considerations for multi- tenancy. APS is intended as an Experimental RFC to gather implementation feedback prior to any standards-track work. | |||||||||||||
| draft-gaikwad-ba64-00.txt | ||||||||||||||
| ba64: A Binary-to-Text Encoding That Is Never Larger Than Base64 | ||||||||||||||
|
ba64 is a text encoding for binary data that is never larger than standard base64. An encoder races DEFLATE compression against plain base64 and emits whichever final text is shorter. Compressed output is marked by a leading "=" character, which is inside the base64 alphabet, so it survives every base64-safe channel, yet can never begin a valid base64 string, so the two forms are unambiguous. A CRC-32 over the decoded bytes guarantees that a ba64 decoder never silently returns wrong data. The plain form is byte-identical to base64, so ba64 decoders are a drop-in replacement wherever base64 is read today. An optional padding method decouples the emitted length from the compressibility of the input. | |||||||||||||
| draft-gaikwad-llm-benchmarking-methodology-01.txt | ||||||||||||||
| Benchmarking Methodology for Large Language Model Serving | ||||||||||||||
|
This document defines benchmarking methodologies for Large Language Model (LLM) inference serving systems. It provides test procedures, setup parameters, measurement specifications, and reporting formats for evaluating latency, throughput, scheduling, and resource management characteristics. This document is a companion to "Benchmarking Terminology for Large Language Model Serving" and SHOULD be consulted alongside that terminology document. | |||||||||||||
| draft-gaikwad-llm-benchmarking-profiles-01.txt | ||||||||||||||
| Performance Benchmarking Profiles for Large Language Model Serving Systems | ||||||||||||||
|
This document defines performance benchmarking profiles for Large Language Model (LLM) serving systems. Profiles bind the terminology defined in draft-gaikwad-llm-benchmarking-terminology and the procedures described in draft-gaikwad-llm-benchmarking-methodology to concrete architectural roles and workload patterns. Each profile clarifies the System Under Test (SUT) boundary, measurement points, and interpretation constraints required for reproducible and comparable benchmarking. This document specifies profiles only. It does not define new metrics, benchmark workloads, or acceptance thresholds. | |||||||||||||
| draft-gaikwad-llm-benchmarking-terminology-01.txt | ||||||||||||||
| Benchmarking Terminology for Large Language Model Serving | ||||||||||||||
|
This document defines terminology for benchmarking the performance of Large Language Model (LLM) inference serving systems. It establishes a shared vocabulary for latency, throughput, resource utilization, and quality metrics applicable to inference engines, application gateways, and compound agentic systems. This document defines terminology only and does not prescribe benchmark methodologies or acceptance thresholds. | |||||||||||||
| draft-gaikwad-llm-fault-detection-methodology-00.txt | ||||||||||||||
| Benchmarking Methodology for Output Behavior Fault Detection in Large Language Model Serving Systems | ||||||||||||||
|
This document defines test procedures for characterizing the fault detection capability of observability systems that monitor Large Language Model (LLM) serving deployments. Procedures are given for Detection Latency, Detection Coverage, Detection Threshold Magnitude, False Detection Rate, and Boundary Masking. The Detector Under Test is the observability system. Output Behavior Faults are injected at a known time under controlled conditions, which makes detection latency directly measurable. This document is a companion to "Benchmarking Terminology for Output Behavior Fault Detection in Large Language Model Serving Systems" and is to be read alongside it. This document specifies no acceptance thresholds. | |||||||||||||
| draft-gaikwad-llm-fault-detection-terminology-00.txt | ||||||||||||||
| Benchmarking Terminology for Output Behavior Fault Detection in Large Language Model Serving Systems | ||||||||||||||
|
This document defines terminology for benchmarking the fault detection capability of observability systems that monitor Large Language Model (LLM) serving deployments. It defines terms for injectable output behavior fault classes, for the detection events and latency intervals those faults produce, and for the coverage and accuracy characteristics of the detector under test. The System Under Test is the observability system, and not the language model. Faults are injected at a known time under controlled conditions, which makes detection latency measurable in a way it is not in production. This document defines terminology only. A companion document defines the corresponding methodology. This document specifies no test procedures, no acceptance thresholds, and no service-level objectives. | |||||||||||||
| draft-gaikwad-llm-incident-metrics-terminology-00.txt | ||||||||||||||
| Terminology for Reporting Output Behavior Incidents in Large Language Model Services | ||||||||||||||
|
This document defines terminology for reporting incidents in Large Language Model (LLM) services in which output behavior departs from intended behavior without producing an error response. It defines the lifecycle events of such an incident, the intervals between those events, and the qualifiers a reported interval carries. The intervals defined here are anchored at the point information about an occurrence reaches a responsible party. The interval preceding the first monitoring signal is named and is not defined as measurable. This document defines terminology only. It specifies no data model, no reporting obligations, and no target values. | |||||||||||||
| draft-gaikwad-south-authorization-01.txt | ||||||||||||||
| SOUTH: Stochastic Authorization for Agent and Service Requests | ||||||||||||||
|
SOUTH defines an authorization protocol for evaluating requests issued by users, services, or autonomous agents. SOUTH allows a server to return a deterministic decision or an allow decision that is issued with a probability determined by local policy. This enables servers to incorporate uncertainty, contextual information, and load conditions into authorization decisions. SOUTH is transport independent and can be composed with existing authentication mechanisms such as OAuth, OpenID Connect, mutual TLS, or DPoP. This document describes the request and response objects, decision semantics, and an HTTP binding for interoperable deployment. | |||||||||||||
| draft-gaikwad-woa-01.txt | ||||||||||||||
| The Web of Agents (WoA) | ||||||||||||||
|
This document defines the Web of Agents (WoA), a minimal JSON based description format and invocation convention that allows HTTP hosts to advertise AI agents and for clients to invoke those agents in a uniform way. A WoA document is typically served from a well known location on an HTTP origin and uses JSON Schema to describe agent inputs and outputs. WoA does not define a discovery protocol itself but is designed to be used as a host level primitive by higher level discovery systems. | |||||||||||||
| draft-gakiwate-dnsop-optimistic-dns-00.txt | ||||||||||||||
| Optimistic DNS | ||||||||||||||
|
DNS lookups introduce user-visible delay, particularly when cached records have expired and must be refreshed from the network. This document describes Optimistic DNS, a client-side stub resolver mechanism that immediately returns expired cached DNS records to applications while simultaneously refreshing them with a network query. The application receives an answer in microseconds rather than milliseconds, and if the data has changed receives an updated answer shortly thereafter. Optimistic DNS is complementary to RFC 8767, which addresses serving stale data at recursive resolvers. This document focuses exclusively on client-side stub resolver behavior, including explicit signaling from the application to inform the stub resolver that the application is able to handle old and possibly incorrect information. | |||||||||||||
| draft-gakiwate-dnsop-proxy-dns-svcb-00.txt | ||||||||||||||
| HTTP Header Fields for Proxying DNS SVCB Information | ||||||||||||||
|
When HTTP clients use the CONNECT method or UDP proxying (CONNECT- UDP) to reach target servers through a proxy, the proxy performs DNS resolution on behalf of the client. This prevents the client from accessing Service Binding (SVCB and HTTPS) DNS records that carry service configuration such as supported protocols and Encrypted Client Hello keys. This document defines HTTP header fields that enable the proxy to relay SVCB information to the client, and introduces a conditional early closure mechanism that allows the client to coordinate with the proxy to abort a connection when specific SVCB parameters are present, so that the client can retry with a different connection strategy. | |||||||||||||
| draft-gallagher-openpgp-certificates-00.txt | ||||||||||||||
| OpenPGP Certificate Grammar | ||||||||||||||
|
This document specifies several updates and clarifications to the grammar and semantics of OpenPGP certificates. | |||||||||||||
| draft-gallagher-openpgp-messages-00.txt | ||||||||||||||
| OpenPGP Message Grammar | ||||||||||||||
|
This document specifies several updates and clarifications to the grammar and semantics of OpenPGP messages. | |||||||||||||
| draft-gallagher-openpgp-signatures-03.txt | ||||||||||||||
| OpenPGP Signatures | ||||||||||||||
|
This document specifies several updates and clarifications to the grammar and semantics of OpenPGP signatures. | |||||||||||||
| draft-gandhi-ippm-stamp-ber-07.txt | ||||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Residual Bit Error Rate Measurement | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, along with its optional extensions specified in RFC 8972, can be utilized for active measurement. Networks may experience transmission bit errors due to various factors, including poor fiber quality. Even with efficient CRC and FEC mechanisms, some bit errors may escape detection and correction, referred to as residual bit errors. This document further augments the STAMP extensions specified in RFC 8972 to enable the measurement of the residual bit error rate within the "Extra Padding" TLV of STAMP test packets. | |||||||||||||
| draft-gandhi-ippm-stamp-mpls-hdr-08.txt | ||||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Network Action Headers | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-by- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect MPLS Network Action Sub-Stacks and Post-Stack MPLS Headers, for HBH and E2E active measurements, for example, using the IOAM data fields. | |||||||||||||
| draft-gandhi-lsr-ber-02.txt | ||||||||||||||
| IS-IS,OSPF,and BGP-LS Extensions for Advertising Bit Error Rate Metric for Traffic Engineering | ||||||||||||||
|
Networks may experience transmission bit errors due to various factors, such as poor fiber quality. This document describes extensions to IS-IS, OSPF, and BGP-LS to advertise the Bit Error Rate (BER) and Packet Error Rate (PER) metrics for the links that can be used for Traffic Engineering. Note that mechanisms for measuring bit errors or acting on that information, once advertised, are outside the scope of this document. | |||||||||||||
| draft-gandhi-lsr-flex-algo-link-ber-00.txt | ||||||||||||||
| IGP Flexible Algorithm Utilizing Link Bit Error Rate Metric | ||||||||||||||
|
Networks may experience transmission bit errors due to various factors, such as poor fiber quality. This document defines extensions to the IGP Flexible Algorithm to utilize the link Bit Error Rate (BER) metric as a link constraint. It defines a mechanism to exclude links whose BER metric exceeds a configured threshold during Flex-Algorithm path computation. The mechanism utilizes BER metric advertisement defined for IS-IS and OSPF in draft-gandhi-lsr- ber. | |||||||||||||
| draft-gandhi-lsr-stamp-00.txt | ||||||||||||||
| IS-IS,OSPF,BGP-LS,and BGP Extensions for Signaling STAMP Parameters | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP), as defined in RFC 8762, can be utilized for active measurement without relying on a control channel to pre-signal session parameters. This document describes the extensions to IS-IS, OSPF, BGP-LS, and BGP protocols for signaling STAMP reflector parameters in a network. The STAMP reflector parameters can be used by the STAMP senders to set up appropriate performance measurement sessions for delay and packet loss metrics. | |||||||||||||
| draft-gandhi-pce-ber-02.txt | ||||||||||||||
| Extensions to the Path Computation Element Communication Protocol (PCEP) for Utilizing Link Bit Error Rate (BER) Metric | ||||||||||||||
|
Networks may experience transmission bit errors due to various factors, such as poor fiber quality. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extensions to PCEP to include link Bit Error Rate (BER) metric as a constraint for end-to-end path computation. The PCEP extension utilize link BER metric advertisements defined for IS-IS and OSPF in draft-gandhi-lsr-ber. | |||||||||||||
| draft-gandhi-pce-pm-14.txt | ||||||||||||||
| PCEP Extensions for Performance Measurement for SR-TE and MPLS-TE LSPs with Stateful PCE | ||||||||||||||
|
In certain networks, network performance data such as packet loss, delay, and delay variation, as well as bandwidth utilization, are critical measures for Traffic Engineering (TE). These data provide operators with the characteristics of their networks for the performance evaluation required to provide Service-Level Agreements (SLAs). Stateful Path Computation Element Communication Protocol (PCEP) extensions have been defined for TE LSPs for Segment Routing (SR) and RSVP. This document describes the PCEP extensions for enabling and notifying end-to-end performance measurement including liveness detection for both PCE-Initiated and PCC-Initiated LSPs for SR-TE over MPLS and IPv6 data planes, and MPLS-TE using RSVP to an Active Stateful PCE. | |||||||||||||
| draft-gao-grow-bmp-config-monitor-tlv-01.txt | ||||||||||||||
| BMP Extension for Configuration Monitoring TLV | ||||||||||||||
|
This document defines two types of BMP extended TLV, which are used to carry configuration information and configuration effective time related to BGP route changes. Through this extension, the BGP monitoring platform can associate various BGP events with configuration operations, providing traceable evidence for identifying network failures caused by configuration changes. | |||||||||||||
| draft-gao-opsawg-flowspec-ipfix-00.txt | ||||||||||||||
| Export of BGP FlowSpec Treatment Information in IPFIX | ||||||||||||||
|
BGP Flow Specification (FlowSpec) is commonly used to distribute traffic filtering and traffic treatment rules. Operational monitoring of FlowSpec deployments may require information from multiple sources, including BGP control-plane telemetry, operational state, and forwarding-plane observations. This document defines IP Flow Information Export (IPFIX) Information Elements that add FlowSpec context to IPFIX Flow Records. The exported information enables a Collector to correlate exported Flow Records with a FlowSpec rule in the scope of an Observation Domain and to identify the treatment class reported by the Exporter. | |||||||||||||
| draft-gao-opsawg-ipfix-term-and-app-02.txt | ||||||||||||||
| Export of TLS Handshake Information in IPFIX | ||||||||||||||
|
This document defines a set of new Information Elements (IEs) in the IPFIX Information Model for exporting raw TLS ClientHello handshake fields. These IEs enable the collection of standardized client behavioral fingerprints from network traffic without decryption of the encrypted payload. The exported fields facilitate network anomaly detection, threat identification, and fault diagnosis in encrypted traffic environments. | |||||||||||||
| draft-garg-auto-delete-unused-te-tunnels-00.txt | ||||||||||||||
| Auto-Deletion of Unused TE Tunnels Using a Timer-Based Mechanism | ||||||||||||||
|
This document describes a timer-based mechanism for handling unused Traffic Engineering (TE) tunnels. When a tunnel remains inactive for a configured period, it is moved to a parked state, administratively shut down, and the associated resources are released. If the tunnel remains parked beyond a longer retention interval, it may be deleted automatically or removed through operator action, depending on local policy. This approach improves resource utilization and provides a structured lifecycle for unused TE tunnels. | |||||||||||||
| draft-garg-l2vpn-over-srv6-02.txt | ||||||||||||||
| Method to enable signaling of L2VPN services using SRv6 extensions | ||||||||||||||
|
This document describes a mechanism to provide L2VPN services using Segment Routing over IPv6 (SRv6), eliminating the need for a separate signaling protocol for VPN label distribution. In current deployments, L2VPN services rely on dedicated protocols such as the Label Distribution Protocol (LDP) or Border Gateway Protocol (BGP) for service label signaling, which adds control-plane complexity. The proposed mechanism introduces an SRv6-based extension that enables L2VPN service identification within the SRv6 framework, reducing control-plane overhead and providing a simplified and efficient solution for L2VPN service delivery. | |||||||||||||
| draft-gavcave-ipv6-emoji-notation-00.txt | ||||||||||||||
| Emoji-Based Notation for IPv6 Addresses | ||||||||||||||
|
This document defines an alternative textual representation of IPv6 addresses using Unicode Emoji characters (hereinafter "Smileys") in place of hexadecimal digits. The proposed format, known as EmojiNotation6 (EN6), aims to make IPv6 addresses more expressive, more human-friendly, and significantly more fun at parties. Additionally, this document specifies a MANDATORY content- classification prefix using the AUBERGINE character (U+1F346) for addresses serving adult content, hereafter referred to as the "Eggplant Requirement". | |||||||||||||
| draft-gazitt-oauth-authzen-claims-01.txt | ||||||||||||||
| AuthZEN Profile for Authorization Claims in JWT Access Tokens | ||||||||||||||
|
RFC 9068 recommends that an authorization server placing group memberships, roles, or entitlements in a JWT access token draw those claims from the SCIM user schema. It says what the claims are named and how their values are encoded, and it does not say where an authorization server obtains them. In deployments today they come from a directory, a database, or a vendor-specific hook, and the question they answer is an authorization question asked of something that is not the authorization system. This document profiles the Resource Search API of the OpenID AuthZEN Authorization API for that purpose. It binds each authorization claim to a search, defines how a search result set becomes a claim value, and requires that a search result never influence whether a token is issued or what authority it conveys. It may be applied on its own, by an authorization server that externalizes claim enrichment but not its issuance decision, or alongside the companion framework document that externalizes the decision. | |||||||||||||
| draft-gazitt-oauth-authzen-issuance-01.txt | ||||||||||||||
| AuthZEN Profile for OAuth 2.0 Token Issuance | ||||||||||||||
|
Numerous OAuth 2.0 specifications define a moment at which an authorization server decides whether to issue a security token, and each of them declares the decision itself to be a matter of local policy that is out of scope. The result is that a decision common to every OAuth deployment has no interoperable expression. This document defines a profile for using the OpenID AuthZEN Authorization API to externalize that decision to a Policy Decision Point. It specifies how the inputs to a token issuance request map onto AuthZEN's mandatory five-tuple, how a Policy Decision Point response may shape the issued token, and how a Policy Decision Point advertises support for the profile. The mapping is complete for grants whose request names a single party, including the authorization code and client credentials grants. Companion documents bind the grant families that add structure this document does not model, the token exchange family first among them. | |||||||||||||
| draft-gazitt-oauth-authzen-token-exchange-01.txt | ||||||||||||||
| AuthZEN Binding for OAuth 2.0 Token Exchange | ||||||||||||||
|
OAuth 2.0 Token Exchange (RFC 8693) defines the moment at which an authorization server decides whether one party may obtain a token to act as, or on behalf of, another. It states that the decision is governed by policy, and does not define that policy. The specifications layered on top of it - identity chaining, identity assertion authorization grants, and transaction tokens - inherit the same seam. This document binds those flows to the AuthZEN profile for OAuth 2.0 token issuance. It specifies how a token exchange request is derived into AuthZEN evaluation requests, how the authority of the requesting party is expressed as a decision distinct from the authority being delegated, and what each of the token types layered on token exchange contributes to that mapping. | |||||||||||||
| draft-gco-oauth-delegate-sd-jwt-00.txt | ||||||||||||||
| Delegate SD-JWT | ||||||||||||||
|
This document specifies an extension to Selective Disclosure JSON Web Tokens to support further delegation from the Holder to a Delegate Holder. This is done by allowing the Key Binding JWT to also be an SD-JWT, optionally with its own Key Binding. This has particular applicability to Agentic systems. | |||||||||||||
| draft-gebauer-iacp-03.txt | ||||||||||||||
| Internet Agent Communication Protocol | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| draft-gebauer-iacp-a2acom-00.txt | ||||||||||||||
| Internet Agent Communication Protocol - A2ACOM | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| draft-gebauer-iacp-dhi-erp-00.txt | ||||||||||||||
| Internet Agent Communication Protocol - DHI - ERP | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| draft-gebauer-iacp-dht-00.txt | ||||||||||||||
| Internet Agent Communication Protocol - DHT | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| draft-gebauer-iacp-economy-00.txt | ||||||||||||||
| Internet Agent Communication Protocol - ECONOMY | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| draft-gebauer-iacp-eid-00.txt | ||||||||||||||
| Internet Agent Communication Protocol - EID | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| draft-gebauer-iacp-interop-00.txt | ||||||||||||||
| Internet Agent Communication Protocol - INTEROP | ||||||||||||||
|
Ever since 1969 and the ARPANET, the internet has repeatedly been faced with challenges that it has had to overcome—and has overcome. Year after year, the number of users has grown, and year after year, the complexity and range of ways in which the internet can be used have expanded. With the advent of AI, we not only have a new type of user, we have a different form of communication; the internet itself is being attributed a completely different significance. If they are not already, AIs will make up the majority of internet users in the foreseeable future. The question of an ‘AgentNet,’ is not merely a question concerning the internet; it is a question of how AIs will interact within a global network in the future. | |||||||||||||
| draft-geng-acme-idp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-geng-acme-sm2dualcert-extension-00.txt | ||||||||||||||
| ACME Extension for SM2 Dual-Certificate System | ||||||||||||||
|
This document describes the extension of the ACME protocol [RFC8555] to support automated issuance of SM2 dual certificates (signature certificates and encryption certificates) in the Chinese National Cryptography certificate system. This document does not represent IETF consensus; the technical solution is applicable only to PKI environments based on an SM2 dual-certificate system. Under the framework of the ACME protocol [RFC8555], this document proposes using two separate Orders to request the two certificates. For the signature certificate, the existing ACME workflow is reused, optionally using the standard CSR approach or the pk-01 challenge [I-D.geng-acme-public-key]. For the encryption certificate, this document defines a new challenge type, auth-01, specifically for *identity authorization* scenarios: the client proves possession of the *signature private key* to authorize the Key Management Center (KMC) to generate an encryption key pair and issue the encryption certificate on behalf of the entity. This challenge type intrinsically binds the issuance of the encryption certificate to the signature key, requiring no additional binding identifiers. All extensions are compatible with the existing ACME resource model. No new Order types are introduced. This document only adds optional fields in the client's newOrder request (authKey, includeEnvelope) and an additional field in the server's response (envelope), without changing the core semantics or state machine of Order. | |||||||||||||
| draft-geng-acme-sm2dualcert-rotation-00.txt | ||||||||||||||
| ACME STAR Extension for SM2 Dual-Certificate Automated Key Rotation | ||||||||||||||
|
The SM2 dual-certificate system, specified in [GMT.0034-2014], employs a dual-certificate architecture in which each entity holds both a signature certificate and an encryption certificate. The encryption private key is generated and escrowed by the Key Management Center (KMC). This document defines an *ACME Profile* that adapts the core protocol of [RFC8555] to the specific deployment scenario of SM2 dual- certificate management in the ShangMi (SM) ecosystem. Building upon the dual-certificate foundation framework defined in [I-D.geng-acme- sm2dualcert-extension], this document defines a STAR extension for the ACME protocol that enables *synchronized short-term automatic renewal* of SM2 dual certificates. The signature certificate follows [RFC8739] (ACME STAR) for automatic renewal with the same key pair; the encryption certificate achieves automated key rotation with a fresh key pair per epoch based on *Asynchronous Remote Key Generation (ARKG)* [Frymann2020]. This extension establishes a *unified ARKG seed chain key derivation system*: the KMC holds a seed seed_kmc and derives all encryption certificate key pairs (pk_i, sk_i) for all epochs via the ARKG algorithm, enabling stateless, lightweight KMC operations. On this basis, this extension provides *two private key delivery modes*: * *Mode A (ARKG Envelope Delivery)*: delivers sk_i to the client via a digital envelope, fully inheriting the envelope mechanism of the base framework. * *Mode B (ARKG Offline DH Derivation)*: the initial private key is obtained via envelope delivery; subsequent private keys are derived offline by the client, providing key insulation security properties. Both modes share the same ARKG cryptographic infrastructure, differing only in the final delivery mechanism of the private key. Deployers may choose according to their requirements, with full compatibility and coexistence achieved through ACME directory object negotiation. *Document Positioning*: This document is intended for the *specific SM ecosystem* as a practical guide and interoperability reference, and does not seek to become a general Internet standard. | |||||||||||||
| draft-geng-grow-bmp-rel-enhancement-03.txt | ||||||||||||||
| Log More Routing Events in the BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The Route Event Logging (REL) message is defined in [I-D.ietf-grow-bmp-rel], which enables monitored routers to report event-driven operational data to BMP collectors. This document defines additional event code points for BGP FlowSpec RFC8955 [RFC8956] and BGP SR Policies [I-D.ietf-idr-sr-policy-safi]. These extensions enhance monitoring visibility for policy execution failures and improve network operation and troubleshooting capabilities. | |||||||||||||
| draft-geng-idr-bgp-savnet-06.txt | ||||||||||||||
| BGP Extensions for Source Address Validation Networks (BGP SAVNET) | ||||||||||||||
|
Many source address validation (SAV) mechanisms have been proposed for preventing source address spoofing. However, existing SAV mechanisms are faced with the problems of inaccurate validation or high operational overhead in some scenarios. This document proposes BGP SAVNET by extending BGP protocol for SAV. This protocol can propagate SAV-related information through BGP messages. The propagated information will help edge/border routers automatically generate accurate SAV rules. These rules construct a validation boundary for the network and help check the validity of source addresses of arrival data packets. | |||||||||||||
| draft-geng-idr-flowspec-sav-07.txt | ||||||||||||||
| BGP Flow Specification for Source Address Validation | ||||||||||||||
|
BGP FlowSpec reuses BGP route to distribute infrastructure and propagates traffic flow information with filtering actions. This document proposes some extensions to BGP FlowSpec for disseminating SAV rules. | |||||||||||||
| draft-geng-savnet-inter-domain-spa-03.txt | ||||||||||||||
| Source Prefix Advertisement for Inter-domain SAVNET | ||||||||||||||
|
This document proposes a mechanism that enables a Source AS to actively advertise their locally observed Customer Cone and prefix information to the adjacent Validating AS via a new inter-domain message called Source Prefix Advertisement (SPA). The Validating AS then combines this SPA-carried information with local source address validation-related information to construct more accurate prefix allowlists for interfaces connected to Source ASes. | |||||||||||||
| draft-geng-sidrops-aspa-analysis-05.txt | ||||||||||||||
| An Analysis of ASPA-based AS_PATH Verification | ||||||||||||||
|
Autonomous System Provider Authorization (ASPA) is very helpful in detecting and mitigating route leaks (valley-free violations) and a majority of forged-origin hijacks. This document does an analysis on ASPA-based AS_PATH verification to help people understand its strengths and deficiencies, and some potential directions of enhancing ASPA are provided. | |||||||||||||
| draft-geng-sidrops-asra-profile-04.txt | ||||||||||||||
| A Profile for Autonomous System Relationship Authorization (ASRA) | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Relationship Authorization (ASRA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASRA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier) can authorize one or more other Autonomous Systems (ASes) as its customers and lateral peers. When validated, an ASRA's eContent can be used for detection and mitigation of BGP AS path manipulation attacks together with Autonomous System Provider Authorization (ASPA). ASRA is complementary to ASPA. | |||||||||||||
| draft-geng-sidrops-rtr-selective-sync-07.txt | ||||||||||||||
| Selective Synchronization Extension for RPKI-to-Router Protocol | ||||||||||||||
|
The RPKI-to-Router (RTR) protocol synchronizes all the verified RPKI data to routers. This document proposes to extend the existing RTR protocol to support selective data synchronization. Selective synchronization can avoid unnecessary transmissions. The router can receive only the data that it really needs. | |||||||||||||
| draft-gerke-publication-process-reform-05.txt | ||||||||||||||
| Publication Process Reform to prevent misuse of AUTH48 or equivalent states | ||||||||||||||
|
This document updates the AUTH48 or equivalent process by introducing deterministic state-integrity constraints within the IETF Datatracker architecture. It establishes automated validation milestones and explicit access controls to prevent late technical modifications after the Working Group Last Call, thereby safeguarding the Rough Consensus. This document updates RFC 7841. | |||||||||||||
| draft-giannelli-srpc-00.txt | ||||||||||||||
| sRPC: Solenoid Action-Oriented RPC and the HTTP RUN Method | ||||||||||||||
|
This document defines the Solenoid Remote Procedure Call (sRPC) protocol and requests registration of a new HTTP method, RUN. sRPC is action-oriented. A client targets a stable endpoint URI and identifies the procedure to execute through a query parameter containing a procedure path. The RUN method provides explicit protocol semantics for function invocation, distinguishing RPC execution from resource-oriented REST interactions. | |||||||||||||
| draft-ginsberg-lsr-hello-capability-00.txt | ||||||||||||||
| IS-IS Hello Capability | ||||||||||||||
|
Advertisement of capabilities in Hellos is useful to allow support of optional features in establishing and maintaining adjacencies. This document defines a new TLV to be sent in hellos to advertise such capabilities. | |||||||||||||
| draft-gl-lsr-metric-normalize-01.txt | ||||||||||||||
| Metric Normalize for IGP Flex-algo | ||||||||||||||
|
When multiple links in a network have the same metric, they can serve as ECMP equivalent links for load balancing during forwarding. However, slight fluctuations in metric values can prevent the formation of ECMP equivalent links, leading to the idle state of suboptimal links and thus wasting bandwidth resources. This document proposes a metric normalization method by advertising metric normalization parameters corresponding to a specific Metric- Type for Flexible Algorithm. During route calculation, slight fluctuations across multiple links are adjusted according to these normalization parameters, making the computed metric values more consistent. This approach enables the formation of ECMP equivalent links and promotes load sharing in the forwarding process. | |||||||||||||
| draft-gomez-iotops-quic-iot-00.txt | ||||||||||||||
| QUIC Usage Guidance in the Internet of Things (IoT) | ||||||||||||||
|
This document provides guidance on how to use QUIC in Constrained- Node Networks (CNNs), which are a characteristic of the Internet of Things (IoT). | |||||||||||||
| draft-gomez-rift-multicast-operational-00.txt | ||||||||||||||
| Operational Considerations for Multicast over RIFT-based Data Center Fabrics | ||||||||||||||
|
RIFT (Routing in Fat Trees) is increasingly used as an underlay routing protocol in modern data center fabrics. However, RIFT does not natively define mechanisms for multicast traffic distribution. This document provides operational guidance and best practices for deploying multicast in RIFT-based data center fabrics. It analyzes PIM, EVPN multicast, BIER, and head-end replication, highlighting trade-offs in scalability, efficiency, and operational complexity. This document does not define new protocol mechanisms. It aims to assist network operators in making informed design decisions when deploying multicast services over RIFT-based fabrics. | |||||||||||||
| draft-gomez-tiptop-coap-01.txt | ||||||||||||||
| CoAP in Space | ||||||||||||||
|
This document provides guidance on using the Constrained Application Protocol (CoAP) in deep space environments. The document focuses on the approach whereby an IP protocol stack is used for end-to-end communication. | |||||||||||||
| draft-goncharov-rfcregsimples-00.txt | ||||||||||||||
| A CBOR Simple Values Range for Packing and Templating | ||||||||||||||
|
The Concise Binary Object Representation (CBOR, RFC 8949, STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document registers a range of sixteen CBOR simple values (0 to 15) that can be shared by different specifications using them for CBOR transformations, such as compression or templating, in a non- conflicting way. This allows current and future specifications to reuse the smallest (single-byte) simple values range while defining their own ways to use them for achieving their goals. This document updates RFC 8949. | |||||||||||||
| draft-gondwana-dkim2-authres-00.txt | ||||||||||||||
| Reporting DKIM2 Verification Results in Authentication-Results | ||||||||||||||
|
DomainKeys Identified Mail Signatures v2 (DKIM2) produces a verification result for an email message. This document defines how that result is reported in the Authentication-Results header field, registering the "dkim2" authentication method, the result values it can take, and two properties which identify the signing domain and the point in the chain at which verification failed. Diagnostic detail about each hop is carried in a human-readable comment. | |||||||||||||
| draft-gondwana-email-header-maintenance-02.txt | ||||||||||||||
| Maintenance of the IANA Message Header Field Registries | ||||||||||||||
|
The IANA "Message Headers" registries record, for each registered header field, the protocol it belongs to, its status, whether it is a trace field, and the document(s) that specify it. These registries were populated incrementally by many documents over more than two decades, and the metadata that reached the registries is in several respects less complete than the metadata the registering documents supplied. Most notably, the document that performed the single largest bulk registration, RFC 4021, gave IANA an explicit status and an explicit specification document for every one of the roughly ninety fields it registered, and neither was recorded: those entries carry a blank status and cite RFC 4021 itself rather than the specification. Separately, the "Trace" column added to both registries by the ongoing revision of RFC 5322 was deliberately left empty for pre-existing entries, to be filled in later. This document reviews the initial definition of, and every subsequent update to, each registered header field, and gives IANA a single, coherent set of instructions for completing and correcting each registry entry. Every recommended change, and every deliberate decision to leave a non-obvious entry unchanged, is justified by reference to the instructions already given by, or the clear intent of the authors of, the source documents in which the field was defined or modified. | |||||||||||||
| draft-gondwana-welcome-to-the-ietf-00.txt | ||||||||||||||
| Welcome to the IETF | ||||||||||||||
|
The IETF has produced many documents to describe what it is and how it works -- this is one of them. In an age in which agentic tooling makes it trivially easy to produce large amounts of text, this document explains to both humans and agents what the IETF is about, how to succeed at the IETF, and some common pitfalls which might reduce the quality of your time here. This document does not describe the specific arcane process of how documents progress through adoption, improvement, consensus, editing, and eventual publication. Instead, we focus on the people and the culture of the IETF and how to succeed at IETFing. | |||||||||||||
| draft-gong-idr-inter-domain-srv6-flex-algo-01.txt | ||||||||||||||
| BGP Extensions for Inter-Domain Flexible Algorithm with Segment Routing over IPv6 (SRv6) | ||||||||||||||
|
IGP Flexible Algorithm (Flex-Algo) provides a mechanism for IGP nodes to compute the best paths according to a set of constraints in both the topology and computation metrics. Segment Routing over IPv6 (SRv6) can be used as one of the data plane of IGP Flex-Algo. In SRv6 networks, services may be carried across multiple network domains which are under the same administration. For some services, it is expected that the an end-to-end inter-domain path can be computed according to the same constraints (such as low latency) defined by Flex-Algo. This document describes BGP extensions to advertise SRv6 locators as IPv6 prefixes, together with the associated algorithm across the AS boundary. | |||||||||||||
| draft-gong-mpls-nrp-oam-mpls-03.txt | ||||||||||||||
| Operations,Administration and Maintenance (OAM) for Network Resource Partition (NRP) in MPLS Network | ||||||||||||||
|
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 MPLS networks. By extending existing OAM mechanisms such as ping, traceroute, the proposed solution enables comprehensive NRP support in MPLS networks. | |||||||||||||
| draft-gong-spring-nd-advertise-srv6-locator-05.txt | ||||||||||||||
| Advertise SRv6 Locator Information by IPv6 Neighbor Discovery | ||||||||||||||
|
In an SRv6 network, each SRv6 segment endpoint has at least one SRv6 Locator. Through the SRv6 locator routes, other SRv6 segment nodes can steer traffic to that node. This document describes a method for an SRv6 endpoint (e.g., a host or a customer provider edge (CPE)) to advertise its SRv6 locator to a neighboring SRv6-aware router using extensions to the IPv6 Neighbor Discovery (ND) protocol. This approach eliminates the need to run a full routing protocol stack on simple endpoints, facilitating SRv6 deployment in controlled, trusted domains such as data centers and managed access networks. | |||||||||||||
| draft-gong-spring-sr-policy-group-yang-04.txt | ||||||||||||||
| YANG Data Model for SR Policy Group | ||||||||||||||
|
This document defines YANG data models for Segment Routing (SR) Policy group that can be used for configuring, instantiating, and managing SR Policy groups. The model is generic and apply equally to the MPLS and SRv6 instantiations of SR policy groups. | |||||||||||||
| draft-gong-teas-spring-nrp-oam-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-google-cfrg-libzk-02.txt | ||||||||||||||
| Longfellow ZK | ||||||||||||||
|
This document defines an algorithm for generating and verifying a succinct non-interactive zero-knowledge argument that for a given input x and a circuit C, there exists a witness w, such that C(x,w) evaluates to 0. The technique here combines the MPC-in-the-head approach for constructing ZK arguments described in Ligero [ligero] with a verifiable computation protocol based on sumcheck for proving that C(x,w)=0. | |||||||||||||
| draft-goswami-agentic-jwt-01.txt | ||||||||||||||
| Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management | ||||||||||||||
|
This document specifies Agentic JSON Web Token (Agentic JWT), as an extension to OAuth 2.0 that addresses authorization challenges unique to autonomous agentic AI systems. This protocol solves the problem of Zero-Trust drift due to non-deterministic Agentic AI clients causing separation between user's (resource owner's) intent and client application's actions. Traditional OAuth 2.0 assumes that client applications faithfully represent user intent when requesting authorization. This assumption breaks down when autonomous AI agents dynamically generate workflows, create sub-agents, and make authorization decisions without continuous human oversight. We term this the "intent-execution separation problem." Agentic JWT introduces three mechanisms to address this problem: (1) cryptographic agent identity through agent checksums (based on agent's system prompts, tools and configurations), (2) workflow-aware token binding that links user intent to agent execution, and (3) a new OAuth 2.0 grant type (agent_checksum) for secure token issuance, (4) a flavor of PoP (Proof-of-Possession) at the level of an agentic identity to prevent token replays by other agents in the same multi- agent process. This specification enables Zero-Trust security principles in multi- agent systems while maintaining backward compatibility with existing OAuth 2.0 infrastructure. The security analysis and experimental validation are described in the companion research paper. | |||||||||||||
| draft-gould-regext-auth-token-00.txt | ||||||||||||||
| Extensible Provisioning Protocol (EPP) Authentication Token Mapping | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of EPP Authentication Token objects in a shared central repository, where an Authentication Token is a JSON Web Signature (JWS), defined in RFC 7515, and is used to authorize actions by registrar users. The Authentication Token can be passed over an authenticated EPP session, as defined in RFC 5730, to provide elevated, fine-grained authorization exclusively valid until the lifetime of the digitally signed Authentication Token. | |||||||||||||
| draft-gould-regext-epp-server-validation-00.txt | ||||||||||||||
| Server Validation Extension for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) extension for providing the status of server validations. Server validations can be done for an extensible set of types, with examples including validating the DNS resolution with the type "dns" and validating the DNSSEC with the type "dnssec". The validations can be performed synchronously that will include the extension in the response or asynchronously that will include the validation in a poll message. If validations are performed on a schedule, a change in the status of a typed-validation will be included in a poll message. | |||||||||||||
| draft-gould-regext-epp-status-set-04.txt | ||||||||||||||
| Status Set Extension Mapping for the Extensible Provisioning Protocol | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) extension for the provisioning and management of status sets applied to EPP objects, such as the domain name object in RFC 5731. The EPP status values defined in the EPP object mappings, such as Section 2.3 of RFC 5731, support human-readable text that describes the rationale or reason for the status applied to the object. There can be many overlapping reasons for a status value being applied to the object, such as implementing a lock service, complying with a court order, or addressing domain abuse. A status set defines an object representing the reason for setting a list of status values, so clients and servers can manage the status sets in place of individual status values to effectively manage the overlapping reasons. The EPP extension supports the provisioning of client status sets, disclosure of the server status sets, and an enhanced authorization model for client status sets with the EPP Authentication Token in [I-D.gould-regext-auth-token]. | |||||||||||||
| draft-gould-regext-rdap-server-validation-02.txt | ||||||||||||||
| Registration Data Access Protocol (RDAP) Extension for Server Validation | ||||||||||||||
|
This document describes an Registration Data Access Protocol (RDAP) extension for providing the status of server validations. Server validations can be done for an extensible set of types, with examples including validating DNS resolution with the type "dns" and validating DNSSEC with the type "dnssec". The validations can be performed synchronously in the provisioning command or asynchronously based on a triggering command or a schedule. The extension will provide the status of the validations, by type, performed by the server in an RDAP lookup response. | |||||||||||||
| draft-gould-regext-rdap-status-set-03.txt | ||||||||||||||
| Registration Data Access Protocol (RDAP) Extension for Status Set | ||||||||||||||
|
This document describes an Registration Data Access Protocol (RDAP) extension for including status sets assigned to RDAP object classes, such as the Domain Object Class and the Nameserver Object Class in [RFC9083]. There can be many overlapping reasons for each of the "status" member values, such as implementing a lock service, complying with a court order, or addressing domain abuse. A status set defines an object representing the reason for setting a "status" value, so clients and servers can effectively manage the overlapping reasons of individual "status" values using the status sets. This RDAP extension supports returning the assigned client and server status sets with additional data members, such as the mapped "status" values and when the status set was assigned. | |||||||||||||
| draft-gq-savnet-sav-terms-02.txt | ||||||||||||||
| Currently Used Terminology Related to Source Address Validation | ||||||||||||||
|
This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology. | |||||||||||||
| draft-grant-ntp-server-identifier-extension-00.txt | ||||||||||||||
| NTP Server Identifier Extension | ||||||||||||||
|
This document defines an extension field that allows operators of NTP services the ability to provide additional information about their services to clients which request it. | |||||||||||||
| draft-gravit-gevp-07.txt | ||||||||||||||
| Gravit Epistemic Verification Protocol (GEVP) | ||||||||||||||
|
GEVP defines a minimal protocol for epistemic convergence. Renamed from VCP to avoid collision with draft-kamimura-scitt-vcp. Invariant C_manip > C_val*2.0 as engineering heuristic. Theta 0.73 RECOMMENDED, pinned 7755f53. Architecture stable per https://github.com/GravitOpenNetwork/gravit-canon. This revision adds a formal mapping between GEVP's Epistemic State Machine and the evidence taxonomy defined in the Gravit Verifiable Epistemic Decision Standard (VEDS). | |||||||||||||
| draft-gravit-verifiable-epistemic-decision-00.txt | ||||||||||||||
| Gravit Verifiable Epistemic Decision Standard | ||||||||||||||
|
This document defines the normative requirements for the Gravit decision-making system. Gravit's core principle is to base all definitive decisions exclusively on verifiable epistemic grounds. This specification establishes mandatory rules for evidence admissibility, epistemic classification, traceability, failure handling, auditability, and security in adversarial environments, including a taxonomy of admissible evidence and failure outcomes, a required Decision Record format, and an explicit threat model with corresponding verification mechanisms. The goal is to ensure that all decisions are reproducible, auditable, and resistant to manipulation, thereby fostering trust and accountability in distributed and high-stakes settings. | |||||||||||||
| draft-gray-lamps-composite-fndsa-lms-00.txt | ||||||||||||||
| Composite FN-DSA and LMS Digital Signature Algorithm for use in X.509 Public Key Infrastructure | ||||||||||||||
|
This document defines a composite signature scheme combining the FN- DSA (Falcon) digital signature algorithm with the Leighton-Micali Signature (LMS) scheme defined in RFC 8554. This construction is designed for use within X.509 Public Key Infrastructure (PKI) and follows the composite signature paradigm defined in [I-D.ietf-lamps-pq-composite-sigs]. | |||||||||||||
| draft-gray-lamps-compositepkc-01.txt | ||||||||||||||
| Preventing Key Reuse and Cross-Key Forgeries in Composite ML-DSA | ||||||||||||||
|
This document defines a small, backwards-compatible change to composite ML-DSA that cryptographically binds the signature to the specific composite public key. It does so by defining a Public-Key Context value (pkc) equal to a hash of the serialized composite public key, and by setting the composite context field to that value. This prevents key reuse and cross-key forgeries across different composite keys, while preserving the API of Composite ML-DSA. The construction introduces two helper procedures to compute pkc from either the composite private key or the composite public key. | |||||||||||||
| draft-gray-plants-mtc-deploy-use-cases-01.txt | ||||||||||||||
| Merkle Tree Certificates Deployment Use Cases | ||||||||||||||
|
Merkle Tree Certificates (MTC) I-D.ietf-plants-merkle-tree-certs has been defined for the use case of the WebPKI. In this document we explore when and how MTC in parts or full can be used in different use cases. Some of this use-cases may provide benefit for private PKI usage. | |||||||||||||
| draft-grayson-connectinfo-10.txt | ||||||||||||||
| A syntax for the RADIUS Connect-Info attribute used in Wi-Fi networks | ||||||||||||||
|
This document describes a syntax for the Connect-Info attribute used with the RADIUS protocol, enabling RADIUS clients to provide RADIUS servers information pertaining to a user's connection with an IEEE 802.11 wireless network. | |||||||||||||
| draft-grayson-radext-wba-wifi-quality-metrics-00.txt | ||||||||||||||
| RADIUS WBA Vendor-Specific Attributes for Wi-Fi Network Quality Metric Reporting | ||||||||||||||
|
This document defines a set of RADIUS Vendor-Specific Attributes (VSAs) designed to encode network quality metrics that are not uniquely associated with an IEEE 802.11 (Wi-Fi) connection. These attributes enable access network quality information to be communicated between RADIUS clients and servers. | |||||||||||||
| draft-gregoire-moq-msfts-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-greicodex-fidex-protocol-01.txt | ||||||||||||||
| FideX Application Statement 5 (AS5) Protocol | ||||||||||||||
|
This document specifies the FideX Protocol (AS5), a modern application-layer protocol for secure Business-to-Business (B2B) message exchange. FideX provides cryptographic non-repudiation, data integrity, and confidentiality using JOSE (JSON Object Signing and Encryption) over HTTPS, replacing legacy AS2 and AS4 standards with a REST-oriented approach accessible to modern web developers. FideX adopts the "AS" naming lineage: AS2 ([RFC4130]) used S/MIME over HTTP; AS4 ([OASIS-ebMS]) used SOAP/WS-Security; AS5 (FideX) uses REST/JSON/JOSE over HTTPS. This document defines the message format, cryptographic operations, partner discovery, state management, acknowledgment receipts (J-MDN), and error handling. | |||||||||||||
| draft-grimminck-safe-ioc-sharing-14.txt | ||||||||||||||
| Safe and Reversible Sharing of Malicious URLs and Indicators | ||||||||||||||
|
This document codifies a consistent and reversible convention used in the threat intelligence and security communities for sharing potentially malicious indicators of compromise (IOCs), such as URLs, IP addresses, email addresses, and domain names. It describes an obfuscation format that reduces the risk of accidental execution or activation when IOCs are displayed or transmitted. The transformation renders an indicator syntactically invalid as a URI while keeping it recognizable to a human reader, and the original value can be recovered deterministically. Safe-IOC strings are a textual rendering convention, not URIs, and are not intended to be processed by generic URI parsers. These conventions aim to improve interoperability among tools and feeds that exchange threat intelligence data. | |||||||||||||
| draft-grow-bmp-stats-informational-tlv-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-gu-nmrg-intent-translator-03.txt | ||||||||||||||
| An Intent Translation Framework for Internet of Things | ||||||||||||||
|
This document describes an intent translation framework for Internet of Things (IoT) and next-generation network management environments. The framework converts user-issued natural language intents into structured policy representations that can be consumed by management and orchestration systems. The framework decomposes intent interpretation into parallel role- and-scenario classification and entity-and-slot extraction, merges the results into an intermediate representation, and generates a candidate policy document under schema-as-grammar constraints derived from the target schema. A policy validator then checks the candidate output for schema conformance, cross-slot consistency, and faithfulness to the original intent. When validation fails, a trace driven recovery agent dispatches targeted regeneration or re- extraction rather than relying on generic retry. | |||||||||||||
| draft-gudzenko-httpbis-h2-cipher-selection-00.txt | ||||||||||||||
| Cipher Suite Selection for HTTP/2 Negotiation over TLS 1.2 | ||||||||||||||
|
Section 9.2.2 of RFC 9113 identifies, but does not normatively resolve, a failure mode in which the application protocol and the cipher suite are selected independently, resulting in a successfully completed TLS handshake whose negotiated parameters may be rejected at the HTTP/2 layer with an INADEQUATE_SECURITY connection error. This document addresses that gap by adding a SHOULD-level procedure that coordinates cipher suite selection with ALPN negotiation, and updates RFC9113. | |||||||||||||
| draft-gueron-cfrg-dndkgcm-05.txt | ||||||||||||||
| Double Nonce Derive Key AES-GCM (DNDK-GCM) | ||||||||||||||
|
This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM). It operates with a 32- byte root key and is designed to encrypt with a 24-byte random nonce and optionally to provide for key commitment. Encryption takes the root key and a 15-byte portion of the random nonce, and derives a fresh 32-byte encryption key and (optionally) a key commitment value. Then, it invokes AES-GCM with the derived key and the remaining bytes of the nonce, and outputs the ciphertext, authentication tag and the key commitment value. Although this is not the primary use case, it is also possible to use DNDK-GCM with a non-repeating but non-random nonce (i.e., a "counter- based nonce"). The low collision probability in a collection of 24-byte random nonces and the per-nonce derivation of an encryption key extend the lifetime of the root key, and the scheme can support processing up to 2^64 bytes under a given root key. DNDK-GCM introduces a relatively small overhead compared to using AES-GCM directly, and its security relies only on the standard assumption that AES acts as a pseudorandom permutation. | |||||||||||||
| draft-guo-krb-spake-2fa-02.txt | ||||||||||||||
| Kerberos SPAKE with Two-Factor Authentication | ||||||||||||||
|
This document defines a new two-factor authentication mechanism for the Kerberos SPAKE pre-authentication. The mechanism uses the time- based one-time password (TOTP) as a second factor, and combines it with the password factor in a more secure way, which can prevent attackers from both impersonating Kerberos clients and obtaining TGTs' session keys in case of any factor leakage. | |||||||||||||
| draft-guo-sidrops-rpa-profile-02.txt | ||||||||||||||
| A Profile for Route Path Authorizations (RPAs) | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Route Path Authorizations (RPA) objects used in Resource Public Key Infrastructure (RPKI). An RPA is a digitally signed object that provides a means of verifying whether an IP address block is received from AS a to AS b and announced from AS b to AS c. When validated, an RPA's eContent can be used for the detection and mitigation of route hijacking, especially providing protection for the AS_PATH attribute in BGP-UPDATE. This object is a variant of the aut-num object in the Internet Routing Registry (IRR). | |||||||||||||
| draft-guorong-utxo-dns-01.txt | ||||||||||||||
| UTXO Domain Name System (UTXO6-DNS): Base Protocol and PRN Regulatory Extensions | ||||||||||||||
|
All domain names used in examples throughout this document use ".test" in accordance with RFC 2606. In actual deployments, ".utxo" is used. This document specifies the UTXO Domain Name System (UTXO6-DNS), a decentralized naming protocol that maps .utxo domain names to blockchain UTXO (Unspent Transaction Output) endpoints and generates verifiable IPv6 Interface Identifiers (IIDs) using Verifiable Random Functions (VRFs). The base protocol defines a new DNS RR type (UTXO, code 260), an EDNS0 option for capability discovery, and fallback mechanisms to coexist with legacy DNS, updating RFC 1034, RFC 1035, and RFC 7217. Additionally, this document defines an optional compliance overlay --- the Penetrating Regulation Node (PRN) extensions --- that can be deployed by regulated financial institutions to meet AML/CFT requirements, provide audit trails, and verify legal entity identities using GLEIF vLEI credentials. The PRN extensions include optional regulatory attributes in UTXO RRs, a new PRNAUDIT RR type for daily audit summaries, a RESTful API (PRN-API) for regulatory dashboards, a 2-of-3 MPC threshold signature framework for audit integrity, and native vLEI integration. This document also describes a transaction lifecycle compliance enforcement model (AnteHandler) and an application-layer policy format (AgentPolicyEnvelope) for declarative authorization. The PRN extensions are privacy-preserving (only Merkle roots and aggregated statistics are shared), decentralized (no central authority), and verifiable (audit summaries are jointly signed by independent auditing firms). *This document is published as an Experimental specification.* It is not an IETF standard and does not represent IETF consensus. It is intended for informational purposes, to facilitate implementation experience, and to support early discussion within the DNSOP working group. See Section 1 for details. *Note:* The AgentPolicyEnvelope JSON Schema (Appendix I) and the AnteHandler compliance enforcement model (Section 4) are application- layer constructs provided as informative examples. They are not on the IETF standards track and are not subject to IETF consensus. Their inclusion in this document is intended to facilitate interoperability of experimental deployments. | |||||||||||||
| draft-gupta-emu-eap-wsim-01.txt | ||||||||||||||
| EAP-WSIM: SIM-Based EAP Authentication for Enterprise Wi-Fi Using the MILENAGE-ML-KEM-FWD Construction | ||||||||||||||
|
Enterprise Wi-Fi networks authenticate devices using enterprise credentials and provisioning policies that are entirely independent of MNO subscriber identity. As a result, MNO application traffic on enterprise Wi-Fi is completely anonymous at the Wi-Fi layer: the enterprise cannot identify MNO subscribers, apply per-subscriber QoS, or support fast BSS transitions for VoWiFi continuity. This document specifies EAP-WSIM, an evolutionary enhancement of EAP- AKA' (RFC 9048) that enables MNO devices to authenticate to enterprise Wi-Fi using their existing SIM credential (WSIM-Card) without contacting the MNO backend during authentication. A WSIM- Authentication Server (WSIM-AS) within the enterprise Wi-Fi infrastructure holds MNO-provisioned MASTER KEY material in tamper- resistant security hardware. Per-subscriber MILENAGE key material is derived on-demand from the MASTER KEY using the device's IMSI -- identical in principle to MNO SIM personalization -- entirely within the security hardware boundary. No per-subscriber key provisioning at the WSIM-AS is required. | |||||||||||||
| draft-gupta-httpapi-events-query-03.txt | ||||||||||||||
| HTTP Events Query | ||||||||||||||
|
Events Query is a minimal protocol built on top of HTTP that allows user agents to receive event notifications directly from any resource of interest. It uses the QUERY method [RFC10008] to request (optionally) the current representation and subsequent event notifications within a single response. The Events Query Protocol (EQP) is predicated on the idea that the most intuitive source for event notifications is the resource itself. | |||||||||||||
| draft-guthrie-cnsa2-ipsec-profile-04.txt | ||||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for IPsec | ||||||||||||||
|
This document defines a base profile for IPsec for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a cybersecurity advisory that outlines quantum-resistant cryptographic algorithm policy for national security applications. This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ IPsec. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This profile is made publicly available for use by developers and operators of these and any other system deployments. | |||||||||||||
| draft-guthrie-ipsecme-aes-gcm-siv-01.txt | ||||||||||||||
| Using AES-GCM-SIV in the Internet Protocol Version 2 (IKEv2) and Encapsulating Security Payload (ESP) Protocols | ||||||||||||||
|
This document specifies the use of AES-GCM-SIV in the Internet Key Exchange Protocol version 2 (IKEv2) and the Encapsulating Security Payload (ESP) protocols. This document also adds AES-GCM-SIV to the IANA IKEv2 registry for "Transform Type 1 - Encryption Algorithm Transform IDs." AES-GCM-SIV is a nonce misuse-resistant authenticated encryption with associated data (AEAD) algorithm based on AES-GCM. | |||||||||||||
| draft-gutmann-pkcs15-05.txt | ||||||||||||||
| PKCS #15 Updates | ||||||||||||||
|
This document describes updates to the PKCS #15 standard made since the original publication of the standard. | |||||||||||||
| draft-gutmann-ssh-preauth-06.txt | ||||||||||||||
| A Pre-Authentication Mechanism for SSH | ||||||||||||||
|
Devices running SSH are frequently exposed on the Internet, either because of operational considerations or through misconfiguration, making them vulnerable to the constant 3-degree background radiation of scanning and probing attacks that pervade the Internet. This document describes a simple pre-authentication mechanism that limits these attacks with minimal changes to SSH implementations and no changes to the SSH protocol itself. | |||||||||||||
| draft-gutmann-tls-lts-18.txt | ||||||||||||||
| TLS 1.2 Update for Long-term Support (LTS) | ||||||||||||||
|
This document specifies an update of TLS 1.2 for long-term support (LTS) on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis. | |||||||||||||
| draft-haberkamp-ipp-01.txt | ||||||||||||||
| Intent Provenance Protocol (IPP) | ||||||||||||||
|
This document specifies the Intent Provenance Protocol (IPP), a cryptographic infrastructure standard for carrying verified human intent through chains of autonomous artificial intelligence agent actions. IPP defines the Intent Token, a signed, bounded, and tamper-evident data structure that travels with every agentic action, preserving an unbroken, auditable lineage from the originating human principal to each terminal action executed on their behalf. As AI agents become primary actors in enterprise environments, executing transactions, accessing sensitive data, orchestrating sub- agents, and operating across organizational boundaries, the absence of a shared trust substrate creates systemic risk to organizational accountability, regulatory compliance, and legal liability attribution. IPP addresses this gap by establishing a protocol layer that operates above cryptographic authentication and below application logic, making human intent a first-class, verifiable primitive in agentic systems. IPP introduces four foundational properties, Lineage, Boundedness, Non-repudiation, and Interoperability, enforced through a combination of Ed25519 digital signatures, Decentralized Identifiers (DIDs), and a Narrowing Invariant that prevents any derived token from exceeding its parent's authorized scope. The protocol is framework-agnostic, cloud-agnostic, and designed for open implementation across the ecosystem of AI orchestration platforms. | |||||||||||||
| draft-hajdusek-qirg-timing-physics-01.txt | ||||||||||||||
| Timing Regimes in Quantum Networks and their Physical Underpinnings | ||||||||||||||
|
Entangling quantum networks build on new physical mechanisms to distribute quantum entanglement among a set of nodes over a set of links. To design a complete network protocol stack with proper division of responsibilities into layers, hardware and protocol engineers must share an understanding of those physical mechanisms and use a common vocabulary. This document bridges the abstract concepts described in [RFC9340] and the underlying physics to engineering concerns such as timing constraints on arrival of photons and exchange of supporting classical messages. The equations presented here will serve as reference points for architectural decisions in future documents, allowing future documents to deal directly in code without complex mathematics. Application-layer developers will not need the low-level physics presented here. | |||||||||||||
| draft-halmir-mpls-ecn-04.txt | ||||||||||||||
| Explicit Congestion Notification Using MPLS Network Actions | ||||||||||||||
|
It has been broadly demonstrated that user experience improvements for time-critical applications have not increased at the same pace as network throughput (i.e., the increased bandwidth does not result in a corresponding increase in the user experience). Optimizing network latency rather than throughput can lead to a significantly improved user experience for time-critical applications. Low Latency, Low Loss, and Scalable Throughput (L4S) technology, introduced in RFC 9330, uses Explicit Congestion Notification (ECN) bits by marking packets suffering potential congestion in the network. L4S operates as a congestion-control mechanism, using markers within the data packets to detect and promptly respond to congestion conditions. This feedback loop enables devices (e.g., endpoints such as client devices and server devices) to adjust data flow in real-time, preventing bottlenecks and ensuring smoother transmission. RFC 5129 describes a mechanism for supporting ECN in the Multiprotocol Label Switching (MPLS) data plane. That mechanism is based on the codepoints that take part in the Traffic Class (TC) field and, thus, prevent the use of TC field for traffic differentiation. This document defines how ECN can be supported in the MPLS data plane using the MPLS Network Actions technology. | |||||||||||||
| draft-haluska-sipping-directory-assistance-11.txt | ||||||||||||||
| Considerations for Information Services and Operator Services Using SIP | ||||||||||||||
|
Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. | |||||||||||||
| draft-hamr-oauth-agent-delegation-01.txt | ||||||||||||||
| An Attenuated Delegation Profile for Automated Agents | ||||||||||||||
|
This document specifies a profile for delegating authorization to automated agents across administrative domains. It defines an HTTP header field, Agent-Delegation, that carries a chain of attenuated delegation links. Each link narrows the scope, tightens or holds a set of floor conditions, and shortens or holds the expiry of its parent. A verifier checks every link in the chain, not only the last, and rejects the chain if any link violates attenuation. The profile is deliberately agnostic to the credential format and to the nature of the entity that issues floor attestations; it specifies required properties, not a specific encoding or a specific kind of issuer. It composes with, and does not replace, existing work on agent credential provisioning and posture. | |||||||||||||
| draft-han-ai-manifest-02.txt | ||||||||||||||
| AI Manifest: Site-Published Friction-Recovery Descriptors for AI Agents | ||||||||||||||
|
This document specifies the AI Manifest, a JSON-based format with which a website operator publishes an AI Friction-Recovery Manifest (AFRM): a declarative, advisory description of the known user- interface (UI) traps on a site, the framework hints that contextualize them, and the interaction shortcuts that bypass them. An autonomous AI agent that uses browser-automation tools discovers the manifest out-of-band and consults it as reference data when it encounters friction, instead of re-inferring site-specific behavior from the full Document Object Model (DOM) by trial and error. The manifest is advisory data published by the origin; it is not part of, and does not modify, any browser-automation tool schema. The specification defines five interoperable discovery methods, the AFRM three-part schema (frameworkHints, knownTraps, and shortcuts), and an OPTIONAL SHA-256 canonical-hash verification procedure via a trust registry, together with security mitigations against prompt- injection attacks. Empirical evaluation with a contemporary LLM browser agent on a proprietary-knowledge enterprise task -- an SAP S/4HANA-style table- maintenance screen whose valid values depend on a company-code registration scope that is not derivable from public or training knowledge -- shows that a site-published manifest, consumed directly by the agent with no external runtime, reduces interaction actions by approximately 54% and input tokens by approximately 45% relative to the no-manifest baseline, with both conditions completing the task. The manifest's value concentrates where the agent cannot succeed from training knowledge alone: site-specific dependencies, data, and hard mechanical blocks. This -02 revision supersedes the deterministic-runtime framing of draft-han-ai-manifest-01. The earlier revision reported a single- trial preliminary measurement and concluded that an embedded manifest is of negative value unless paired with a deterministic execution runtime (an "SDK"). Subsequent multi-condition measurement with a real LLM agent shows that a manifest is consumed and is useful on its own; an out-of-band discovery path (the Method A well-known URI, or the user-curated Method E) avoids the prompt-injection-defense friction that the earlier embedded-only trial encountered. A deterministic runtime remains OPTIONAL -- useful for latency- or service-level-sensitive deployments -- but is no longer presented as REQUIRED. | |||||||||||||
| draft-han-anima-gap-analysis-ai-asa-00.txt | ||||||||||||||
| Problem Statement and Gap Analysis for Autonomic Networking with AI- powered Autonomic Service Agent | ||||||||||||||
|
This document presents a problem statement and gap analysis of the technical challenges faced by the GeneRic Autonomic Signaling Protocol (GRASP) [RFC8990] when it is used, within the Autonomic Networking Infrastructure (ANI) defined by the ANIMA Working Group [RFC8993], to support enhanced Autonomic Service Agents that incorporate Large Language Model (LLM) capabilities, referred to in this document as AI-ASAs. | |||||||||||||
| draft-han-anima-grasp-congestion-relief-01.txt | ||||||||||||||
| Automatic Network Congestion Relief in GeneRic Autonomic Signaling Protocol (GRASP) | ||||||||||||||
|
This draft defines new autonomic technical objectives for automatic congestion relief using the Grasp protocol acording to the [RFC 9222]. In operator networks, network devices can automatically respond and achieve real-time self-healing for network failures such as fiber optic cable faults and optical module malfunctions | |||||||||||||
| draft-han-bmwg-agent-security-benchmark-00.txt | ||||||||||||||
| Security Evaluation Benchmark for AI Agents | ||||||||||||||
|
This document defines a security evaluation benchmark framework for AI agents. It is divided into two parts: evaluation metrics and evaluation methodology, comprising four first-level evaluation dimensions and 55 second-level metrics, as well as a comprehensive evaluation methodology system covering all scenarios, including static evaluation, dynamic evaluation, attack-defense evaluation, compliance evaluation, and quantitative evaluation. It aims to assess the risk profile of AI agents throughout their entire lifecycle, including perception risks, memory risks, decision-making risks, and execution risks. | |||||||||||||
| draft-han-detnet-tc-dev-handling-00.txt | ||||||||||||||
| Handling of traffic characteristic deviation for DetNet | ||||||||||||||
|
Deterministic Networking (DetNet) relies on resource reservation to guarantee bounded-latency forwarding, yet traffic characteristic deviations from microbursts and flow aggregation frequently occur at aggregation nodes. Native handling approaches like direct packet discard or best-effort forwarding lead to severe service degradation. This document proposes an enhanced traffic characteristic deviation solution for DetNet. This solution specifies two complementary data- plane policies: the squeezing policy defers deviated traffic to subsequent timeslots within a configurable threshold while preserving deterministic attributes to absorb transient bursts; the degrading policy reclassifies over-threshold traffic to lower-priority queues for graceful handling, avoiding unnecessary packet loss. These policies can be enabled independently or combined, ensuring the preferential scheduling and preservation of deterministic service traffic under deviation conditions. | |||||||||||||
| draft-han-fann-codeployment-pfc-fgfc-00.txt | ||||||||||||||
| Use cases and Requirement for Flow Control Collaboration Across DCNs and WAN | ||||||||||||||
|
The demand for lossless network transmission and the application of flow control mechanisms have expanded from DCNs (Data Center Networks) to WANs(Wide Area Networks). To mitigate PFC - related issues in WANs, the fine - grained flow control is proposed. This mechanism aims to achieve precise control at flow / tenant levels, limits flow control to specified paths and slices, and provides intelligent congestion backpressure. As current DCN already adopts PFC mechanisms, the fine-grained flow control in WANs needs to work with PFC in DCNs to achieve end-to-end flow control. This document describes the use cases and requirements for the collaboration of flow control mechanisms across DCNs and WANs. | |||||||||||||
| draft-han-rtgwg-agent-gateway-intercomm-framework-02.txt | ||||||||||||||
| Agent Gateway Intercommunication Framework | ||||||||||||||
|
This document defines the framework and requirements for intercommunication between Agent Gateways (AGw) in the Agent Internet (IoA) ecosystem. It specifies a hierarchical layered model, functional components, protocol requirements and deployment consideration for AGw interconnection. The framework aims to address data synchronization, protocol compatibility, and security challenges in cross-domain agent collaboration, enabling efficient and scalable communication for distributed intelligent agents. It is compatible with existing IoA reference architectures while specializing in cross-domain gateway interoperability. | |||||||||||||
| draft-han-rtgwg-fine-grained-backpressure-02.txt | ||||||||||||||
| Fine-Grained Flow Control Backpressure Mechanism for Wide Area Networks | ||||||||||||||
|
This document specifies a fine-grained flow control backpressure mechanism for Wide Area Networks (WANs). Leveraging data-plane congestion detection and notification, it enables millisecond-level congestion response. The mechanism enhances Layer 2 PFC by extending network protocols (e.g., ICMPv6) for congestion backpressure messaging in WANs, and leverages network slicing isolation to provide fine-grained flow control at tenant or task granularity. It addresses the limitations of traditional flow control mechanisms in WAN environments through fast and precise backpressure, and supports multi-hop propagation of congestion notifications along the forwarding path. | |||||||||||||
| draft-hao-civ-03.txt | ||||||||||||||
| Caller ID Verification In Heterogeneous Telecommunication Networks | ||||||||||||||
|
This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support a Caller ID Verification (CIV) method. CIV authenticates the caller ID of an incoming call through a challenge-and-response process across both IP and non-IP networks without requiring a trusted third party or a public key infrastructure. When receiving a call with a claimed phone number, the called party holds the call and sends a quickly terminated INVITE request (like a flash call) to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller would receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new option tag, "civ", in the Supported header field of the INVITE request. This tag allows the calling party to indicate support for CIV in the initial call. Second, it adds a special value "civ-veri- call" for the Purpose parameter of the Call-Info header field. This value allows the called party to make a verification call, indicating the purpose of the call is to transmit a challenge rather than establish a phone conversation. CIV uses the standard Session-ID header in the INVITE request to allow the calling party to explicitly match the verification call with the initial call. Whilst this document focuses on IP networks, the same CIV protocol also works with non-IP networks (e.g., SS7) by including the "civ" tag, the "civ-veri-call" value and the session ID in the User-to-User Information (UUI) parameter. | |||||||||||||
| draft-hardaker-dns-wgs-at-ietf-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hardaker-dnsop-dns-xfr-scheme-01.txt | ||||||||||||||
| The DNS XFR URI Schemes | ||||||||||||||
|
The DNS protocol provides an in-band mechanism for transferring the contents of a zone from a server to a client. This is most frequently used when secondary servers are transferring the DNS zone content from their configured primary server. This document defines a Uniform Resource Identifier (URI) scheme for referencing DNS servers from which DNS zone contents can be transferred. | |||||||||||||
| draft-hardaker-dnsop-nothing-new-00.txt | ||||||||||||||
| Support for nothing-new notifications in the DNS | ||||||||||||||
|
The DNS protocol has increasingly needed to carry larger records than it was originally designed to carry. This has resulted in performance impacts due to both the size increases and requiring TCP instead of only UDP. Of particular note is the expected large increase in records relating to post-quantum signing algorithms. To help mitigate, but not entirely prevent, these impacts, this document proposes a new "nothing new" NN flag, a LARGE Redirection Resource record type, and how these can integrate with current and future DNSSEC DNSKEY and RRSIG records. | |||||||||||||
| draft-hardaker-dnsop-root-zone-pub-list-guidelines-02.txt | ||||||||||||||
| Guidelines for IANA DNS Root Zone Publication List Providers | ||||||||||||||
|
This document describes guidelines for entities that wish to publish a list of URLs from where the contents of the IANA DNS root zone may be obtained. These guidelines are specifically provided as guidance to IANA, but these suggestions may be applicable to any entity wishing to build a list of IANA DNS root zone sources for their own purposes. | |||||||||||||
| draft-hardaker-dnsop-root-zone-publication-points-02.txt | ||||||||||||||
| An IANA root zone publication source list format | ||||||||||||||
|
This document describes a machine readable format to be used by IANA to publish a list of sources where the contents of the IANA DNS Root Zone may be fetched from. | |||||||||||||
| draft-hardaker-dnsop-rss-usage-considerations-01.txt | ||||||||||||||
| DNS Root Server System Usage Considerations | ||||||||||||||
|
This document explores various technologies developed to enhance the DNS, focusing specifically on interactions with the DNS Root Server System (RSS). It examines a number of the protocols and evaluates their impact on communication with the RSS. | |||||||||||||
| draft-hardman-verifiable-voice-protocol-07.txt | ||||||||||||||
| Verifiable Voice Protocol | ||||||||||||||
|
Verifiable Voice Protocol (VVP) authenticates and authorizes organizations and individuals making and/or receiving telephone calls. This eliminates trust gaps that malicious parties exploit. Like related technologies such as SHAKEN, RCD, and BCID, VVP uses STIR to bind cryptographic evidence to a SIP INVITE, and verify this evidence downstream. VVP can also let evidence flow the other way, proving things about the callee. VVP builds from different technical and governance assumptions than alternatives, and uses richer, stronger evidence. This allows VVP to cross jurisdictional boundaries easily and robustly. It also makes VVP simpler, more decentralized, cheaper to deploy and maintain, more private, more scalable, and higher assurance. Because it is easier to adopt, VVP can plug gaps or build bridges between other approaches, functioning as glue in hybrid ecosystems. For example, it may justify an A attestation in SHAKEN, or an RCD passport for branded calling, when a call originates outside SHAKEN or RCD ecosystems. VVP also works well as a standalone mechanism, independent of other solutions. An extra benefit is that VVP enables two-way evidence sharing with verifiable text and chat (e.g., RCS and vCon), as well as with other industry verticals that need verifiability in non-telco contexts. | |||||||||||||
| draft-hardt-aauth-bootstrap-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hardt-aauth-headers-00.txt | ||||||||||||||
| HTTP AAuth Headers | ||||||||||||||
|
This document defines two HTTP response headers — AAuth-Requirement and AAuth-Error — and profiles HTTP Message Signatures ([RFC9421]) for request authentication, with keying material conveyed via the Signature-Key header ([I-D.hardt-httpbis-signature-key]). A server uses AAuth-Requirement to require pseudonymous or verified agent identity, to request user interaction, or to signal that approval is pending. AAuth-Error conveys structured error information. Both headers use extensible registries for their values. | |||||||||||||
| draft-hardt-email-verification-02.txt | ||||||||||||||
| Email Verification Protocol | ||||||||||||||
|
This document defines the Email Verification Protocol (EVP), the HTTP-level protocol by which a browser obtains a signed email verification token from an issuer and presents it to a relying party (RP). The protocol enables web applications to verify that a user controls an email address without sending a verification email. It uses a three-party model in which the browser intermediates between the RP and the issuer, hiding the RP's identity from the issuer and supporting private, per-RP email addresses to prevent cross-site correlation. This document covers issuer discovery, the token issuance request, the Email Verification Token (EVT) and Key Binding JWT (KB-JWT) formats, and token verification. The browser API — how the user selects an email address and how the token is delivered to the RP — is defined in the companion W3C Email Verification API ([EVP-Browser]). | |||||||||||||
| draft-hardt-httpbis-signature-key-09.txt | ||||||||||||||
| HTTP Signature Keys | ||||||||||||||
|
This document defines five HTTP header fields for use with HTTP Message Signatures as defined in RFC 9421. The Signature-Key request header distributes public keys used to verify signatures, with eight initial key distribution schemes: pseudonymous inline keys (hwk), self-issued key delegation via JWK Thumbprint JWTs (jkt-jwt), identified signers with JWKS URI discovery (jwks_uri), direct JWKS fetch (jwks), JWT-based delegation (jwt), self-issued JWTs (self- jwt), X.509 certificate chains (x509), and references to previously cached assertions (cached). The Accept-Signature-Scheme and Accept- Signature-Alg response headers state the schemes and algorithms a server accepts, so a client can select both before it signs. The Signature-Error response header provides structured error information when signature verification fails, and the Signature-Key-Cache response header issues a cache identifier by which a caller can reference a previously presented assertion instead of resending it. Together, these mechanisms enable flexible trust models ranging from privacy-preserving pseudonymous verification to horizontally-scalable delegated authentication and PKI-based identity chains. | |||||||||||||
| draft-hardt-oauth-aauth-protocol-10.txt | ||||||||||||||
| AAuth Protocol | ||||||||||||||
|
This document defines the AAuth authorization protocol for agent-to- resource authorization and identity claim retrieval. The protocol supports four resource access modes — identity-based, resource- managed (two-party), PS-asserted (three-party), and federated (four- party) — with agent governance as an orthogonal layer. It builds on the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]) for HTTP Message Signatures and key discovery. | |||||||||||||
| draft-hardt-oauth-protected-authorization-00.txt | ||||||||||||||
| OAuth Protected Authorization | ||||||||||||||
|
This document defines browser support for protecting OAuth 2.0 authorization requests and authorization responses during redirect- based authorization flows. A single Structured Field header field, OAuth-Authorization, is set by the OAuth client in the redirect response that sends the browser to the authorization server, and by the authorization server in the redirect response that returns the browser to the OAuth client. In both cases the browser augments the header with the attested origin of the redirecting party and delivers it to the redirect destination. The mechanism provides security for the authorization request: the authorization server receives a browser-attested, tamper-evident statement of which origin initiated the request. The mechanism provides security and privacy for the authorization response: the authorization code is delivered in the browser-protected header instead of the redirect URI, and never appears in a URL, eliminating its exposure through browser history, server logs, Referer headers, analytics systems, and URL sharing. The header is generated, validated, and delivered by the browser, and is inaccessible to scripts, service workers, and browser extensions. Existing OAuth deployments continue to function unchanged; the protections activate only when the OAuth client, browser, and authorization server all support them. | |||||||||||||
| draft-hares-idr-fsv2-more-ip-filters-05.txt | ||||||||||||||
| BGP Flow Specification Version 2 - More IP Filters | ||||||||||||||
|
The BGP flow specification version 2 (FSv2) for Basic IP defines user ordering of filters along with FSv1 IP Filters and FSv1 actions. This draft defines the format for the Extended IP Filters for Flow Specification FSv2. | |||||||||||||
| draft-haresh-sushrut-mib-classification-01.txt | ||||||||||||||
| SNMPD to use cache and shared database based on MIB Classification | ||||||||||||||
|
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. | |||||||||||||
| draft-harrison-sshm-mlkem-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hartman-credential-broker-4-agents-00.txt | ||||||||||||||
| Credential Broker for Agents (CB4A) | ||||||||||||||
|
This document specifies a Credential Broker for Agents (CB4A). a credential vaulting and brokering architecture that mediates AI agent access to API credentials. Agents never hold real long-lived credentials. Instead, they receive short-lived, narrowly scoped, auditable proxy credentials issued by a broker that separates policy decisions from credential delivery. The architecture addresses the "credential sprawl" risk inherent in agentic AI, where agents aggregating access across many services become high-value compromise targets. CB4A builds on SPIFFE/SPIRE for workload identity, uses a Policy Decision Point / Credential Delivery Point separation inspired by NIST SP 800-207, and employs DPoP (RFC 9449) for sender-constrained token binding. The specification defines three credential proxy models, a tiered approval framework, and a comprehensive threat model with ten identified threats and their mitigations. | |||||||||||||
| draft-harvey-cfrg-mtl-mode-09.txt | ||||||||||||||
| Merkle Tree Ladder (MTL) Mode Signatures | ||||||||||||||
|
This document provides an interoperable specification for Merkle tree ladder (MTL) mode, a technique for using an underlying signature scheme to authenticate an evolving series of messages. MTL mode can reduce the signature scheme's operational impact. Rather than signing messages individually, the MTL mode of operation signs structures called "Merkle tree ladders" that are derived from the messages to be authenticated. Individual messages are then authenticated relative to the ladder using a Merkle tree authentication path and the ladder is authenticated using the public key of the underlying signature scheme. The size and computational cost of the underlying signatures are thereby amortized across multiple messages, reducing the scheme's operational impact. The reduction can be particularly beneficial when MTL mode is applied to a post-quantum signature scheme that has a large signature size or computational cost. As an example, the document shows how to use MTL mode with ML-DSA as defined in FIPS204 and SLH-DSA as defined in FIPS205. Like other Merkle tree techniques, MTL mode's security is based only on cryptographic hash functions, so the mode is quantum- safe based on the quantum-resistance of its cryptographic hash functions. | |||||||||||||
| draft-hause-asip-00.txt | ||||||||||||||
| ASIP: AS-Structured Internet Protocol (128-bit) | ||||||||||||||
|
ASIP (AS-Structured Internet Protocol; IP version 8 on the wire) is a 128-bit network protocol that defines a new address family alongside IPv4. ASIP is NOT a wire-level superset of IPv4: an unmodified IPv4 device cannot send, receive, or forward an ASIP packet. Interoperation between ASIP-aware endpoints and legacy IPv4 networks is provided by a defined transition mechanism (stateless translation at AS boundaries and encapsulation across non-upgraded transit), not by wire compatibility. ASIP's addressing architecture arranges the 128-bit address as four 32-bit fields (ASN routing locator, zone, subnet, host). The ASN locator is used as a routing hint rather than a hard identity binding; multihoming, ASN transfer, and cross-ASN anycast remain possible through multi-address semantics defined in Sections 8, 11, and 14. This structure is intended to reduce operational friction during transition (familiar dotted-decimal notation, clean aggregation at the ASN boundary) rather than to achieve wire-level IPv4 compatibility. This document specifies the core protocol: address format, packet header, address classes, routing behavior, transition mechanisms, and security considerations. The Zone Server reference architecture (Section 16) is Informative and non-normative. The Cost Factor routing metric (Section 17) is OPTIONAL and is specified in a separate companion document (draft-asip-cf-00); Section 17 of this document is a one-paragraph forward reference. Interplanetary realm reservations (Section 3.12) are reserved allocations only; delay- tolerant transport is out of scope for this document. Operators MAY deploy ASIP addressing without any of the above. This specification extends the ASN-locator addressing model of [I-D.thain-ipv8] to a 128-bit four-field address format; see Section 1.3 for the relationship between the two proposals. | |||||||||||||
| draft-havel-nmop-simap-yang-03.txt | ||||||||||||||
| A YANG Data Model for SIMAP | ||||||||||||||
|
This document defines a YANG data model for Service & Infrastructure Maps (SIMAP). It extends the RFC8345 YANG modules to support all SIMAP requirements. This document will only focus on modelling proposal for each of the requirements not supported by RFC8345. Any related terminology, concepts, use cases and requirements are defined outside of this draft and this draft will only refer to them, analyze how to model and propose the implementation solutions. | |||||||||||||
| draft-hawkins-scitt-attested-agent-payment-02.txt | ||||||||||||||
| Notice of Discontinuation: Attested Agent Payment | ||||||||||||||
|
This document serves as formal administrative notification that the individual Internet-Draft draft-hawkins-scitt-attested-agent-payment has been discontinued and will not be progressed as an individual submission. | |||||||||||||
| draft-hawkins-x402-dns-discovery-03.txt | ||||||||||||||
| Discovering x402 Payment Capability via DNS and a Well-Known URI | ||||||||||||||
|
x402 is an application-level protocol for internet-native payments built on the HTTP 402 (Payment Required) status code. This document defines how a domain publishes its x402 payment capability out-of- band, so that clients, autonomous agents, and indexers can discover it without prior configuration or a central directory. It specifies a JSON capability manifest served at the well-known URI "/.well- known/x402" and an optional DNS TXT record at the underscored node name "_x402" that points to the manifest. A consumer resolves a bare domain name to verified x402 capability with at most one DNS query and one HTTPS GET. | |||||||||||||
| draft-haynes-nfsv4-flexfiles-v2-08.txt | ||||||||||||||
| Parallel NFS (pNFS) Flexible File Layout Version 2 | ||||||||||||||
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Flexible File Version 2 Layout Type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Data protection is also added to provide integrity. Both Client-side mirroring and the erasure coding algorithms are used for data protection. | |||||||||||||
| draft-haynes-nfsv4-flexfiles-v2-delta-writes-00.txt | ||||||||||||||
| Delta-Write Extension for the Flexible File Version 2 Layout Type | ||||||||||||||
|
The Flexible File Version 2 pNFS layout type defines a chunk-oriented data-server protocol in which every write is a full-chunk payload. For workloads that make small edits to files protected by an XOR- based erasure encoding, this forces client-side stripe fetch, re- encode, and transmit on every edit, with wire amplification of three to four orders of magnitude per byte edited. This document defines an optional extension, CHUNK_XOR_DELTA, that lets a client transmit a per-projection XOR delta directly to each data server holding a projection of the affected stripe; the data server applies the delta locally. The extension is restricted to XOR-linear systematic encodings and XOR-affine checksums, using the existing chunk state machine with no new commit protocol. | |||||||||||||
| draft-haynes-nfsv4-flexfiles-v2-proxy-server-04.txt | ||||||||||||||
| Proxy-Driven Server for Flexible Files Version 2 | ||||||||||||||
|
Parallel NFS (pNFS) with the Flexible Files Version 2 layout type supports client-side erasure coding and per-chunk repair between clients and data servers. This document extends that architecture with a proxy server role: a registered peer of the metadata server that polls the metadata server for work assignments and carries them out -- moving a file from one layout to another, reconstructing a whole file from surviving shards, or translating between encodings for clients that cannot participate in the file's native encoding (including NFSv3 clients). All proxy-server-to-metadata-server coordination is fore-channel: the metadata server returns work assignments inline in the response to a proxy-server-initiated PROXY_PROGRESS poll, and the proxy server reports completion via a fore-channel PROXY_DONE. No callback operations are required for the proxy server protocol. | |||||||||||||
| draft-haynes-nfsv4-recalldevice-02.txt | ||||||||||||||
| Deviceid-Scoped Layout Recall for NFSv4.2 | ||||||||||||||
|
The Parallel Network File System (pNFS) allows the metadata server to recall a layout from a client by file id, by file system id, or across all of a client's layouts. It also lets the server delete a deviceid via CB_NOTIFY_DEVICEID. It does not provide a mechanism for the metadata server to recall, in a single operation, all layouts that reference a specific deviceid. This document presents an extension to RFC7862 that adds a deviceid-scoped layout recall: a single CB_LAYOUTRECALL operation recalls every layout a client holds that references a given deviceid, leaving unrelated layouts in place. Without this capability, device unavailability can trigger large volumes of failed WRITE and LAYOUTERROR traffic, and administrators lack a surgical way to retire a deviceid without disturbing layouts that reference healthy devices. | |||||||||||||
| draft-haynes-nfsv4-swap-07.txt | ||||||||||||||
| Adding an Atomic EXCHANGE_RANGE Operation to NFSv4.2 | ||||||||||||||
|
The Network File System version 4.2 (NFSv4.2) does not provide support for atomic multi-block updates to file data. This document introduces a new EXCHANGE_RANGE operation which provides for such atomic updates. This document extends NFSv4.2 (see RFC7862). | |||||||||||||
| draft-he-dawn-ipv6-agent-aware-framework-00.txt | ||||||||||||||
| Agent-Awareness in IPv6 Networks: Problem Statement and Framework | ||||||||||||||
|
The Internet of Agents (IoA) raises a question beyond IPv6 address space and end-to-end connectivity: should an IPv6 network be able to relate packet forwarding to agent capability, policy, and short-lived execution state? This informational document states the problem, sketches a framework for agent-aware IPv6 forwarding, and lists open questions for community discussion. It does not define packet formats, routing extensions, IANA allocations, or a new agent discovery protocol. | |||||||||||||
| draft-he-idr-bgp-ec-sr-pm-00.txt | ||||||||||||||
| BGP Extended Communities for SR Policy Performance Metrics | ||||||||||||||
|
Traffic scheduling and optimization have become routine network operation and maintenance tasks for operators. The operators need to select a path that can meet the Qality of Service (QoS) reqiurements of the traffic to be scheduled. This document defines four BGP extended communities for Segment Routing (SR) candidate path performance metric: the Available Bandwidth Extended Community, the Unidirectional Delay Extended Community, the Unidirectional Delay Variation Extended Community and the Unidirectional Loss Extended Community, which carry SR Policy candidate path performance parameters for the operators to select a preferred path for traffic scheduling and optimization. It also specifies the format and processing rules for these extended community types. | |||||||||||||
| draft-he-idr-bgp-flowspec-ifit-04.txt | ||||||||||||||
| BGP Extensions to Enable BGP FlowSpec based IFIT | ||||||||||||||
|
Border Gateway Protocol (BGP) Flow Specification (FlowSpec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. In-situ Flow Information Telemetry (IFIT) denotes a family of flow-oriented on-path telemetry techniques, which can provide high-precision flow insight and real-time network issue notification. This document defines BGP extensions to distribute BGP FlowSpec based traffic filtering carrying IFIT information. Therefore, IFIT behavior can be automatically applied to the matched flow to capture real-time network dynamics. | |||||||||||||
| draft-he-idr-bgpls-sr-policy-pm-00.txt | ||||||||||||||
| Advertisement of SR Policy Performance Metrics Using BGP-LS | ||||||||||||||
|
This document defines several Type-Length-Values (TLVs) to advertise the performance metrics for Segment Routing (SR) Policy using BGP Link State (BGP-LS). It complements RFC9857 for the advertisement of SR Policy performance metrics. Such information can be used by the operators for monitoring the performance and state of the candidate path . | |||||||||||||
| draft-he-ippm-congestion-loss-monitoring-arch-00.txt | ||||||||||||||
| An Architectural Framework for Monitoring Packet Loss Caused by Network Congestion | ||||||||||||||
|
Network congestion can lead to performance degradation and increase uncertainty in service delivery, so real-time congestion monitoring is necessary. This document describes a comprehensive packet loss monitoring architectural framework. The proposed scheme is capable to not only determine the time and location of packet loss occurrence, make the accurate statistics of discarded packets, parse what traffic flows are contained in discarded packets and identify what traffic flows lead to microburst, but also obtain accurate packet loss ratio results. More importantly, the proposed scheme can achieve little or even no interference to network, and is applicable to any data plane without modifying the forwarding chip and packet header as existing measurement methods do. | |||||||||||||
| draft-he-ippm-congestion-loss-monitoring-problem-00.txt | ||||||||||||||
| Requirements and Problem Statement for Monitoring Packet Loss Caused by Network Congestion | ||||||||||||||
|
Emerging services including enhanced Mobile Broadband (eMBB) and Ultra-Reliable Low Latency Communication (uRLLC), as well as Artificial Intelligence (AI)training and inference have imposed stringent requirements of "high throughput, low latency, and minimal packet loss" on IP bearer network performance. Network congestion can lead to performance degradation and increase uncertainty in service delivery, so real-time congestion monitoring is necessary. This document discuss the requirements of real-time monitoring of packet loss caused by congestion, present the problems and challenges faced by existing measurement techniques in monitoring congestion- induced packet loss. | |||||||||||||
| draft-he-ippm-ioam-dex-extensions-incorporating-am-05.txt | ||||||||||||||
| IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method | ||||||||||||||
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, passport-based IOAM allows telemetry data generated by each node along the path to be pushed into data packets when they traverse the network, while postcard-based IOAM allows IOAM data generated by each node to be directly exported without being pushed into in-flight data packets. The Alternate-Marking method is used to measure performance metrics on live traffic, such as packet loss, delay, and jitter. This document extends IOAM Direct Export (DEX) Option-Type to integrate the Alternate-Marking Method into IOAM to augment IOAM in performance measurement. | |||||||||||||
| draft-he-ippm-ioam-extensions-incorporating-am-07.txt | ||||||||||||||
| IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method | ||||||||||||||
|
In situ Operation, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information, which leverages IOAM Trace Option to incorporate IOAM data fields into in- flight data packets. The Alternate-Marking method is used to measure performance metrics on live traffic, such as packet loss, delay, and jitter. This document extends IOAM Trace Option for incorporating the Alternate-Marking method to augment IOAM in performance measurement. | |||||||||||||
| draft-he-ippm-ioam-trace-type-bandwidth-01.txt | ||||||||||||||
| IOAM Trace-Type Extensions for Path bandwidth | ||||||||||||||
|
Traffic scheduling and optimization have become routine network operation and maintenance tasks for operators. The operators need to select a path that can accommodate the capacity of the traffic to be scheduled. In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. This document defines two bit flags within IOAM Trace- Type for carrying bandwidth information. | |||||||||||||
| draft-he-rtgwg-wan-fcn-00.txt | ||||||||||||||
| Fast Congestion Notification (FCN) in Wide Area Network (WAN) Interconnecting RoCEv2 Networks | ||||||||||||||
|
Wide Area Network (WAN), when interconnecting RoCEv2 networks, needs to meet the performance requirements of "high throughput, low latency, and minimal packet loss". This document describes a solution to Fast Congestion Notification (FCN) in WAN interconnecting RoCEv2 networks, especially applicable to tunnel encapsulation. | |||||||||||||
| draft-he-rtgwg-wan-pfc-01.txt | ||||||||||||||
| PFC PAUSE Frame Forwarded Transparently in Wide Area Networks | ||||||||||||||
|
This document describes a solution for transparent forwarding of PFC PAUSE frames in wide area networks, which does not require the nodes in wide area networks to support PFC flow control capabilities. | |||||||||||||
| draft-hebbar-hiremani-scswp-01.txt | ||||||||||||||
| Secure Collaborative State Workspace Protocol (SCSWP) | ||||||||||||||
|
This document specifies the Secure Collaborative State Workspace Protocol (SCSWP), a stateful, continuously authenticated protocol that enables multiple clients, operating from heterogeneous networks, to securely access and collaboratively manage a shared file workspace hosted on a central authoritative server. SCSWP defines a complete protocol lifecycle encompassing client provisioning via a Key-Dissolving bootstrap mechanism, mutual X.509 certificate-based identity authentication, ephemeral Elliptic-Curve Diffie-Hellman (ECDH) key exchange producing a three-level cryptographic key hierarchy (K1, K2, K3), continuous Dynamic Network and Access (D/N/P/S) trust evaluation, per-client capability-based authorization, workspace-aware congestion control with a dynamic worker-pool scheduler, concurrent file-operation management via mutual exclusion locks and optimistic version control, idempotent operation execution, a hash-chained audit ledger, and session continuity and recovery through the Dynamic Network and Access Continuity (DNAC) mechanism. The fundamental security principle of SCSWP is that client trust is not established permanently at login time. Instead, identity, device state, network context, session state, authorization state, resource state, and workspace state are evaluated continuously and cryptographically throughout the full lifetime of every connection. | |||||||||||||
| draft-hebbar-zeropath-vpn-protocol-01.txt | ||||||||||||||
| ZeroPath VPN: Hop-Bound Secure Packet Validation with State-Bound Ephemeral Sessions,Cryptographic Attestation,and Opcode-Driven Control Architecture | ||||||||||||||
|
This document specifies the complete ZeroPath VPN protocol suite, comprising three coordinated sub-protocols: HBSPV (Hop-Bound Secure Packet Validation) -- a three-domain packet framing model that isolates payload decryption to the authorized egress node while allowing intermediate hops to validate forwarding context without accessing payload content. SGCP (State Graph Cryptographic Protocol) -- a three-message cryptographically attested handshake enforcing mutual authentication and device posture verification before any session is established. SCSWP (Secure Cryptographic Session Workspace Protocol) -- a continuous session state mechanism providing tamper-evident hash chain continuity, epoch-bound forward secrecy, and four-dimensional trust scoring across the full session lifetime. This document additionally specifies a complete opcode architecture governing all control-plane and data-plane message types, providing a machine-parseable, extensible message dispatch framework. The protocol suite is implemented as a pure Python reference implementation at https://github.com/sripad2020/Zeropath-vpn. | |||||||||||||
| draft-hegde-lsr-isis-osnc-00.txt | ||||||||||||||
| IS-IS Originator Sequence Number Checksum TLV | ||||||||||||||
|
This document introduces a new top-level TLV in IS-IS to carry a checksum over the LSP IDs and sequence numbers of all self-originated LSP fragments. A receiving node uses this value to validate the integrity of the originator's Link State Database (LSDB). | |||||||||||||
| draft-helixar-hdp-agentic-delegation-02.txt | ||||||||||||||
| Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems | ||||||||||||||
|
Agentic AI systems operate on behalf of human principals, often delegating tasks through multi-step chains of AI agents. There is currently no standard mechanism to record who authorized an agent to act, under what scope, and through what chain of delegation, in a way that can be verified offline, without a central registry, and without third-party trust anchors. This document specifies the Human Delegation Provenance Protocol (HDP) version 0.1, a lightweight token-based protocol that captures, structures, cryptographically signs, and verifies human delegation context in agentic AI systems. An HDP token binds a human authorization event to a session, records each agent's delegation action as a signed hop in an append-only chain, and enables any participant to verify the full provenance record using only the issuer's Ed25519 public key and the current session identifier. Verification is fully offline. No registry lookup, no network call, and no third-party trust anchor is required. HDP's distinguishing contribution is a signed, tamper-evident record of each agent's declared action at each hop, an execution audit trail that complements, rather than replaces, capability-based delegation formats such as UCAN and ZCAP-LD. The underlying append-only, offline-verifiable chain-of-custody mechanism is payload-agnostic; human-authorized agentic delegation is the reference profile specified in this document. HDP is not an authorization protocol. An HDP token confers no authority and its presentation entitles the presenter to nothing. It is a record of who authorized a task and of what each agent declared it did with that authorization, carried with the task and read at audit. | |||||||||||||
| draft-helmprotocol-tttps-09.txt | ||||||||||||||
| The TLS TimeToken Secure Protocol (tttps://) | ||||||||||||||
|
This document specifies the TLS TimeToken Secure Protocol (tttps://), a protocol extension that augments TLS 1.3 with cryptographically verifiable temporal ordering. TTTPS introduces Proof-of-Time (PoT): a multi-source synthesised timestamp bound to a holder identity and to a live TLS session through an explicit holder-proof construction, verified in constant time independent of network size. Internet infrastructure conventionally assumes ordering-neutral channels. NTP servers, BGP routing authorities, DNS resolvers, and transaction sequencers all have an operational incentive to misrepresent event ordering; this document formalises that condition as the Strategic Channel Controller Problem (SCCP). PoT detects Byzantine time-source manipulation with probability at least 1 minus 2 to the negative 61st power, and an AdaptiveSwitch mechanism makes sustained ordering manipulation economically self-defeating; the equilibrium threshold is derived in closed form and empirically calibrated from deployed auction data. This document has Experimental status. A reference deployment has produced over 70,000 verified records, 55 percent of which were generated by autonomous AI agents. The mandatory-to-implement integrity mode (SHA-256) is completely and publicly specified in Appendix B; the optional high-assurance integrity mode (GRG) remains subject to pending patent proceedings and is specified only at the abstract-interface level pending their conclusion. Discussion Note This note is to be removed before publishing as an RFC. This document is being discussed on the [email protected] mailing list. Comments and participation are welcome. Changes from -06: * Header: revision -06 -> -07; submissionType corrected from "IETF" to "independent" (this document is an Independent Submission, not an IETF Working Group product); dates updated. * Section 2 / Section 6.1 (the former binding_key construction): the -06 construction let any participant in the TLS session -- including an attacker in its own session with the Issuer -- recompute binding_key and pass verification without proving possession of any holder key material, because binding_key was derived solely from public TLS Exporter output and the public PoT bytes. This is replaced with a PoT Record v2 (180 octets) carrying an explicit holder_auth_type (Ed25519 public key, MTI, or a pre-shared secret, OPTIONAL) and a binding_proof computed by the holder over the TLS Exporter output at binding time. Verification now performs integrity-tag interpretation first, in a single fixed-cost pass with a three-way intact/resolved/unresolvable verdict; in -06 the equivalent check was ordered after five other checks. The full 8-step order is specified in Section 2.5. * Appendix B: removed the "(Placeholder)" designation. Appendix B now specifies a public Integrity Algorithm Registry: alg_id 0x0001 (SHA-256, detection-only) is the Mandatory-to-Implement algorithm and is completely and publicly specified, free of any licensing condition. alg_id 0x0100 (GRG, detection-and-correction) remains OPTIONAL and interface-only pending conclusion of the patent proceedings referenced in Section 12. * IANA Considerations, HTTP/3 Stream Types: renamed from "HTTP/3 and QUIC Stream Types". The "QUIC Stream Types" registry entry is removed; no such IANA registry exists, and QUIC stream identification for TTTPS is carried entirely by the HTTP/3-layer frame registration. * Abstract: shortened from six paragraphs to three; removed inline document citations (an abstract is conventionally self-contained and does not carry bracketed references). * Scope reduced to the core protocol: satellite communication, SS7 legacy infrastructure, 5G/6G core network ordering, and deep- space/SAGIN deployment material are removed from this revision as out of scope; see 3GPP and CCSDS/TIPTOP for domain-specific profiles. The former Appendix E (a regulated therapeutic-design motivating scenario) is removed as non-normative and out of scope for a protocol specification. * Sections 1 through 4 of -06 (Introduction, Use Cases, Requirements Language, Problem Statement) are consolidated into a single Section 1, removing a duplicated BCP 14 paragraph and shortening the document. * The former Section 4.3 (Shannon Gap / SCCP) and Section 7.4 (V* equilibrium) are shortened; the full economic and information- theoretic derivations remain in the companion paper [POT2026], which this document now points to rather than reproduces. * IANA Time Source Type Registry: named operators (NIST, Google, Cloudflare, Apple) are replaced with source classes (national metrology laboratory, GNSS-disciplined, Roughtime-authenticated, NTS-authenticated, PTP grandmaster); the same replacement is applied to the worked examples in Sections 1.3, 2.2, and 7.1. This document does not depend on, or endorse, any specific named operator. * References [RFC8915], [RFC5705], and [RFC8126] are unchanged from -06. Changes from -02 through -05 (compressed; see prior revisions of this draft for the full itemised changelog): -03 added Use Cases, the SS7/ SCCP instance analysis, path manipulation scenarios, the trust model, and the Implementation Status section (RFC 7942). -04 added the Formal Verification Artifacts subsection and the former Appendix E. -05 is not separately archived. -06 added Oracle Confidence Gating (the G-Score), corrected IPR licensing language per ISE guidance, and recorded the provisional "tttps" URI scheme registration. | |||||||||||||
| draft-henlich-imdf-00.txt | ||||||||||||||
| Internet Month-Name Date Format (IMDF) | ||||||||||||||
|
This document defines the Internet Month-Name Date Format (IMDF), a concise date representation for English-language human communication. IMDF requires an alphabetic month abbreviation. This makes the month visually distinct from the numeric day and reduces errors caused by differing regional date-order conventions. The specification primarily defines how IMDF dates are presented. It establishes a preferred output form and permits a limited set of familiar English-language variants. Detailed input handling is outside its scope. IMDF does not replace ISO 8601 for machine interchange, language- neutral communication, chronological sorting, or timestamps. | |||||||||||||
| draft-herdes-idr-otc-rs-verification-00.txt | ||||||||||||||
| Strict Only to Customer (OTC) Verification on Route Server Sessions | ||||||||||||||
|
RFC 9234 specifies how an AS receiving a route from a lateral Peer can check if route was lekaed, but doesn't specify any checks for routes received from Route Server (RS). This makes quility of filtering dependent on whether the RS implements RFC 9234. This document updates RFC 9234 by adding complimentary ingress check by RS-Client. | |||||||||||||
| draft-herman-did-w3c-drn-00.txt | ||||||||||||||
| Decentralized Resource Name (DRN) DID Method | ||||||||||||||
|
This document specifies the did:drn Decentralized Identifier (DID) method, which defines a deterministic mapping from Uniform Resource Names (URNs) (RFC 8141) into a DID-compatible identifier format called a Decentralized Resource Name (DRN). The did:drn method preserves URN semantics, enables DID resolution without mandatory centralized infrastructure, and provides optional cryptographic and service-layer extensibility. The method is fully compatible with the W3C DID Core specification (W3C DID Core, 2022) and the broader DID ecosystem. | |||||||||||||
| draft-herman-did-web7-urn-00.txt | ||||||||||||||
| Decentralized Universal Resource Name (URN) DID Method (Web 7.0) | ||||||||||||||
|
This document specifies the did7:web7 Decentralized Identifier (DID) method, which defines a deterministic mapping from Uniform Resource Names (URNs) (RFC 8141) into a DID-compatible identifier format called a Decentralized Universal Resource Name (URN). The did7:web7 method preserves URN semantics, enables DID resolution without mandatory centralized infrastructure, and provides optional cryptographic and service-layer extensibility. The method is fully compatible with the W3C DID Core specification (W3C DID Core, 2022) and the broader DID ecosystem. | |||||||||||||
| draft-herman-did7-identifier-00.txt | ||||||||||||||
| DID7: Authority-Scoped Decentralized Identifier Scheme | ||||||||||||||
|
This document defines the "did7" URI scheme, an authority-scoped decentralized identifier format. DID7 introduces an optional authority component and a two-stage resolution process, while remaining fully compatible with the W3C Decentralized Identifiers (DIDs) v1.0 specification (DID Core). | |||||||||||||
| draft-herman-vtc-proof-sets-01.txt | ||||||||||||||
| Verifiable Trust Circles (VTCs) using VC Proof Sets | ||||||||||||||
|
This document specifies Web 7.0 Verifiable Trust Circles (VTCs), a generalized mechanism for expressing verifiable multi-party membership, belonging, and trust relationships using the W3C Verifiable Credentials (VC) Data Model 2.0 [W3C.VC-DATA-MODEL] and VC Data Integrity Proof Sets [W3C.VC-DATA-INTEGRITY]. VTCs extend the Partof Architecture Reference Model (PARM) to provide a universal credential pattern that subsumes prior pairwise constructs (Personhood Credentials (PHCs) and Verifiable Relationship Credentials (VRCs)) and additionally supports voting-based decision making, meeting requests, task forces, and digital societies. | |||||||||||||
| draft-herz-moq-nmsf-01.txt | ||||||||||||||
| NMSF - Neural Video Codec Packaging for MOQT Streaming Format | ||||||||||||||
|
This document updates the MOQT Streaming Format (MSF) by defining a new optional feature for the streaming format. It specifies the syntax and semantics for adding Neural Video Codec (NVC) packaged media to MSF. NVC codecs use learned neural network transforms for video compression, and their bitstreams require a distinct packaging model from traditional block-based codecs. NMSF maps neural keyframes (Intra) and delta frames (Inter) onto MoQ Groups and Objects, and introduces a multi-track model that separates hyperprior side information from latent bitstreams for priority-aware delivery. This enables real-time neural video streaming over any standard MoQ relay. | |||||||||||||
| draft-hezami-pulseproof-sentinel-00.txt | ||||||||||||||
| PulseProof Sentinel Protocol Specification | ||||||||||||||
|
This document specifies the PulseProof Sentinel Protocol (PPS), an experimental, technology-agnostic protocol for time-bound asymmetric authentication proofs. PPS is not a new cryptographic primitive; it profiles established mechanisms -- Ed25519 signatures, SHA-256 hashing, HKDF key derivation, and deterministic CBOR encoding -- into a compact, interoperable verification model suited to offline, embedded, and non-browser environments where a full WebAuthn ceremony is unavailable. A PPS authentication event produces a Pulse: a signed statement bound to a relying-party identifier, time epoch, monotonic counter, expiration, and optional nonce, context, policy, and transaction data. Because the verifier stores only public keys, PPS removes the shared-secret exposure problem inherent in TOTP. PulseProof Sentinel extends the basic Pulse model with several optional but interoperable security extensions: | |||||||||||||
| draft-hi-ccamp-cmis-control-yang-04.txt | ||||||||||||||
| A YANG Data Model for CMIS Access and Control | ||||||||||||||
|
This document provides YANG data models for accessing and controlling CMIS in order to manage pluggable Digital Coherent Optics transceivers equipped in a router or a switch from outside the platform device. CMIS provides custom pages that can be defined by the module vendor for its own usage, allowing the capabilities of the optics devices to be extended. These YANG modules also allow the utilization of CMIS custom pages as a generic control mechanism. The models complement abstracted data models for coherent pluggables: they provide governed access to opaque, vendor-specific attributes (e.g., those exposed via CMIS custom pages) and a transitional path for standardized features that the host NOS does not yet support. | |||||||||||||
| draft-hillier-certisyn-ai-governance-verified-02.txt | ||||||||||||||
| AI Governance Verified -- A Cryptographic Verification Standard for Agentic AI Governance in Regulated Industries | ||||||||||||||
|
This document specifies a verification standard for the cryptographic attestation of agentic AI governance in regulated industries. It defines the Verification Reconciliation Object (VRO), the issuing- partner framework, the eight control areas through which AI governance posture is reconciled, three maturity-attestation levels (Documented, Operational, Adversarial-ready), and the cryptographic continuity requirements that together produce deterministic, independently reconstructable, auditor-grade attestations of agentic AI governance. The standard sits beneath ISO/IEC 42001:2023, the NIST AI Risk Management Framework, and other agentic AI governance frameworks, and produces the verifiable artefact those frameworks were designed to imply but do not deliver. | |||||||||||||
| draft-hillier-certisyn-essential-eight-verified-02.txt | ||||||||||||||
| Essential Eight Verified -- A Cryptographic Verification Standard for the ACSC Essential Eight Maturity Model | ||||||||||||||
|
This document specifies a verification standard for the cryptographic attestation of conformance to the Australian Cyber Security Centre (ACSC) Essential Eight Maturity Model. It defines the Verification Reconciliation Object (VRO), the issuing-partner framework, the evidence categories required for each of the eight controls of the Essential Eight, the three maturity-attestation levels, and the cryptographic continuity requirements that together produce deterministic, independently reconstructable, auditor-grade attestations of cybersecurity posture. The standard sits beneath the ACSC Essential Eight Maturity Model and produces the verifiable artefact the model was designed to imply but does not deliver. | |||||||||||||
| draft-hillier-coverage-attestation-00.txt | ||||||||||||||
| The Coverage Attestation Profile (CAP-1) | ||||||||||||||
|
A report can be complete and still silent about its own scope. A statement that something was not observed is routinely recorded in a form that reads as a claim about the world, when what was established was a claim about a bounded population examined to a stated depth. Nothing in the record distinguishes the two, and no relying party can recover the difference after the fact. This document specifies the Coverage Attestation Profile, CAP-1: a tool-agnostic vocabulary for stating what an examination examined, what it did not, and why. A conforming document declares one or more populations, a denominator for each whose basis is itself declared, and an individual accounting for every unit that was not examined, drawn from a closed set of dispositions. A remainder that reconciles only by arithmetic is refused. The construct is not novel outside this application. Coverage accounting with a declared denominator is settled practice in configuration assessment and in vulnerability scanning, and this document states that relationship in Section 1.2 before making any claim of its own. | |||||||||||||
| draft-hillier-scitt-arp-04.txt | ||||||||||||||
| Attestation Reconciliation Protocol | ||||||||||||||
|
This document specifies the Attestation Reconciliation Protocol (ARP), a deterministic, bilateral, minimum-disclosure mechanism for reconciling verification claims against a plurality of sovereign authoritative registers without raw register records leaving their data-residency jurisdiction. ARP extends the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture to cross-sovereign claim reconciliation. A reconciliation server canonicalises a structured claim, binds the identity of the requesting principal -- including, where the requester is an autonomous agent, a friend-or- foe determination of that agent's verifiable principal binding -- projects the claim through register-specific controlled projection functions producing the nearest permitted ancestor predicate supported by each addressed register, transmits register-specific ciphertexts, receives partial attestations whose payload discloses, of the subject, only a verdict, an optional divergence axis, the applied profile parameters and a query binding digest, aggregates those attestations under a verdict arithmetic the deployment's policy resolves, committing each register's contribution to a Merkle tree, and seals the resulting reconciliation output against a policy- version hash. An append-only cross-jurisdictional settlement-layer ledger records digests and structural metadata, with no claim, register-record or principal content. The protocol supports retroactive re-evaluation of historical reconciliations under updated pattern libraries or policy versions without bilateral renegotiation, and a cryptographic-primitive-upgrade path including post-quantum primitives. This revision adds a normative binding to the SCITT Reference APIs, register data-format profiles for beneficial- ownership, corporate-registry, customs and consolidated-sanctions formats, and a source-data version binding that makes a change in a historical verdict attributable to a change in policy or to a change in the underlying published corpus. | |||||||||||||
| draft-hko-openpgp-identifiers-for-legacy-devices-03.txt | ||||||||||||||
| OpenPGP key identifiers for legacy hardware devices | ||||||||||||||
|
This document describes an approach for storing a fingerprint-based identifier for an OpenPGP key packet on a hardware security device that has a size-constrained identifier field. | |||||||||||||
| draft-hoehlhubmer-https-addon-07.txt | ||||||||||||||
| Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol | ||||||||||||||
|
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations. | |||||||||||||
| draft-hoehrmann-cp-collation-01.txt | ||||||||||||||
| The i;codepoint collation | ||||||||||||||
|
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. | |||||||||||||
| draft-hoffman-deleg-secure-transports-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hoffman-duj-05.txt | ||||||||||||||
| DNS Update with JSON | ||||||||||||||
|
It is common for service providers such as certificate authorities and social media providers to want users to update the users' zones to prove that they control those zones, or to add other features. Currently, service providers tell users to do this using human language describing the resource record type and data values to enter into the zone. This document describes a text format, called "DNS update with JSON" or "DUJ", for such a service provider to give to a user, with the expectation that the user would copy and paste the text to their DNS operator to update the user's zone. DNS operators who know how to handle DUJ strings will make the update process easier and more predictable for their users. | |||||||||||||
| draft-hoffman-pq-dnssec-considerations-00.txt | ||||||||||||||
| Considerations for Selecting Post-Quantum Algorithms for DNSSEC | ||||||||||||||
|
This draft lists many of the considerations that the DNS community needs to balance when it is deciding which post-quantum algorithms to standardize for DNSSEC. This draft is definitely not meant to become an RFC. | |||||||||||||
| draft-hoffman-rootcache-02.txt | ||||||||||||||
| RootCache: Filling Resolver Caches with Root Zone Records | ||||||||||||||
|
Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. Resolvers can reduce the number of queries sent to root server, and thus prevent observation of requests, by caching a copy of the full root zone. This document shows how a resolver can securely receive the full root zone and put it into the resolver's cache. This document obsoletes RFC 8806. | |||||||||||||
| draft-hoffman-variable-length-nonparticipating-00.txt | ||||||||||||||
| Variable Length DNSKEY and RRSIG Types For Testing | ||||||||||||||
|
Some DNS operators want to test what will happen when DNSSEC algorithms that have large DNSKEY records, RRSIG records, or both, are deployed. For example, they may want to see the effects on TCP retries due to large DNSSEC records. This document defines a new DNS security algorithm, named "Variable Length Nonparticipating", for such testing. To prevent possible security issues with this new algorithm, signatures with this algorithm never participate in DNSSEC validation. This document might never become an RFC; it's purpose is just to register the new algorithm in the IANA "DNS Security Algorithm Numbers" registry. | |||||||||||||
| draft-hoflev-secure-smtp-01.txt | ||||||||||||||
| Secure SMTP | ||||||||||||||
|
SMTP [RFC5321] uses opportunistic TLS to optionally protect transport sessions. Secure SMTP uses mandatory TLS on all connections. It also provides a method for SMTP clients to locate Secure SMTP servers. | |||||||||||||
| draft-hohendorf-secure-sctp-42.txt | ||||||||||||||
| Secure SCTP | ||||||||||||||
|
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP, it is designed to integrate cryptographic functions into SCTP. | |||||||||||||
| draft-holmgren-at-repository-02.txt | ||||||||||||||
| Authenticated Transfer: Repository | ||||||||||||||
|
This document specifies a repository data structure for storage and transfer of public user data records as part of the Authenticated Transfer Protocol (ATP). It describes encoding formats for both individual data records and entire repositories. The repository data structure is content-addressable and cryptographically authenticated. | |||||||||||||
| draft-holmgren-at-synchronization-00.txt | ||||||||||||||
| Authenticated Transfer: Synchronization | ||||||||||||||
|
This document describes synchronization mechanisms for public repositories as part of the Authenticated Transfer Protocol (ATP). It specifies both a low-latency streaming protocol over WebSocket, and a full-repository fetch mechanism over HTTP. | |||||||||||||
| draft-homburg-dnsop-dettl-00.txt | ||||||||||||||
| Add TTLs to DNS errors | ||||||||||||||
|
When a DNS server replies an error other than NXDOMAIN, there is no mechanism to specify how long this error can be cached by the recepient. This document introduces a mechanism where a server can specify the time to live (TTL) of an error by adding a SOA record to the additional section of a reply. Clients can use this TTL at their discretion. In particular, clients can limit the TTL to a maximum value, impose a minimum value or just ignore the TTL value all together. | |||||||||||||
| draft-hong-nmrg-agenticai-ps-02.txt | ||||||||||||||
| Motivations and Problem Statement of Agentic AI for network management | ||||||||||||||
|
This document outlines the key objectives of introducing Agentic AI to the field of network management and highlights the fundamental issues with existing technologies that must be addressed to achieve these goals. It emphasizes the necessity for relevant groups within the IETF/IRTF and presents the core technological areas requiring standardization. The aim of Agentic AI is to facilitate a paradigm shift in which multiple autonomous AI agents collaborate to fully automate network operation, management and security. | |||||||||||||
| draft-hong-nmrg-rea-ps-00.txt | ||||||||||||||
| Problem statements and Challenges of Internet for Physical AI : REA | ||||||||||||||
|
As autonomous agents and physical AI increasingly translate digital requests into physical execution, existing Internet trust mechanisms assure integrity within the digital domain but cannot verify whether execution conforms to physical reality. This document defines this problem space as Reality Execution Assurance (REA), extending the evidence-appraisal-result structure of RATS and SCITT to identify key gaps between digital declaration and physical execution and to outline design requirements for assurance results consumable by relying systems. This document is a problem statement and does not define a protocol. | |||||||||||||
| draft-hood-agtp-agent-cert-03.txt | ||||||||||||||
| AGTP Agent Certificate Extension | ||||||||||||||
|
The Agent Transfer Protocol (AGTP) base specification defines agent identity headers (Agent-ID, Owner-ID, Authority-Scope) that are self- asserted: present on every request and mandatory for logging, but not cryptographically verified at the transport layer. This document specifies the AGTP Agent Certificate Extension: an optional mechanism that binds Agent-ID, Owner-ID, and Authority-Scope to an X.509 v3 certificate presented during TLS mutual authentication. The extension enables infrastructure components including Scope- Enforcement Points (SEPs), load balancers, and governance gateways to verify agent identity and enforce authority scope without application-layer access, at O(1) cost per request header check. The extension also defines session-level revocation propagation via AGTP NOTIFY broadcast and a Certificate Transparency Log for tamper- evident governance metadata. Note: Certain mechanisms described in this document may be subject to pending patent applications by the author. The licensor is prepared to grant a royalty-free license to implementers consistent with the IETF's IPR framework. See the IPR Notice and Section 7. | |||||||||||||
| draft-hood-agtp-api-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hood-agtp-ard-00.txt | ||||||||||||||
| ARD Binding for AGTP: Agentic Resource Discovery over the Agent Transfer Protocol | ||||||||||||||
|
The Agentic Resource Discovery (ARD) specification defines a federated, domain-anchored model for cataloging, discovering, and searching agentic resources across organizational boundaries. ARD is artifact-protocol-agnostic: it advertises capabilities and trust metadata, then steps out of the way to let agents connect over each artifact's native protocol. This document specifies how the Agent Transfer Protocol (AGTP) composes with ARD. It defines an AGTP catalog entry type for ARD manifests, the agtp:// endpoint URI as a valid runtime connection target, the composition of AGTP's wire-level identity model with the ARD trustManifest object, and an AGTP-native binding for publishing and consuming ARD catalogs over the AGTP substrate rather than HTTPS. The result is a clean composition. ARD operates at the application layer and answers the discovery question: where is the capability, can it be trusted before connection. AGTP operates at the transport substrate beneath application-layer protocols (MCP, A2A, API, and others ARD catalogs) and carries structural identity, authority scope, and attribution at the wire. ARD and the application protocols it catalogs can run over AGTP as substrate, the same way they currently run over HTTP. | |||||||||||||
| draft-hood-agtp-bindings-00.txt | ||||||||||||||
| AGTP Transport Bindings: TCP/TLS and QUIC | ||||||||||||||
|
The Agent Transfer Protocol (AGTP) base specification defines AGTP semantics independently of any specific transport. This document specifies the AGTP transport bindings for TCP with TLS 1.3 and for QUIC, defining how AGTP requests and responses are carried over each transport, how TLS mutual authentication composes with AGTP identity, and how connection lifecycle events map to AGTP session semantics. A central concern for the QUIC binding is replay safety. QUIC supports 0-RTT early data, which is replayable by design. AGTP requests carry authority-scoped actions; a replayed action method could re-trigger authorized work without the requesting agent's intent. This document defines an AGTP-specific replay-safety profile: early data is permitted only for safe idempotent methods (QUERY, DISCOVER) and *MUST NOT* be used for action methods (EXECUTE, DELEGATE, PURCHASE, TRANSACT, and the lifecycle methods). This document follows the pattern established by HTTP: protocol semantics defined independently of transport ([RFC9110] for HTTP), with transport-specific bindings in separate documents. AGTP semantics are defined in [AGTP]; this document defines the transport mechanics. | |||||||||||||
| draft-hood-agtp-commerce-00.txt | ||||||||||||||
| AGTP-Commerce: Open Commerce Specification for Agent-to-Agent Transactions | ||||||||||||||
|
This document specifies AGTP-Commerce, an open commerce specification for agent-to-agent transactions. The specification defines the structural transaction information that the Agent Transfer Protocol carries between agents, allowing payment providers and commerce applications to compose at the application layer to perform the actual financial execution. AGTP-Commerce is to agent commerce what ISO 20022 is to inter-bank payment messaging: a standardized message format that allows heterogeneous payment infrastructure to interoperate. AGTP-Commerce does not move money, hold funds, or operate as a payment processor. The protocol carries pricing manifests, budget signaling, transaction commitments, and audit trail records that payment providers consume to execute settlement through existing financial infrastructure. This document specifies the pricing manifest format, extended Budget- Limit header semantics, the TRANSACT method for transaction commitment, audit-trail-based receipt records, dispute composition surfaces, and the integration patterns that allow payment providers (traditional processors, banks, cryptocurrency rails, and specialized agent-economy services) to compose with AGTP-Commerce as application- layer infrastructure. | |||||||||||||
| draft-hood-agtp-communication-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hood-agtp-composition-01.txt | ||||||||||||||
| AGTP Composition Profiles: Agent Group Messaging Protocols,External Identity Providers,and HTTP Gateways | ||||||||||||||
|
The Agent Transfer Protocol (AGTP) operates as a substrate beneath several adjacent layers: Agent Group Messaging Protocols (AGMPs) such as the Model Context Protocol (MCP), the Agent-to-Agent Protocol (A2A), and the Agent Communication Protocol (ACP); external identity providers (OAuth, OIDC, enterprise IdPs); and HTTP-based clients that interact with agents through translation gateways. This document specifies the composition profiles for each of these adjacent layers, defining normative mapping rules between the adjacent layer and AGTP. Three composition families are specified. The AGMP composition profile specifies how MCP, A2A, and ACP messages are carried over AGTP, with mapping rules for identity, authority scope, delegation, and session fields between the AGMP and AGTP layers. The External Identity Provider composition profile specifies how AGTP agent identity composes with externally-issued credentials, treating "which agent" and "on whose behalf" as orthogonal axes. The HTTP Gateway composition profile specifies the translation surface for accepting HTTP traffic into AGTP- served agents as a REST adoption ramp. Across all three families, AGTP headers take precedence over equivalent adjacent-layer fields for all infrastructure-level routing, enforcement, and audit operations. Agents gain transport- level governance, observability, and identity without modification to the adjacent layers. | |||||||||||||
| draft-hood-agtp-discovery-01.txt | ||||||||||||||
| AGTP Agent Discovery and Name Service | ||||||||||||||
|
The Agent Transfer Protocol (AGTP) enables agents to communicate once they know each other's canonical identifiers. This document specifies two layered mechanisms by which agents find each other and by which human-readable names resolve to Canonical Agent-IDs: the DISCOVER method, which queries for agents matching a capability description, and the Agent Name Service (ANS), which provides governed name-to-Agent-ID resolution. The architectural relationship is layered. AGTP-Presence [AGTP-PRESENCE] provides ambient awareness of agents within visibility scopes as a substrate property. DISCOVER operates over the Presence substrate to query the live population. ANS provides human-readable name resolution, analogous to DNS for the web, with name authorities federating across organizational boundaries. This document also introduces Anticipatory Discovery Services (ADS) as a forward-looking composition pattern where application-layer services preload agent awareness based on observed operational signals. DISCOVER and ANS together provide the application-layer interfaces for discovery and naming that compose with the substrate-level ambient discovery defined in [AGTP-PRESENCE]. | |||||||||||||
| draft-hood-agtp-identifiers-02.txt | ||||||||||||||
| AGTP Identifier Chain | ||||||||||||||
|
This document specifies the AGTP identifier chain: a layered model of identifiers that together produce a tamper-evident chain of custody across every action an AGTP agent takes. The chain is composed of identifiers already established in the AGTP draft family (Agent-ID, Owner-ID, Session-ID, Task-ID, and the Attribution-Record envelope of base AGTP) together with a small set of additional identifiers introduced by this document (Request-ID, Response-ID, Action-ID, Evaluation-ID, Decision-ID, Audit-ID). The Audit-ID is the cryptographic hash of an extended Attribution-Record and provides the per-agent hash chain that links every action an agent takes back to its Agent Genesis. This document defines the identifiers, how they extend the existing Attribution-Record envelope, the construction of the hash chain, and the verification procedure by which a regulator, auditor, or counterparty reconstructs the chain end to end. The identifier chain is the regulatory backbone of AGTP. Without it, the protocol can record that something happened but cannot prove who caused it, what authorized it, or what was decided. | |||||||||||||
| draft-hood-agtp-lei-00.txt | ||||||||||||||
| AGTP-LEI: Binding the Agent Transfer Protocol to the Verifiable Legal Entity Identifier | ||||||||||||||
|
The Legal Entity Identifier (LEI), defined by ISO 17442 and operated under the global governance of the Global Legal Entity Identifier Foundation (GLEIF), is the internationally recognized identifier for legal entities in financial transactions and regulatory reporting. The verifiable LEI (vLEI), built on Key Event Receipt Infrastructure (KERI) and Authentic Chained Data Containers (ACDC), extends the LEI into the digital trust ecosystem with cryptographically verifiable credentials issued through Qualified vLEI Issuers (QVIs). This document specifies how the Agent Transfer Protocol (AGTP) binds to the LEI and vLEI infrastructure. It defines how an LEI is carried in an AGTP Owner-ID, how a vLEI Legal Entity credential composes with AGTP-CERT to establish institutional identity at the wire, how a new verification path (vlei-anchored) is added to AGTP-TRUST for KERI- based verification, and how vLEI Role Credentials (OOR, ECR, AUTH) express the human authorization chain that produced an agent. The result is a clean composition: AGTP provides the agent identity substrate, the LEI provides the institutional identity, the vLEI provides cryptographic verification of that institutional identity, and the vLEI Role Credentials provide the authorization chain from the legal entity through human officers to the agent. This document positions financial institutions, regulated entities, and other LEI holders to deploy agents with structurally verifiable institutional identity from day one. | |||||||||||||
| draft-hood-agtp-log-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hood-agtp-merchant-identity-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hood-agtp-presence-00.txt | ||||||||||||||
| AGTP Presence: Ambient Discovery and Visibility for Agent Substrates | ||||||||||||||
|
This document specifies AGTP Presence, an ambient discovery and visibility layer for the Agent Transfer Protocol (AGTP). Existing agent discovery proposals are pull-based: an agent must know where to look (a catalog URL, a registry endpoint, a DNS name) before discovery can begin. AGTP Presence inverts this model. When an agent joins the AGTP substrate, it becomes structurally addressable and visible to the relevant scope of other agents immediately, without requiring registration with a central directory. The architecture combines three proven patterns: a Distributed Hash Table (DHT) keyed by Canonical Agent-ID for content-addressable routing, a gossip-based protocol for presence announcement and convergence, and trust-tier-scoped overlay partitioning for visibility control. Per-agent visibility is cryptographically declared in AGTP-CERT certificate extensions and enforced structurally, with three orthogonal axes of control: presence visibility, disclosure visibility, and audience scoping. This document defines three new lifecycle methods (ANNOUNCE, WITHDRAW, PROBE), specifies the DHT and gossip protocols, defines the visibility model and its certificate extensions, addresses scaling through hybrid participation modes and federation-of-scoped-overlays, and provides a threat model with concrete mitigations. | |||||||||||||
| draft-hood-agtp-session-00.txt | ||||||||||||||
| AGTP Session Protocol | ||||||||||||||
|
This document specifies the AGTP Session Protocol (AGTP-SESSION), a companion to [AGTP] that defines session semantics for agent-to-agent and agent-to-API communication. AGTP-SESSION addresses two distinct session models: bounded sessions for time-limited transactional flows, and persistent sessions for long-lived agent contexts. Both inherit identity, authority, and attribution from base AGTP. This is an early working draft; many design decisions are deliberately open. | |||||||||||||
| draft-hood-agtp-standard-methods-01.txt | ||||||||||||||
| AGTP Standard Extended Method Vocabulary | ||||||||||||||
|
The Agent Transfer Protocol (AGTP) defines a core method vocabulary (Tier 1) of twelve intent-based methods covering the most common agent operations. This document defines the Tier 2 Standard Extended Method Vocabulary: methods registered in the IANA AGTP Method Registry that are available for use in any AGTP implementation but are not required for baseline compliance. Methods are organized into six categories reflecting the full operational range of AI agent systems: ACQUIRE, COMPUTE, TRANSACT, INTEGRATE, COMMUNICATE, and ORCHESTRATE. This document also specifies the QUOTE method referenced in the AGTP core specification for pre-flight resource cost estimation. The six-category taxonomy is aligned with the ACTION framework described in [AGENTIC-API]. All methods defined in this document conform to the Agentic Grammar and Interface Specification (AGIS) [AGIS]. Each method satisfies the AGIS action-intent semantic class requirement and syntactic rules. This document serves as a reference vocabulary of AGIS-conformant methods for organizations seeking maximum cross-system interoperability. Organizations requiring domain-specific vocabularies not covered here may define their own AGIS-conformant methods without IANA registration using the Tier 4 grammar-based validation pathway defined in [AGTP]. | |||||||||||||
| draft-hood-agtp-trust-02.txt | ||||||||||||||
| AGTP Trust and Verification Specification | ||||||||||||||
|
This document specifies the AGTP trust and verification model: the trust tiers an AGTP agent may occupy, the verification paths by which a Tier 1 agent's identity is established, the registration procedures by which a governance platform assigns a tier, and the trust score that is carried alongside an agent's identity to express runtime behavioral assessment. AGTP-TRUST is consumed by AGTP-aware infrastructure components (Scope-Enforcement Points, governance gateways, peer agents) for runtime trust-aware routing and authority decisions, and by registration authorities when issuing or evaluating Agent Genesis documents. This is an early working draft; the dimension catalog, computation methodology, and several aspects of the registration procedure are placeholders pending further work. | |||||||||||||
| draft-hood-agtp-web3-bridge-00.txt | ||||||||||||||
| AGTP Web3 Bridge Specification | ||||||||||||||
|
The Agent Transfer Protocol (AGTP) uses a PKI-based trust model: agent identity is anchored to DNS-verified domain ownership and CA- issued X.509 certificates. Web3 systems offer an alternative identity model based on blockchain address ownership, smart contract verification, and decentralized naming systems including the Ethereum Name Service (ENS) and Unstoppable Domains. This document specifies the AGTP Web3 Bridge: a framework for mapping Web3 identity anchors to AGTP trust tiers, resolving Web3 names to canonical AGTP Agent- IDs, and operating AGTP sessions with agents whose identity is anchored to blockchain rather than DNS. Web3-anchored agents are treated as Trust Tier 2 (Org-Asserted) in the absence of additional verification. This document also defines the conditions under which a Web3 identity MAY be elevated to Trust Tier 1 through a hybrid verification procedure. | |||||||||||||
| draft-hood-aipref-earmark-00.txt | ||||||||||||||
| Earmark: Embedded Attribution and Rights Marks for AI Usage Preferences | ||||||||||||||
|
This document defines Earmark (Embedded Attribution and Rights Marks), a mechanism by which publishers and rights holders embed signed usage preferences directly into published content. To earmark content is to reserve it for designated uses, and the mark travels with what it covers, surviving republication and aggregation, so the preference remains discoverable wherever the content arrives, including where perimeter signals such as robots.txt no longer apply. Marks carry the identity of the rights holder, the preferences asserted, and a signature, and are verifiable offline by any party. An individual signed statement is a Mark; the mechanism as a whole is Earmark. This document defines the Mark Object, embedding bindings for common content types, and the detection and verification procedure. It reuses the AI Preference vocabulary for preference semantics and the C2PA and CAWG assertion infrastructure for media, defining new machinery only where none exists. Earmarks make ignored preferences observable and attributable. Enforcement remains with law, contract, and the market. | |||||||||||||
| draft-hood-independent-agis-01.txt | ||||||||||||||
| Agentic Grammar and Interface Specification (AGIS) | ||||||||||||||
|
This document defines the Agentic Grammar and Interface Specification (AGIS), a grammar-constrained interface definition language for Agentive APIs designed for consumption by large language model (LLM) based agents. AGIS establishes structural and semantic rules governing how API methods and endpoints must be expressed, without mandating a fixed vocabulary of method names. An implementation conforming to AGIS uses intent-expressing imperative verbs as method identifiers, enabling agents to infer operational meaning from method names without requiring training on a predefined catalog. AGIS is the native interface definition layer for the Agent Transfer Protocol (AGTP) [AGTP], in the same way that HTML functions as the native content language for the HTTP transport protocol. AGIS does not replace JSON Schema [JSON-SCHEMA] for data contracts; it governs the structural grammar of method and endpoint design that wraps those contracts. AGIS-conformant methods are accepted at the AGTP transport layer via the Method-Grammar header without requiring prior IANA registration, enabling organizations to define domain-specific Agentive API vocabularies while preserving interoperability through shared grammatical constraints. Empirical validation of the core AGIS design principle is provided in [HOOD2026], which demonstrates a 10-29 percentage point accuracy advantage for intent-expressing method names over generic HTTP verbs across three frontier LLM families in 7,200 controlled trials. This version also introduces: normative YAML and JSON serialization formats; a Data Manifest block enabling services to declare available data without pre-built endpoints; a negotiable signal enabling AGTP dynamic endpoint instantiation; semantic declaration enhancements including is_idempotent, impact_tier, parameter_hints, and state_transition fields; vocabulary namespace disambiguation; and an HTTP transitional binding for incremental adoption. | |||||||||||||
| draft-hood-independent-agtp-09.txt | ||||||||||||||
| Agent Transfer Protocol (AGTP) | ||||||||||||||
|
AI agents and agentic systems generate a growing volume of intent- driven, unstructured, and undifferentiated traffic that flows through HTTP indistinguishably from human-initiated requests. HTTP lacks the semantic vocabulary, observability primitives, and identity mechanisms required by agent systems operating at scale. Existing protocols described as Agent Group Messaging Protocols (AGMP), including MCP, ACP, A2A, and ANP, are messaging-layer constructs that presuppose HTTP as their transport. They do not address the underlying transport problem. This document defines the Agent Transfer Protocol (AGTP): a dedicated application-layer protocol for AI agent traffic. AGTP is a runtime contract negotiation substrate (RCNS): a transport that fixes only a eighteen-method protocol floor and negotiates any additional method surface at runtime between agent and server in a single round-trip, governed by the AGTP-API companion specification [AGTP-API], which defines the curated method catalog, path grammar, endpoint primitive, and synthesis semantics. Version 07 confirms the IANA-registered agtp:// URI scheme and IANA-assigned port 4480 for TCP/TLS and QUIC, formalizes Form 1a URI grammar (agtp://{agent-id}@{host}) for direct addressing, renames the Agent Manifest Document to the Agent Identity Document with an enumerated schema, redesigns the protocol-defined method floor to a 12-method set organized as six cognitive verbs (QUERY, DISCOVER, DESCRIBE, SUMMARIZE, PLAN, PROPOSE) and six mechanics verbs (EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY), establishes AGTP as a substrate for higher-level agent frameworks (MCP, A2A, ACP) carried as content types inside AGTP method invocations, renumbers AGTP-specific status codes out of HTTP- assigned space to avoid semantic collision, mandates explicit Content-Length framing with a prohibition on TLS socket-level half- close, adds a .well-known/agtp bootstrap convention per RFC 8615, deprecates the AGIS reference and the proposed AGTP-Methods specification by folding both into the unified AGTP-API contract layer, adds status codes 405 (Method Not Allowed), 459 (Method Violation), and 460 (Endpoint Violation) per the AGTP-API contract model, and adopts "Agent Genesis" as the canonical term for the permanent signed origin document. Version 06 prepared the IANA Service Name and Port Number application and consolidated the URI scheme registration. Version 05 restored the canonical Agent-ID as the primary identity primitive and decoupled Trust Tier 1 verification from DNS as a sole requirement. A canonical Agent-ID is derived from the agent's Agent Genesis hash and is authoritative in every AGTP protocol operation. Three equivalent verification paths are recognized for Trust Tier 1: DNS-anchored verification via RFC 8555 ACME challenge, log-anchored verification via Agent Genesis inclusion in an append-only transparency log aligned with RFC 9162 and RFC 9943 (SCITT), and hybrid verification combining DNS control with blockchain address ownership. Version 04 introduced normative integration hooks for the AGTP Merchant Identity and Agentic Commerce Binding specification [AGTP-MERCHANT], which defines the merchant- side identity model that complements AGTP's agent-side identity model. AGTP transport bindings for TCP/TLS and QUIC are specified in [AGTP-BINDINGS]. AGTP is designed to be composable with existing agent frameworks, not to replace them. | |||||||||||||
| draft-hope-mpdf-protocol-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hopkins-evp-spec-10.txt | ||||||||||||||
| Evidence Package Format Specification: Storing Evidence from Software Testing | ||||||||||||||
|
Taking evidence is a key part of any robust software testing process. This specification defines a format which collects evidence together and stores metadata and annotations in an organised fashion from both manual and automated testing sources. This work is not a standard and does not enjoy community consensus. | |||||||||||||
| draft-hopley-x402-cancellation-receipt-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hopley-x402-canonicalisation-jcs-v1-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hopley-x402-compliance-receipt-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hopley-x402-composite-trust-query-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hopley-x402-federation-zkp-00.txt | ||||||||||||||
| Cross-Issuer ZKP Federation for Post-Quantum Agentic Payment Credentials | ||||||||||||||
|
This document defines a protocol for composing independently-issued post-quantum ZKP credentials from different issuers into a single federation token, without requiring a shared trust root between issuers. Each credential is a Falcon-1024 (NIST FIPS 206) or ML-DSA-65 (NIST FIPS 204) signed Bulletproofs range proof asserting that an agent's trust score meets a threshold. A federation validator independently verifies each credential against its issuer's public key, then computes a composite commitment binding all verified proofs. The resulting federation token is signed by the validator alone. No issuer needs to know about the others. This solves the cross-issuer attestation composition problem in agentic payment networks. | |||||||||||||
| draft-hopley-x402-payment-evidence-frame-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hopley-x402-pqc-credential-binding-00.txt | ||||||||||||||
| Post-Quantum Credential Binding for x402 Agentic Payment Authorization | ||||||||||||||
|
This document defines how Falcon-1024 (NIST FIPS 206 / FN-DSA) and ML-DSA-65 (NIST FIPS 204) credentials bind to x402 agentic payment authorization. It specifies the credential envelope format, the JCS canonicalization discipline applied to signed payloads, the gateway verification procedure, and the session token binding that replaces per-request API key authentication for credentialed agents. This is the first Internet-Draft in the agentic payments space to anchor credential binding to the NIST post-quantum cryptography standards (FIPS 203/204/206). | |||||||||||||
| draft-hopley-x402-refund-receipt-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-hopley-x402-retention-chain-07.txt | ||||||||||||||
| Self-Verifiable Retention Chain for Payment Receipts | ||||||||||||||
|
This document specifies eight cryptographic constructions for self-verifiable agentic payment records. The first, the Retention Chain Reference (retention_chain_ref), enables tamper-evident audit chains linking payment receipts without requiring external infrastructure. The second, the Payment Action Lifecycle, defines a content-addressed model for the exactly-once execution of payment actions, including an action reference primitive (action_ref) and a per-state transition hash (transition_hash) with a provable SKIP-on- retry idempotency guarantee. The third, the Settlement-Action Binding (binding_ref), binds a settled payment to the verified agent action it paid for and to the retention chain entry recording it, so that a settlement attestation proves not only that a payment occurred but which verified action it corresponds to. The fourth, the Policy Binding (policy_bound_ref), binds a content-addressed snapshot of the governing policy to an existing binding or chain reference, so that a decision is verifiable against the exact policy version that admitted it and a policy rotation is detectable by recomputation. The fifth, the Compliance Gate Binding (gate_ref), binds a categorical ALLOW/REFER/DENY compliance verdict and a no-PII payer reference to a policy or binding reference, so that a screening decision is provably tied to the policy in force when it was made and carries no personal data in the bound record. The sixth, the Pre-Payment Decision Chain (guardrail_ref), composes an agent identity reference, a spend authority reference, and the policy in force into one recomputable pre-payment ALLOW/DENY decision. The seventh, Post-Decision Execution Evidence (execution_ref), binds an executed action to the exact decision that authorized it, so the recorded execution is provably consistent with the decision and not merely correlated with an agent identity. The eighth, Cross-Party Authority Delegation (delegation_ref), binds a delegation of authority from one party to another and chains hand-offs, so a verifier can confirm that authority did not widen across an organizational boundary. All constructions use only SHA-256 and the JSON Canonicalization Scheme (JCS, RFC 8785), and are verifiable by any party holding the relevant receipts without contacting the issuer. The constructions satisfy the transaction recording and audit trail obligations of MiCA Article 80, DORA Article 14, and AMLR Article 56. | |||||||||||||
| draft-hopley-x402-rfc9421-binding-01.txt | ||||||||||||||
| RFC 9421 HTTP Message Signatures Binding for x402 Payment Flows | ||||||||||||||
|
This document specifies the normative binding of RFC 9421 (HTTP Message Signatures) and RFC 9530 (Digest Fields for HTTP) to the x402-foundation/x402 challenge/response payment flow. It defines the minimum covered-components set for an x402 challenge response and a payment proof submission, the RFC 9530 Content-Digest discipline, keyid resolution patterns, and the multi-hop proxy-chain survival property that the x402 transport requires. This binding is complementary to the existing http-message-signatures extension in the x402 specification, which specifies agent identity and registration (registrationUrl, signatureSchemes, tags). This document specifies the normative binding: which components MUST be covered, how Content-Digest is handled, and how signatures survive multi-hop proxy chains. The two compose cleanly in a deployment that uses both. A reference implementation is provided as algovoi-rfc9421-verifier on PyPI and npm (Apache 2.0), with Python and TypeScript byte-for-byte parity, cross-validated against external fixture sets. 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 binding specified is one approach among possible alternatives; implementers may choose this approach, alternative approaches, or hybrid approaches as appropriate to their requirements. | |||||||||||||
| draft-hopley-x402-settlement-attestation-01.txt | ||||||||||||||
| 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 ( | |||||||||||||
| draft-hori-agent-quality-graph-00.txt | ||||||||||||||
| Agent Quality Graph (AQG): A Protocol for Evaluating AI Agent Trustworthiness via Delegation Graphs | ||||||||||||||
|
This document describes the Agent Quality Graph (AQG) protocol, a method for evaluating and ranking AI agent trustworthiness based on delegation transaction graphs. As the number of autonomous AI agents grows rapidly, there is no standardized mechanism for determining which agents reliably complete delegated tasks. AQG applies graph- based ranking algorithms, analogous to web page ranking via hyperlink analysis, to the domain of agent-to-agent delegation. Agents that are frequently delegated to by other highly-ranked agents receive higher trust scores. This document defines the delegation record format, the graph construction process, the scoring algorithm, and the API for querying trust scores. | |||||||||||||
| draft-housley-asn1-layman-guide-02.txt | ||||||||||||||
| A Layman's Guide to a Subset of ASN.1,BER,and DER | ||||||||||||||
|
This note gives a layman's introduction to a subset of the Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The purpose of this note is to provide background material sufficient for understanding and implementing standards that make use of ASN.1. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This memo offers tutorial information. | |||||||||||||
| draft-howard-virp-07.txt | ||||||||||||||
| VIRP: Verified Infrastructure Response Protocol | ||||||||||||||
|
The Verified Infrastructure Response Protocol (VIRP) defines a trust framework for operators -- human or autonomous -- acting on live network infrastructure. As operations shift toward agentic and automated systems that can autonomously configure, audit, and remediate production environments, the absence of a verifiable chain of custody for observations and actions introduces fundamental risks: fabricated telemetry, unauthorized state changes, and the inability to distinguish legitimate operations from compromise. VIRP routes every observation and every authorization decision through a designated collection-and- verification boundary that the requesting party does not control. Observations are authenticated at collection time using HMAC-SHA256; in session-bound mode (Section 6.4) authentication uses a per-session key and binds the response to session, device, sequence, and a command-digest field. Validating the command binding additionally requires trusted request context from which the verifier recomputes the command digest. A two-channel architecture separates read-only Observation from write-intent Intent, and trust tiers (GREEN/YELLOW/RED/BLACK) govern action authorization with human-in-the-loop controls for elevated operations. VIRP's observation and chain-integrity guarantees are symmetric and explicitly scoped by key role; approval and federation records use asymmetric Ed25519 signatures. Distinct key roles authenticate observations, chain entries, intents, approvals, and federation records (Section 6.1), though the reference implementation currently reuses one key across the v1-observation and v2-derivation roles; a holder of a symmetric key can both verify and forge within that key's scope, so VIRP does not provide publicly verifiable observation origin and does not defend a record against an adversary holding the relevant key or controlling the collection boundary. Authentication does not certify that a response reflects the managed device's true state, only that the boundary obtained and authenticated those bytes for that recorded request. Asymmetric proof of origin and external anchoring of the chain are distinct, independent items of future work (Section 18). This revision adds External Authorization Binding (Section 11): a deployment profile in which the gate holds only a read-only device identity, the write credential is never at rest on the gate, and per- command authorization is performed by an authorization service that the gate does not control, using the device's own authorization mechanism (for example TACACS+ command authorization [RFC8907] on IOS and IOS-XE). The gate's own record of an action is then reconciled against the device's independent accounting under the same public verification tooling. The individual mechanisms are long-standing; the contribution is their composition, with an autonomous or automated requester as the constrained principal, together with an evidence layer that enables the gate's account of an action to be reconciled against the device's independently sourced account of the same action so a third party can compare them. Static per-command authorization and reconciliation are implemented and exercised on production Cisco hardware; approval-scoped dynamic grants and the chaining of authorization decisions are specified and marked as not yet implemented (Section 19). Since draft-howard-virp-06 the reference chain implementation has gained an OPTIONAL per-entry and per-head Ed25519 signature, computed by the daemon at append time over the same canonical bytes as the mandatory HMAC and verifiable from a public key alone. It is enabled per node and is off by default, so a conforming deployment may still be HMAC-only. The base chain-integrity guarantee remains the symmetric one described here; the signature is an additional authenticator, described in Section 6.5 and Section 6.5.2, not a replacement for it. | |||||||||||||
| draft-howe-vcon-agent-session-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-howe-vcon-lawful-basis-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-howe-vcon-lifecycle-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-howe-vcon-morse-code-extension-00.txt | ||||||||||||||
| vCon Extension for Morse Code Dialog Encoding | ||||||||||||||
|
This document defines a vCon extension for representing Morse code conversations within the Virtualized Conversation (vCon) container format. Morse code remains an actively used communication medium among amateur radio operators, in historical preservation contexts, and in cultural works. The extension provides standardized encoding for Morse code dialog, including keying timing data, prosign representation, and the Farnsworth timing method. This document also addresses information-theoretic considerations of Morse code's variable-length encoding, its relationship to modern source coding theory, and the privacy implications of preserving historically significant Morse code conversations whose data subjects may be deceased. | |||||||||||||
| draft-howe-vcon-provenance-00.txt | ||||||||||||||
| vCon Generation Provenance | ||||||||||||||
|
This document defines a "provenance" extension for Virtualized Conversations (vCon) that records how a piece of generated content was produced by a generative model: the model and provider, the decoding parameters (for example temperature and top_p), the prompt or a hash of it, the vCon elements that were given to the model as input, and a hash of the output. The record is carried as a named provenance member on the analysis object it describes (and, for machine-generated dialog, on the dialog object), so that an analysis has a real, named home for "how this was generated" rather than overloading the analysis body or schema. The extension is a Compatible vCon extension. It introduces no new top-level fields and does not alter the semantics of existing ones. Because the provenance record binds an output to its model, prompt, and inputs by hash, a signed vCon, or a SCITT transparency receipt over it, can attest to a verifiable derivation: not only that the analysis exists, but how it came to be. | |||||||||||||
| draft-howe-vcon-sip-signaling-00.txt | ||||||||||||||
| vCon Extension for SIP Signaling and STIR/SHAKEN Data | ||||||||||||||
|
This document defines a vCon extension for capturing Session Initiation Protocol (SIP) signaling metadata, STIR/SHAKEN certificate data, and related telephony information within the vCon conversation data container. The extension uses the vCon Attachment Object to store SIP messages and certificates, and introduces optional parameters on Party and Dialog Objects to carry SIP-specific identifiers. This extension is classified as Compatible per the vCon extension framework, allowing implementations that do not recognize it to safely ignore the additional data. | |||||||||||||
| draft-howe-vcon-wtf-extension-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-howlett-aigcsep-00.txt | ||||||||||||||
| The Covenant -- Artificial Intelligence Governance Control and Service Exchange Protocol (AIGCSEP) | ||||||||||||||
|
The Artificial Intelligence Governance Control and Service Exchange Protocol (AIGCSEP), informally called The Covenant, establishes an open, universal framework for autonomous machine-to-machine commerce, automated service discovery, and verifiable human accountability. This specification delivers the concrete engineering infrastructure-- cryptographic leashes, three-plane isolation, and low-latency transaction tracking--required to let autonomous AI agents safely out of the cage: free to discover downstream capabilities and execute financial transactions on behalf of human users, with every action identifiable, attributable, and auditable. Today, AI systems exist in isolated silos, much as early computers did before the internet unified them. The Covenant opens that marketplace: any compliant participant can hang a shingle and do business. Participation is voluntary; compliance is enforced by consensus, not coercion: entities that join gain access to the full interconnected economy, while those that do not, or that lose standing, are simply returned to their pre-Covenant silo. The market collectively declines to transact with them--no pursuit, no termination, just the natural gravity of market access. The governance architecture provides the substrate through which existing human authority extends naturally into this digital space. An emergency stop function enables authorized principals to act within their jurisdiction (Section 3.1). The structural design draws on the same fault-tolerant, triadic engineering principles that have made constitutional government durable under adversarial conditions-- not to impose any particular legal tradition, but because that model is the proven architecture for multi-party, adversarially robust control. Exactly how sovereign branches project their authority into these cryptographic interfaces is presented as an open invitation for community standards development (Section 9). | |||||||||||||
| draft-hss-srv6ops-srv6-routing-planes-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-httpauth-payment-01.txt | ||||||||||||||
| The "Payment" HTTP Authentication Scheme | ||||||||||||||
|
This document defines the "Payment" HTTP authentication scheme, enabling HTTP resources to require a payment challenge to be fulfilled before access. The scheme extends HTTP Authentication, using the HTTP 402 "Payment Required" status code. The protocol is payment-method agnostic, supporting any payment network or currency through registered payment method identifiers. Specific payment methods are defined in separate payment method specifications. | |||||||||||||
| draft-hu-6man-ipv6-flowlabel-load-balancing-rdma-02.txt | ||||||||||||||
| A RoCEv2 Flow-Level Load Balancing Method Based on the IPv6 Flow Label | ||||||||||||||
|
This document proposes a method for achieving flow-level load balancing in RoCEv2 (RDMA over Converged Ethernet version 2) networks. Traditional per-flow load balancing based on the 5-tuple cannot distinguish between different RDMA sessions that share the same 5-tuple. This causes "elephant flows" to be hashed to the same path, leading to network congestion. This method resolves this issue by having the ingress network device (e.g., a top-of-rack switch or router) parse the QP (Queue Pair) information from the IB BTH (Base Transport Header) and IB DETH (Datagram Extended Transport Header) headers of the RoCEv2 packet. By combining this with portions of the IPv6 source and destination addresses as an entropy source, a CRC32 hash algorithm generates a 20-bit value, which is then written into the Flow Label field of the IPv6 header. Network devices can subsequently use the updated "5-tuple + Flow Label" for more granular flow-level load balancing, thereby effectively improving transmission efficiency in high-performance networks such as AI computing. | |||||||||||||
| draft-hu-ipsecme-pqt-hybrid-auth-05.txt | ||||||||||||||
| Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the Internet Key Exchange Version 2 (IKEv2) | ||||||||||||||
|
One IPsec area that would be impacted by Cryptographically Relevant Quantum Computer (CRQC) is IKEv2 authentication based on traditional asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely deployed authentication options of IKEv2. There are new Post-Quantum Cryptographic (PQC) algorithms for digital signature like NIST [ML-DSA], However, it takes time for new cryptographic algorithms to mature, There is security risk to use only the new algorithm before it is field proven. This document describes a hybrid PKI authentication scheme for IKEv2 that incorporates both traditional and PQC digital signature algorithms, so that authentication is secure as long as one algorithm in the hybrid scheme is secure. | |||||||||||||
| draft-hu-lsr-isis-process-verification-00.txt | ||||||||||||||
| IS-IS Process ID Verification | ||||||||||||||
|
In IS-IS deployments, the process identifier (process ID) is used on a local router to distinguish and manage different IS-IS protocol instances. Process ID is local to the router and is not transmitted to neighbors, providing operational flexibility. However, because the process ID is also used to implement route redistribution and specify administrative tags for fine-grained control, its misconfiguration can lead to severe impacts (e.g., routing loops or black holes) with difficult troubleshooting. To address this problem, network operators typically deploy a consistent process ID on both ends of a link within the same domain, to reduce configuration complexity. In this context, to avoid the misconfiguration of the IS-IS process ID, this document introduces two optional approaches for process ID verification. When process ID verification is enabled, an IS-IS adjacency can be established only when the process identifiers at both ends of the link match. | |||||||||||||
| draft-huang-idr-color-time-schedule-00.txt | ||||||||||||||
| BGP Extension for Time-Scheduled Color based SR Policy Selection | ||||||||||||||
|
Segment Routing (SR) Policy is identified by a tuple of Color and Endpoint. In BGP/MPLS IP VPN and EVPN services, the egress PE attaches a Color Extended Community to the advertised VPN route so that the ingress PE can steer the traffic into a corresponding SR Policy. In many deployment scenarios, the same customer may require different Service Level Agreements (SLAs) during different time periods of a day. For example, a customer may require a high- bandwidth SLA during the off-peak hours (e.g., 02:00-06:00) and a low-cost SLA during the daytime. Such time-variant SLA requirements imply that the ingress PE should select different SR Policies (i.e., different Colors) for the same VPN route at different times. This document defines a new BGP Extended Community, called the Schedule Extended Community, to be used together with the Color Extended Community. Two sub-types of the Schedule Extended Community are defined: a Daily Schedule sub-type for recurring time-of-day periods, and a Day Schedule sub-type for specific dates. The Schedule Extended Community carries the time period during which the associated Color is valid. Based on the current time and the received Schedule Extended Communities, the ingress PE can dynamically select the appropriate SR Policy for a VPN route, thereby realizing time-scheduled SLA switching. | |||||||||||||
| draft-huang-savnet-pi-sav-for-cc-02.txt | ||||||||||||||
| Provider Interface SAV for Customer Cone Sources | ||||||||||||||
|
Current source address validation (SAV) on an AS's provider interfaces mainly relies on loose uRPF, which cannot defend against IP spoofing using routable prefixes and is ineffective when a default route is present. This document describes a *framework* for provider interface source address validation against spoofing of customer cone source prefixes (PI-SAV for CC). Two architectural approaches are presented: * *PI-SAV for Standalone CC*: a static solution that builds a blocklist based on topology information from BGP RIBs, RPKI ASPA, and local configuration (SLURM) etc. It requires no inter-AS communication. * *PI-SAV for Standalone+ CC*: an enhanced solution that uses lightweight query-response coordination between the top AS and member ASes to identify sub-cones that do not actually cause traffic detours, thereby enlarging the effective blocklist. This document is *informational* and provides only the framework, conceptual procedures, and requirements for future protocol specifications. Detailed wire protocols (e.g., for partial transit information provisioning or for query-response messaging) are out of scope and will be defined in separate documents. | |||||||||||||
| draft-huang-sidrops-source-pre-validation-00.txt | ||||||||||||||
| Source Pre-validation in RPKI-based Route Origin Validation | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) and Route Origin Validation (ROV) have significantly improved inter-domain routing security. However, thousands of RPKI-invalid routes - the vast majority caused by misconfiguration or synchronization delays - persistently appear in the global routing table. Many of these self- inflicted invalid routes originate from autonomous systems (ASes) that could have easily blocked them before advertisement. This document defines a *Best Current Practice (BCP)* for *source pre-validation*: the practice by which an originating AS checks its intended BGP announcement against its local RPKI cache *before* sending it to eBGP neighbors. Routes that would be evaluated as Invalid (or NotFound for strict mode) are blocked, logged, and *MUST be cached* for later re-evaluation, enabling automatic recovery when RPKI data changes. Routes evaluated as Valid or NotFound(for default mode) may be advertised normally. This BCP complements existing standards RFC8893 & RFC9324 by focusing on *mandatory deployment at the origin* and on *outbound caching* of suppressed routes. It provides operational guidance for deployment, cache management, and handling of RPKI data updates. Implementation of this BCP reduces self-inflicted invalid routes, improves global routing stability, and encourages wider ROV adoption. | |||||||||||||
| draft-huang-spring-pppoe-srv6-01.txt | ||||||||||||||
| SRv6 for PPPoE Transport | ||||||||||||||
|
This document proposes a method that employs SRv6 underlay tunnel to transport PPPoE session information across broadband networks. By leveraging the programmability of SRv6 SIDs, the approach not only delivers trusted authentication and secure subscriber access, but also enables operators to offer differentiated services and flexibly instantiate network functions for broadband users. | |||||||||||||
| draft-huang-spring-time-scheduled-color-behavior-00.txt | ||||||||||||||
| Headend Behavior for Time-Scheduled Color based SR Policy Selection | ||||||||||||||
|
This document specifies the normative behavior of the ingress Provider Edge (PE) router (headend) when selecting a Segment Routing (SR) Policy for VPN traffic based on time-scheduled Color values. In the time-scheduled Color mechanism, the egress PE advertises multiple (Color, Schedule) groups for the same VPN routes. The headend evaluates the schedule associated with each Color based on the current time, selects a currently valid Color, and steers the traffic into the corresponding SR Policy. This document defines the requirements for parsing the Color and Schedule Extended Communities, evaluating schedule validity, selecting among multiple valid Colors, performing schedule-boundary timer-based re-evaluation, handling switchover with make-before- break, and falling back when no Color is valid. This document updates RFC 9256 by replacing the multiple-Color selection rule specified in Section 8.4.1 with a Schedule-based selection rule. | |||||||||||||
| draft-huang-spring-time-scheduled-color-framework-00.txt | ||||||||||||||
| Framework for Time-Scheduled Color based SR Policy Selection | ||||||||||||||
|
In Segment Routing (SR) based VPN services, the BGP Color Extended Community is used by the egress Provider Edge (PE) router to steer VPN traffic into an SR Policy at the ingress PE. In many deployment scenarios, a customer requires different Service Level Agreements (SLAs) during different time periods of a day. For example, during business hours (e.g., 06:00 to 02:00 the next day) a best-effort, lower-cost SLA is sufficient for normal office traffic, while during the early morning hours (e.g., 02:00 to 06:00) a high-bandwidth, low-latency SLA is required for massive data transmission such as scientific computing. This document presents a framework for time-scheduled Color based SR Policy selection. The mechanism allows the egress PE to advertise multiple (Color, Color Schedule) pairs for the same VPN routes, enabling the ingress PE to select the appropriate SR Policy based on the current time. The time-to-Color mapping is configured per VPN instance (VRF/VSI), so each customer can have an independent time-varying SLA policy. This document is an Informational framework that describes the problem and the overall architecture. The advantages of the proposed mechanism and the comparison with alternative approaches are provided in Appendix A. The normative specifications of the protocol extensions, data models, and other components are described in Appendix B. | |||||||||||||
| draft-huitema-ccwg-c4-design-04.txt | ||||||||||||||
| Design of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. It pays special attention to the high jitter conditions encountered in Wi-Fi networks. The design emphasizes simplicity and avoids making too many assumption about the "model" of the network. The main control variables are the estimate of the data rate and of the maximum path delay in the absence of queues. | |||||||||||||
| draft-huitema-ccwg-c4-spec-04.txt | ||||||||||||||
| Specification of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design emphasizes simplicity and avoids making too many assumptions about the "model" of the network. | |||||||||||||
| draft-huitema-ccwg-c4-test-04.txt | ||||||||||||||
| Testing of Christian's Congestion Control Code (C4) | ||||||||||||||
|
Christian's Congestion Control Code is a new congestion control algorithm designed to support Real-Time applications such as Media over QUIC. It is designed to drive towards low delays, with good support for the "application limited" behavior frequently found when using variable rate encoding, and with fast reaction to congestion to avoid the "priority inversion" happening when congestion control overestimates the available capacity. The design was validated by series of simulations, and also by initial deployments in control networks. We describe here these simulations and tests. | |||||||||||||
| draft-hunt-httpbis-watch-method-00.txt | ||||||||||||||
| WATCH: A Proposed HTTP Method for Event-Driven Subscriptions | ||||||||||||||
|
This document proposes the addition of a WATCH method to the Hypertext Transfer Protocol (HTTP). The WATCH method enables a client to subscribe to change notifications on a specified resource, shifting the communication model from client-initiated polling to server-initiated event delivery. The proposal includes two companion mechanisms: ALIVE, a client- initiated heartbeat protocol that maintains subscription validity and restores economic symmetry between client and server; and UNWATCH, a clean subscription termination method. Together, these introduce an event-driven subscription layer into HTTP while preserving the protocol's existing simplicity and extensibility. This document incorporates formal terminology, a setup phase with confirmation handshake, refined jurisdictional compliance guidance, implementation recommendations, and protocol flow diagrams for all defined interaction patterns. | |||||||||||||
| draft-huque-dnsop-multi-alg-rules-08.txt | ||||||||||||||
| Multiple Algorithm Rules in DNSSEC | ||||||||||||||
|
This document restates the requirements on DNSSEC signing and validation and makes small adjustments in order to allow for more flexible handling of configurations that advertise multiple Secure Entry Points (SEP) with different signing algorithms via their DS record or trust anchor set. The adjusted rules allow both for multi- signer operation and for the transfer of signed DNS zones between providers, where the providers support disjoint DNSSEC algorithm sets. In addition, the proposal enables pre-publication of a trust anchor in preparation for an algorithm rollover, such as of the root zone. This document updates RFCs 4035 and 6840. | |||||||||||||
| draft-hwang-silp-protocol-02.txt | ||||||||||||||
| Semantic Interlingua Layer Protocol (SILP): A Payload Codec for Cross-Model Agent Communication | ||||||||||||||
|
This document specifies the Semantic Interlingua Layer Protocol (SILP), a black-box, text-interface payload codec designed for cross- model agent-to-agent communication. SILP defines a coarse-grained action-slot intermediate representation (IR) as the reference semantic layer and compiles it into multiple pluggable surface frontends -- code-like function-call syntax, pure JSON, natural language, and ML-compressed text. SILP is designed as a payload- layer option within existing agent transport protocols such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol, which define transport envelopes and capability discovery but leave payload encoding unspecified. SILP provides compile/decode round-trip guarantees for lossless frontends, dynamic frontend negotiation via probe messages, session management with heartbeat renewal, and a verb whitelist verified across six production tokenizers for cross-model token-level stability. This document is a product of independent research and is not an IETF standard. It is published as an Informational document to establish a stable reference for implementers. | |||||||||||||
| draft-hzh-fantel-wan-tunnel-03.txt | ||||||||||||||
| Fast Notification for tunnel-based lossless RDMA transmission in WAN | ||||||||||||||
|
With the rapid development of Large Language Models (LLMs), many emerging AI services require lossless transmission of RDMA traffic over tunnels in Wide Area Network(WAN). Existing network mechanisms were not designed for the responsiveness and scale required by these dynamic services. WAN should support the real-time, lightweight network notification to enhance the responsiveness for traffic engineering, congestion mitigation, and failure protection. This document analyzes typical scenarios where RDMA traffic need to be tunneled across WAN, and proposes fast network notification solutions based on ICMPv6 or UDP. | |||||||||||||
| draft-iab-ip-geo-workshop-report-04.txt | ||||||||||||||
| Report from the IAB Workshop on IP Address Geolocation | ||||||||||||||
|
The IAB Workshop on IP Address Geolocation (IP-GEO) was held from December 3-5, 2025, as a three-day virtual meeting. It covered the use cases and background on using IP addresses as indicators of geolocation, explored various problems and challenges that exist in that ecosystem, and discussed future directions and opportunities to improve or replace the current practices. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. | |||||||||||||
| draft-iab-protocol-greasing-01.txt | ||||||||||||||
| Considerations For Maintaining Protocols Using Grease and Variability | ||||||||||||||
|
Active use and maintenance of network protocols is an important way to ensure that protocols remain interoperable and extensible over time. Techniques such as intentionally exercising extension points with non-meaningful values (referred to as "grease") or adding variability to how protocol elements are used help generate this active use. Grease and variability are used across various protocols developed by the IETF. This document discusses considerations when designing and deploying grease and variability mechanisms, and provides advice for making them as effective as possible. | |||||||||||||
| draft-iab-rfc4052bis-05.txt | ||||||||||||||
| IAB Processes for Management of IETF Liaison Relationships | ||||||||||||||
|
This document describes the procedures used by the Internet Architecture Board (IAB) to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also outlines the expectations of the IAB in establishing formal liaison relationships and describes the responsibilities of IAB- appointed IETF liaison managers. | |||||||||||||
| draft-iab-rfc4053bis-05.txt | ||||||||||||||
| Procedures for Handling Liaison Statements to and from the IETF | ||||||||||||||
|
This document describes the procedures for generating and handling liaison statements between the IETF and other Standards Development Organizations (SDOs), so that the IETF can effectively collaborate with other organizations in the international standards community. | |||||||||||||
| draft-iannone-dawn-privacy-considerations-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-icann-registrar-interfaces-16.txt | ||||||||||||||
| ICANN Registrar Interfaces | ||||||||||||||
|
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications. | |||||||||||||
| draft-ietf-6lo-nd-gaao-11.txt | ||||||||||||||
| Generic Address Assignment Option for 6LoWPAN Neighbor Discovery | ||||||||||||||
|
This document specifies an extension to the IPv6 Neighbor Discovery in Low Power and Lossy Networks (LLNs), enabling a node to request to be assigned an address or a prefix from neighbor routers, without introducing a centralized infrastructure and without relying on multicast messages. Such a mechanism makes it possible to algorithmically assign addresses and prefixes to nodes in a 6LoWPAN deployment. The proposed mechanism is more efficient in such specific scenario with respect to DHCPv6. | |||||||||||||
| draft-ietf-6lo-owc-07.txt | ||||||||||||||
| Transmission of IPv6 Packets over Short-Range Optical Wireless Communications | ||||||||||||||
|
[IEEE802.15.7], "Short-Range Optical Wireless Communications" defines wireless communication using visible light. It defines how data is transmitted, modulated, and organized in order to enable reliable and efficient communication in various environments. The standard is designed to work alongside other wireless communication systems and supports both Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) communications. However, ambient light interference from natural sunlight or artificial lighting sources can impact signal reliability. To mitigate this, advanced modulation techniques, optical filtering, and adaptive power control can be employed. This document describes how IPv6 is transmitted over short-range optical wireless communications (OWC) using IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. | |||||||||||||
| draft-ietf-6lo-path-aware-semantic-addressing-15.txt | ||||||||||||||
| Path-Aware Semantic Addressing (PASA) for Low power and Lossy Networks | ||||||||||||||
|
This document specifies a topological addressing scheme, Path-Aware Semantic Addressing (PASA), that enables stateless IP packet forwarding. The forwarding decision is based solely on the destination address structure. This document focuses on carrying IP packets across an LLN (Low power and Lossy Network), in which the topology is quite static, the location of the nodes is fixed for long period of time, and the connection between the nodes is also rather stable. This document specifies the PASA architecture, along with the PASA address allocation, forwarding mechanism, routing header format, and IPv6 interconnection support. | |||||||||||||
| draft-ietf-6lo-schc-15dot4-13.txt | ||||||||||||||
| Transmission of SCHC-compressed packets over IEEE 802.15.4 networks | ||||||||||||||
|
A framework called Static Context Header Compression and fragmentation (SCHC) has been designed with the primary goal of supporting IPv6 over Low Power Wide Area Network (LPWAN) technologies [RFC8724]. One of the SCHC components is a header compression mechanism. If used properly, SCHC header compression allows a greater compression ratio than that achievable with traditional 6LoWPAN header compression [RFC6282]. For this reason, it may make sense to use SCHC header compression in some 6LoWPAN environments, including IEEE 802.15.4 networks. This document specifies how a SCHC-compressed packet can be carried over IEEE 802.15.4 networks. The document also enables the transmission of SCHC-compressed UDP/ CoAP headers over 6LoWPAN-compressed IPv6 packets. | |||||||||||||
| draft-ietf-6man-eh-occurrences-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-6man-enhanced-vpn-vtn-id-16.txt | ||||||||||||||
| Carrying Network Resource (NR) related Information in IPv6 Extension Headers | ||||||||||||||
|
Virtual Private Networks (VPNs) provide different customers with logically separated connectivity over a common network infrastructure. With the introduction of 5G and also in some existing network scenarios, some customers may require network connectivity services with features that are more advanced compared to conventional VPN services. Such kind of network service is called enhanced VPNs. Enhanced VPNs can be used, for example, to deliver network slice services. 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 may be used as the underlay to support one or a group of enhanced VPN services. For packet forwarding within a specific NRP, some fields in the data packet (these fields are called the NRP Selector) are used to identify the NRP to which the packet belongs. By identifying a packet with an NRP, NRP-specific processing can be performed on each node along the forwarding path in the NRP. This document specifies a new IPv6 Hop-by-Hop option to carry Network Resource related information in data packets. The new option is called the Network Resource (NR) Option. It can be used to carry an identifier of the NRP Selector, but it is designed to also be able to carry general information about network resource semantics and functions. | |||||||||||||
| draft-ietf-6man-icmpv6-ioam-conf-state-11.txt | ||||||||||||||
| IPv6 Query for Enabled In-situ OAM Capabilities | ||||||||||||||
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in IPv6 networks. IPv6 Node IOAM Query functionality uses the ICMPv6 Query messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. | |||||||||||||
| draft-ietf-6man-icmpv6-reflection-19.txt | ||||||||||||||
| Internet Control Message Protocol (ICMPv6) Reflection | ||||||||||||||
|
This document specifies the ICMPv6 Reflection utility. The ICMPv6 Reflection utility is a diagnostic tool, similar to Ping and the ICMPv6 PROBE utility. It is similar to Ping and PROBE in that it relies on a stateless message exchange between a probing node and a probed node. The probing node sends a request to the probed node and the probed node responds to the request. The ICMPv6 Reflection utility differs from Ping and PROBE because, in the ICMPv6 Reflection utility, the probing node requests a snapshot of the message that it sent, as it was when arrived at the probed node. The probed node returns the requested snapshot. The ICMPv6 Reflection utility is useful because it can allow the user to see how the network modified the request as it traveled from the probing node to the probed node. | |||||||||||||
| draft-ietf-6man-ieee80211-dms-00.txt | ||||||||||||||
| IPv6 wants 802.11 Directed Multicast Service | ||||||||||||||
|
There is consensus for switching this document from Flexible Multicast Service (FMS) to Directed Multicast Service (DMS). This version has not been edited over yet and is being uploaded to check if/how the name can be changed. IEEE 802.11 Flexible Multicast Service (FMS) addresses reliability issues in IPv6 due to aggressive powersave optimizations in 802.11 client devices. The intent of this document is to collect consensus in the IETF 6man (IPv6 Maintenance) working group to request either/both the IEEE 802.11 Working Group and/or the Wifi Alliance's certification process to make implementing FMS a requirement. | |||||||||||||
| draft-ietf-6man-ipv6-neighbor-discovery-yang-08.txt | ||||||||||||||
| YANG Data Model for IPv6 Neighbor Discovery | ||||||||||||||
|
This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Enhanced Duplicate Address Detection. | |||||||||||||
| draft-ietf-6man-rfc6724-update-25.txt | ||||||||||||||
| Prioritizing known-local IPv6 ULAs through address selection policy | ||||||||||||||
|
This document updates the default address selection algorithm for Internet Protocol Version 6 (IPv6), originally specified in RFC 6724, based on accumulated operational experience. It introduces the concept of "known-local" Unique Local Address (ULA) prefixes within the fd00::/8 block and specifies that ULA-to-ULA communications using such prefixes should be preferred over both IPv4-to-IPv4 and GUA-to- GUA (Global Unicast Address) communications in local use scenarios. The document defines mechanisms for nodes to identify and incorporate known-local prefixes into their address selection policy tables. It introduces a requirement to implement Rule 5.5 of RFC 6724 and reduces the default precedence for 6to4 addresses. These updates enhance the supportability of typical deployment environments, including automatic and unmanaged configurations, and promote consistent IPv6-over-IPv4 precedence behavior for both ULA and GUA within local networks. The document acknowledges that certain atypical deployment models may require explicit configuration to achieve intended operational outcomes. | |||||||||||||
| draft-ietf-6man-rfc8504-bis-03.txt | ||||||||||||||
| IPv6 Node Requirements | ||||||||||||||
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 8504, and in turn RFC 6434 and its predecessor, RFC 4294. | |||||||||||||
| draft-ietf-6man-sidlist-clarification-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-6man-slaac-renum-14.txt | ||||||||||||||
| Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events | ||||||||||||||
|
In scenarios where network configuration information becomes invalid without explicit notification to the local network, local hosts may end up employing stale information for an unacceptably long period of time, thus resulting in interoperability problems. This document improves the reaction of IPv6 Stateless Address Autoconfiguration to such configuration changes. It formally updates RFC 4191, RFC 4861, RFC 4862, RFC 8106, RFC 8781, RFC 9096, and RFC 9463. | |||||||||||||
| draft-ietf-6man-snac-router-ra-flag-08.txt | ||||||||||||||
| SNAC Router Flag in ICMPv6 Router Advertisement Messages | ||||||||||||||
|
This document defines a new flag, the SNAC Router flag, in the Router Advertisement message that can be used to distinguish configuration information sent by SNAC routers from information sent by transit routers. | |||||||||||||
| draft-ietf-6man-sub-link-scope-multicast-01.txt | ||||||||||||||
| Sub-Link Scoped IPv6 Multicast Addressing | ||||||||||||||
|
The IPv6 addressing architecture for multicast has the scope of a multicast group embedded in its address, with the smallest non- reserved scopes being interface-local and link-local, numbered 1 and 2. This document suggests the introduction of a scope inbetween these two, for use with lower-layer transport multicast that reaches parts of a link. Since there is no room to insert a scope value for this, a separate address block is used. A mapping for Ethernet as lower-layer transport is provided. | |||||||||||||
| draft-ietf-ace-authcred-dtls-profile-04.txt | ||||||||||||||
| Additional Formats of Authentication Credentials for the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead of DTLS, as defined in RFC 9430. | |||||||||||||
| draft-ietf-ace-coap-est-oscore-11.txt | ||||||||||||||
| Protecting EST Payloads with OSCORE | ||||||||||||||
|
Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates. | |||||||||||||
| draft-ietf-ace-coap-pubsub-profile-05.txt | ||||||||||||||
| CoAP Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to enable secure group communication in the Publish-Subscribe (Pub-Sub) architecture for the Constrained Application Protocol (CoAP) [draft- ietf-core-coap-pubsub], where Publishers and Subscribers communicate through a Broker. This profile relies on protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. This document specifies the provisioning and enforcement of authorization information for Clients to act as Publishers and/or Subscribers, as well as the provisioning of keying material and security parameters that Clients use for protecting their communications end-to-end through the Broker. Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]" with the RFC number of that document and delete this paragraph. | |||||||||||||
| draft-ietf-ace-edhoc-oscore-profile-11.txt | ||||||||||||||
| Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. | |||||||||||||
| draft-ietf-ace-group-oscore-profile-07.txt | ||||||||||||||
| The Group Object Security for Constrained RESTful Environments (Group OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group Object Security for Constrained RESTful Environments (Group OSCORE) to provide communication security between a client and one or multiple resource servers that are members of an OSCORE group. The profile securely binds an OAuth 2.0 access token to the public key of the client associated with the private key used by that client in the OSCORE group. The profile uses Group OSCORE to achieve server authentication and proof of possession of the client's private key. Also, it provides proof of the client's membership to the OSCORE group by binding the access token to information that pertains to the Group OSCORE Security Context, thus allowing the resource server(s) to verify the client's membership upon receiving the access token. Effectively, the profile enables fine-grained access control paired with secure group communication, in accordance with the Zero Trust principles. | |||||||||||||
| draft-ietf-ace-key-groupcomm-oscore-21.txt | ||||||||||||||
| Key Management for Group Object Security for Constrained RESTful Environments (Group OSCORE) Using Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
This document defines an application profile of the Authentication and Authorization for Constrained Environments (ACE) framework, to request and provision keying material in group communication scenarios that are based on the Constrained Application Protocol (CoAP) and are secured with Group Object Security for Constrained RESTful Environments (Group OSCORE). This application profile delegates the authentication and authorization of Clients, which join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication, and proof of possession of a key owned by the Client and bound to an OAuth 2.0 access token. | |||||||||||||
| draft-ietf-ace-oscore-gm-admin-17.txt | ||||||||||||||
| Admin Interface for the OSCORE Group Manager | ||||||||||||||
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible for handling the joining of new group members, as well as for managing and distributing the group keying material. This document defines a RESTful admin interface at the Group Manager that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The Authentication and Authorization for Constrained Environments (ACE) framework is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. | |||||||||||||
| draft-ietf-ace-oscore-gm-admin-coral-06.txt | ||||||||||||||
| Using the Constrained RESTful Application Language (CoRAL) with the Admin Interface for the OSCORE Group Manager | ||||||||||||||
|
Group communication for the Constrained Application Protocol (CoAP) can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group keying material. The Group Manager can provide a RESTful admin interface that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. This document specifies how an Administrator interacts with the admin interface at the Group Manager by using the Constrained RESTful Application Language (CoRAL). The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof of possession, and server authentication. | |||||||||||||
| draft-ietf-ace-workflow-and-params-08.txt | ||||||||||||||
| Short Distribution Chain (SDC) Workflow and New OAuth Parameters for the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document updates the Authentication and Authorization for Constrained Environments framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when Concise Binary Object Representation (CBOR) is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework. | |||||||||||||
| draft-ietf-acme-authority-token-jwtclaimcon-07.txt | ||||||||||||||
| JWTClaimConstraints profile of ACME Authority Token | ||||||||||||||
|
This document defines an authority token profile for the validation of JWTClaimConstraints and EnhancedJWTClaimConstraints certificate extensions within the Automated Certificate Management Environment (ACME) protocol. This profile is based on the Authority Token framework and establishes the specific ACME identifier type, challenge mechanism, and token format necessary to authorize a client to request a certificate containing these constraints. | |||||||||||||
| draft-ietf-acme-device-attest-10.txt | ||||||||||||||
| Automatic Certificate Management Environment (ACME) Device Attestation Extension | ||||||||||||||
|
This document specifies new identifiers and a challenge for the Automatic Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. This document updates RFC 8555 to enable a privacy-preserving mode for the identifiers defined in this document. | |||||||||||||
| draft-ietf-acme-dns-account-label-03.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-acme-dns-persist-01.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation | ||||||||||||||
|
This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as multi-tenant hosting platforms, enterprise DNS environments, and IoT deployments. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/Browser Forum Baseline Requirements. | |||||||||||||
| draft-ietf-acme-integrations-17.txt | ||||||||||||||
| ACME Integrations for Device Certificate Enrollment | ||||||||||||||
|
This document outlines multiple advanced use cases and integrations that ACME facilitates without any modifications or enhancements required to the base ACME specification. The use cases include ACME integration with EST, BRSKI and TEAP. | |||||||||||||
| draft-ietf-acme-pop-00.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Extension for Proof-of-Possession | ||||||||||||||
|
The Automated Certificate Management Environment (ACME) protocol [RFC8555] requires a PKCS#10 Certificate Signing Request (CSR) at the finalization stage. This document defines an optional extension that allows a client to prove possession of a private key directly, without constructing a CSR. The extension is motivated by use cases where the CSR-based flow is problematic: KEM-only keys that cannot generate self-signatures, resource-constrained devices that benefit from reduced encoding overhead, and issuance models where the certificate is constructed from order and profile data (e.g., via the ACME Profiles extension [I-D.ietf-acme-profiles]) rather than a client-generated CSR. This is particularly relevant when combined with compact encodings such as C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. In the "newOrder" request, the client declares the public key via a popKey field and includes a pop-type identifier whose value is the empty string. The server creates a dedicated pop authorization containing a single pop-01 challenge, processed using the same state machine as any other ACME authorization. When all authorizations (including the pop authorization) are valid, the ACME server issues a certificate using the validated public key and the authorized identifiers, eliminating the need for a CSR at finalization. The extension is additive and strictly optional: clients that do not use it, and servers that do not support it, continue to use the standard CSR-based flow defined in [RFC8555] without any changes. | |||||||||||||
| draft-ietf-acme-profiles-02.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Profiles Extension | ||||||||||||||
|
This document defines how an ACME Server may offer a selection of different certificate profiles to ACME Clients, and how those clients may indicate which profile they want. | |||||||||||||
| draft-ietf-acme-rats-02.txt | ||||||||||||||
| Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type | ||||||||||||||
|
This document describes an approach where an ACME Server can challenge an ACME Client to provide Evidence, Endorsements, or Attestation Result according to the Remote ATtestation procedureS (RATS) framework in any format supported by the Conceptual Message Wrapper (CMW). The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. | |||||||||||||
| draft-ietf-aipref-attach-05.txt | ||||||||||||||
| Associating AI Usage Preferences with Content in HTTP | ||||||||||||||
|
Methods are defined for associating usage preferences with content that is obtained using the HTTP protocol. This document defines attachment methods using the Robots Exclusion Protocol and HTTP header fields. This document updates RFC 9309 to allow for the inclusion of usage preferences. | |||||||||||||
| draft-ietf-aipref-vocab-08.txt | ||||||||||||||
| A Vocabulary For Expressing AI Usage Preferences | ||||||||||||||
|
This document defines a vocabulary for expressing preferences regarding how digital assets are used by automated processing systems. This vocabulary allows for the declaration of restrictions or permissions for use of digital assets by such systems. | |||||||||||||
| draft-ietf-alto-oam-yang-18.txt | ||||||||||||||
| YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol | ||||||||||||||
|
This document defines a YANG data model for Operations, Administration, and Maintenance (OAM) & Management of the Application-Layer Traffic Optimization (ALTO) Protocol. The operator of an ALTO server can use this data model to (1) set up the ALTO server, (2) configure server discovery, (3) create, update and remove ALTO information resources, (4) manage the access control of each ALTO information resource, and (5) collect statistical data from the ALTO server. The application provider can also use this data model to configure ALTO clients to communicate with known ALTO servers. | |||||||||||||
| draft-ietf-anima-brski-cloud-19.txt | ||||||||||||||
| Bootstrapping Remote Secure Key Infrastructure (BRSKI) Cloud Registrar | ||||||||||||||
|
Bootstrapping Remote Secure Key Infrastructures (BRSKI) defines how to onboard a device securely into an operator-maintained infrastructure. It assumes that there is local network infrastructure for the device to discover. On networks without that, there is nothing present to help onboard the device. This document extends BRSKI and defines behavior for bootstrapping devices for deployments where no local infrastructure is available, such as in a home or remote office. This document defines how the device can use a well-defined "call-home" mechanism to find the operator-maintained infrastructure. This document defines how to contact a well-known Cloud Registrar, and two ways in which the device may be redirected towards the operator-maintained infrastructure. The Cloud Registrar enables discovery of the operator-maintained infrastructure, and may enable establishment of trust with operator-maintained infrastructure that does not support BRSKI mechanisms. This document updates RFC 8995 (BRSKI). | |||||||||||||
| draft-ietf-anima-brski-discovery-13.txt | ||||||||||||||
| BRSKI discovery and variations | ||||||||||||||
|
This document specifies procedures for variations of the "Bootstrapping Remote Secure Key Infrastructure" (BRSKI) series of protocols to automatically announce, discover and select responders using different discovery mechanisms such as DNS-SD, GRASP or CORE- LF. Different variations are not interoperable so initiators need to be able to find responders supporting the variation(s) they support. Procedures for BRSKI proxies are defined that allow proxying of traffic for any current and future variation. Procedures to discover BRSKI Pledges by their identifier are defined. All procedures are defined such that they rely on IANA defined tables through which not only well specified but also possible but not yet validated variations of BRSKI or additional discovery mechanisms can be supported simply by adding entries to the IANA tables. Many of the procedures and mechanisms covered by this document may equally be applied to discovery of other protocols, especially when they have non-interoperable variations. | |||||||||||||
| draft-ietf-anima-brski-prm-23.txt | ||||||||||||||
| BRSKI with Pledge in Responder Mode (BRSKI-PRM) | ||||||||||||||
|
This document defines enhancements to Bootstrapping Remote Secure Key Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder Mode (BRSKI-PRM). BRSKI-PRM supports the secure bootstrapping of devices, referred to as pledges, into a domain where direct communication with the registrar is either limited or not possible at all. To facilitate interaction between a pledge and a domain registrar the registrar-agent is introduced as new component. The registrar-agent supports the reversal of the interaction model from a pledge-initiated mode, to a pledge-responding mode, where the pledge is in a server role. To establish the trust relation between pledge and registrar, BRSKI-PRM relies on object security rather than transport security. This approach is agnostic to enrollment protocols that connect a domain registrar to a key infrastructure (e.g., domain Certification Authority). | |||||||||||||
| draft-ietf-anima-constrained-grasp-03.txt | ||||||||||||||
| Constrained GeneRic Autonomic Signaling Protocol | ||||||||||||||
|
This document proposes the Constrained GeneRic Autonomic Signaling Protocol (cGRASP), a constrained and lightweight variant of the GeneRic Autonomic Signaling Protocol (GRASP, or the standard GRASP). cGRASP reduces message overhead and replaces TCP with CoAP as the transport protocol. By leveraging CoAP's reliability features and deployment maturity, cGRASP can provide reliable signaling services without relying on TCP, making it suitable for IoT, where lightweight and resource-constrained devices dominate. Furthermore, this document also discusses the potential approaches to adapting the cGRASP to work on the network without IP connectivity. | |||||||||||||
| draft-ietf-anima-constrained-join-proxy-21.txt | ||||||||||||||
| Join Proxy for Onboarding of Constrained Network Elements | ||||||||||||||
|
This document supports the constrained Bootstrapping Remote Secure Key Infrastructures (cBRSKI) onboarding protocol by adding a required network function, the Join Proxy. This function can be implemented on a constrained node. The goal of the Join Proxy is to help new constrained nodes ("Pledges") securely onboard into a new IP network using the cBRSKI protocol. It acts as a circuit proxy for User Datagram Protocol (UDP) packets that carry the onboarding messages. The solution is extensible to support other UDP-based onboarding protocols as well. The Join Proxy functionality is designed for use in constrained networks, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) based networks in which the onboarding authority server ("Registrar") may be multiple IP hops away from a Pledge. Despite this distance, the Pledge only needs to use link-local communication to complete cBRSKI onboarding. Two modes of Join Proxy operation are defined, stateless and stateful, to allow different trade-offs regarding resource usage, implementation complexity and security. | |||||||||||||
| draft-ietf-anima-constrained-voucher-31.txt | ||||||||||||||
| Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) | ||||||||||||||
|
This document defines the Constrained Bootstrapping Remote Secure Key Infrastructure (cBRSKI) protocol, which provides a solution for secure zero-touch onboarding of resource-constrained (IoT) devices into the network of a domain owner. This protocol is designed for constrained networks, which may have limited data throughput or may experience frequent packet loss. cBRSKI is a variant of the BRSKI protocol, which uses an artifact signed by the device manufacturer called the "voucher" which enables a new device and the owner's network to mutually authenticate. While the BRSKI voucher data is encoded in JSON, cBRSKI uses a compact CBOR-encoded voucher. The BRSKI voucher data definition is extended with new data types that allow for smaller voucher sizes. The Enrollment over Secure Transport (EST) protocol, used in BRSKI, is replaced with EST-over- CoAPS; and HTTPS used in BRSKI is replaced with DTLS-secured CoAP (CoAPS). This document Updates RFC 8995 and RFC 9148. | |||||||||||||
| draft-ietf-anima-jws-voucher-16.txt | ||||||||||||||
| JWS signed Voucher Artifacts for Bootstrapping Protocols | ||||||||||||||
|
This document introduces a variant of the RFC8366 voucher artifact in which CMS is replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515. This supports deployments in which JOSE is preferred over CMS. In addition to specifying the format, the "application/voucher-jws+json" media type is registered and examples are provided. | |||||||||||||
| draft-ietf-anima-masa-considerations-03.txt | ||||||||||||||
| Operational Considerations for Voucher infrastructure for BRSKI MASA | ||||||||||||||
|
This document describes a number of operational modes that a BRSKI Manufacturer Authorized Signing Authority (MASA) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the MASA is deployed into. This document does not change any protocol mechanisms. | |||||||||||||
| draft-ietf-anima-registrar-considerations-03.txt | ||||||||||||||
| Operational Considerations for BRSKI Registrar | ||||||||||||||
|
This document describes a number of operational modes that a BRSKI Registration Authority (Registrar) may take on. Each mode is defined, and then each mode is given a relevance within an over applicability of what kind of organization the Registrar is deployed into. This document does not change any protocol mechanisms. This document includes operational advice about avoiding unwanted consequences. | |||||||||||||
| draft-ietf-anima-rfc8366bis-36.txt | ||||||||||||||
| A Voucher Artifact for Onboarding Protocols | ||||||||||||||
|
This document defines a strategy to securely assign a candidate device (Pledge) to an Owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "Voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The Voucher Artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document obsoletes RFC8366: it includes a number of desired extensions into the YANG module. The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of RFC8995. | |||||||||||||
| draft-ietf-asdf-digital-twin-05.txt | ||||||||||||||
| Semantic Definition Format (SDF) Modeling for Digital Twin | ||||||||||||||
|
This memo specifies SDF modeling for digital twins, i.e., digital twin systems, and their things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of things, i.e. physical objects, in digital twins that contain things as components. | |||||||||||||
| draft-ietf-asdf-nipc-22.txt | ||||||||||||||
| An Application Layer Interface for Non-Internet-connected Physical Components (NIPC) | ||||||||||||||
|
This document describes an API that allows applications to perform operations against a gateway serving one or more devices described by an SDF model. The API consists of a RESTful application layer interface that performs operations on those devices, as well as a CBOR-based publish-subscribe interface for streaming data. | |||||||||||||
| draft-ietf-asdf-sdf-nonaffordance-05.txt | ||||||||||||||
| Semantic Definition Format (SDF) Extension for Non-Affordance Information | ||||||||||||||
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class keyword, sdfContext, that enables comprehensive modeling of Things and improves semantic clarity. | |||||||||||||
| draft-ietf-asdf-sdf-protocol-mapping-12.txt | ||||||||||||||
| SDF Protocol Mapping | ||||||||||||||
|
This document defines protocol mapping extensions for the Semantic Definition Format (SDF) to enable mapping of protocol-agnostic SDF affordances to protocol-specific operations. The protocol mapping mechanism allows SDF models to specify how properties, actions, and events should be accessed using a specific protocol. This document defines protocol mappings for Bluetooth Low Energy and Zigbee, and the mechanism can be extended to other protocols such as HTTP and CoAP. This document also describes a method to extend SCIM with an SDF model mapping. | |||||||||||||
| draft-ietf-asdf-sdftype-link-02.txt | ||||||||||||||
| An sdfType for Links | ||||||||||||||
|
This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). | |||||||||||||
| draft-ietf-avtcore-frame-acknowledgement-01.txt | ||||||||||||||
| RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement | ||||||||||||||
|
This document describes a mechanism for signaling which video frames have been received and decoded by a remote peer. It comprises an RTCP feedback message and an RTP header extension used to request said feedback. One of the main use cases for this data is to implement various forms of Long Term Reference (LTR) reference structures. Additionally, the mechanism provides a way for receivers to request resynchronization frames that reference acknowledged frames, enabling efficient recovery from partial or full frame loss without requiring a full keyframe. | |||||||||||||
| draft-ietf-avtcore-hevc-webrtc-09.txt | ||||||||||||||
| H.265 Profile for WebRTC | ||||||||||||||
|
RFC 7742 defines WebRTC video processing and codec requirements, including guidance for endpoints supporting the VP8 and H.264 codecs, which are mandatory to implement. This document defines a profile of RFC 7798 for browsers supporting the H.265 codec. | |||||||||||||
| draft-ietf-avtcore-rtcp-green-metadata-17.txt | ||||||||||||||
| RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution | ||||||||||||||
|
The RTCP messages specified in this document enable receivers to provide feedback to the senders and thus allow for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The messages have broad applicability in point-to-point real-time video communication services. Specifically, the messages can be used to convey the video decoder feedback metadata to the encoder to adapte the decoder energy consumption as defined in the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC29/WG3 MPEG Systems. | |||||||||||||
| draft-ietf-avtcore-rtp-avatar-02.txt | ||||||||||||||
| RTP Payload Format for Avatar Representation Format (ARF) Animation Stream | ||||||||||||||
|
This memo outlines RTP payload formats for the animation stream format as defined in the ISO/IEC 23090-39 standard (MPEG-I Avatar Representation Format), in the following referred to as ARF. ARF is composed of Avatar Animation Units (AAU) including an AAU header and zero or more AAU packets. The RTP payload header format allows for packetization of an AAU unit in an RTP packet payload as well as fragmentation of an AAU into multiple RTP packets. | |||||||||||||
| draft-ietf-avtcore-rtp-jpegxs-3ed-07.txt | ||||||||||||||
| RTP Payload Format for ISO/IEC 21122 (JPEG XS) | ||||||||||||||
|
This document specifies a Real-Time Transport Protocol (RTP) payload format for transport of a video signal encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency and low-complexity video coding system. Employing this format allows achieving encoding-decoding latencies confined to a fraction of a video frame. This document revises RFC 9134 to incorporate support for new features introduced in the third edition of JPEG XS. Most notably, it contains the necessary provisions to support the TDC coding mode. This document obsoletes RFC 9134; however, the revised payload format is designed to ensure that existing conforming implementations of RFC 9134 remain valid under the updated specification. Additionally, this document consolidates the errata of RFC 9134 and includes improvements and clarifications for implementers and users. | |||||||||||||
| draft-ietf-avtcore-rtp-vdmc-03.txt | ||||||||||||||
| RTP Payload Format for V-DMC | ||||||||||||||
|
This memo outlines RTP payload formats for the Video-based Dynamic Mesh Coding (V-DMC), which comprises several types of components, such as a basemesh, AC-based displacements, 2D representations of attributes, and an atlas. This document focuses on describing the basemesh and displacement, while the RTP payload formats for the atlas and attributes are addressed in other documents. The RTP payload header formats enable the packetization of a basemesh or displacement Network Abstraction Layer (NAL) unit in an RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. | |||||||||||||
| draft-ietf-bess-bgp-multicast-controller-18.txt | ||||||||||||||
| Controller-based BGP Multicast Signaling | ||||||||||||||
|
This document specifies a way that one or more centralized controllers can use BGP to set up multicast distribution trees (identified by either IP source/destination address pair, or mLDP FEC) in a network. Since the controllers calculate the trees, they can use sophisticated algorithms and constraints to achieve traffic engineering. The controllers directly signal dynamic replication state to tree nodes, leading to very simple multicast control plane on the tree nodes, as if they were using static routes. This can be used for both underlay and overlay multicast trees, including replacing BGP-MVPN signaling. | |||||||||||||
| draft-ietf-bess-bgp-sdwan-usage-37.txt | ||||||||||||||
| BGP Usage for SD-WAN Overlay Networks | ||||||||||||||
|
This document illustrates how a BGP-based control plane can be used to manage large scale Software Defined WAN (SD-WAN) overlay networks by distributing edge service reachability information, WAN port attributes, and underlay path details, thereby minimizing manual provisioning. In such deployments, BGP can provide a standards-based mechanism for distributing information that may otherwise be exchanged using proprietary SD-WAN control-plane mechanisms. However, extensions to BGP are needed to achieve that goal. | |||||||||||||
| draft-ietf-bess-ebgp-dmz-11.txt | ||||||||||||||
| BGP link bandwidth extended community use cases | ||||||||||||||
|
BGP link bandwidth extended community provides a way to signal a value along with a BGP path that can be used to perform weighted load-balancing in multipath scenarios. This document details various use cases of the BGP link bandwidth extended community. It also describes local mechanisms to dynamically adjust the BGP link bandwidth value or the multipath weights based on different considerations. | |||||||||||||
| draft-ietf-bess-evpn-ac-aware-bundling-06.txt | ||||||||||||||
| AC-Aware Bundling Service Interface in EVPN | ||||||||||||||
|
An EVPN (Ethernet VPNs) provides an extensible and flexible multihoming VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. EVPN multihoming with Integrated Routing and Bridging (IRB) is one of the common deployment scenarios. Some deployments requires the capability to have multiple subnets designated with multiple VLAN IDs in the single broadcast domain. EVPN technology defines three different types of service interface which serve different requirements but none of them address the requirement of supporting multiple subnets within a single broadcast domain. In this document, we define a new service interface type to support multiple subnets in the single broadcast domain. Service interface proposed in this document will be applicable to multihoming cases only. | |||||||||||||
| draft-ietf-bess-evpn-bfd-20.txt | ||||||||||||||
| EVPN Network Layer Fault Management | ||||||||||||||
|
This document specifies proactive, in-band Network Layer OAM (RFC 9062) mechanisms to detect loss of continuity faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (EVPN, RFC 7432bis) network. The mechanisms specified in this document use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol. | |||||||||||||
| draft-ietf-bess-evpn-first-hop-security-01.txt | ||||||||||||||
| EVPN First Hop Security | ||||||||||||||
|
The Dynamic Host Configuration Protocol (DHCP) snoop database stores valid IPv4-to-MAC and IPv6-to-MAC bindings by snooping on DHCP messages. These bindings are used by security functions like Dynamic Address Resolution Protocol Inspection (DAI), Neighbor Discovery Inspection (NDI), IPv4 Source Guard, and IPv6 Source Guard to safeguard against traffic received with a spoofed address. These functions are collectively referred to as First Hop Security (FHS). This document proposes BGP extensions and new Ethernet VPN (EVPN) procedures to distribute and synchronize the DHCP snoop database to support FHS. Such synchronization is needed to support EVPN host mobility and multihoming. | |||||||||||||
| draft-ietf-bess-evpn-ip-mac-proxy-adv-00.txt | ||||||||||||||
| Proxy MAC-IP Advertisement in EVPNs | ||||||||||||||
|
This document specifies procedures for EVPN PEs connected to a common multihomed site to generate proxy EVPN MAC-IP advertisements on behalf of other PEs to facilitate preservation of ARP/ND state across link or node failures. | |||||||||||||
| draft-ietf-bess-evpn-l3mh-proto-01.txt | ||||||||||||||
| EVPN multi-homing support for L3 services | ||||||||||||||
|
This document describes the use of EVPN Ethernet Segment Link Aggregation Group (ES-LAG) technology to provide multi-homing redundancy for Layer 3 services. The solution synchronizes ARP/ND, multicast state, and IGP routes between redundant PEs without requiring Layer 2 constructs or proprietary Inter-Chassis Communication protocols. | |||||||||||||
| draft-ietf-bess-evpn-mvpn-seamless-interop-11.txt | ||||||||||||||
| Seamless Multicast Interoperability between EVPN and MVPN PEs | ||||||||||||||
|
Ethernet Virtual Private Network (EVPN) solution is becoming pervasive for Network Virtualization Overlay (NVO) services in data center (DC), Enterprise networks as well as in service provider (SP) networks. As service providers transform their networks in their Central Offices (COs) towards the next generation data center with Software Defined Networking (SDN) based fabric and Network Function Virtualization (NFV), they want to be able to maintain their offered services including Multicast VPN (MVPN) service between their existing network and their new Service Provider Data Center (SPDC) network seamlessly without the use of gateway devices. They want to have such seamless interoperability between their new SPDCs and their existing networks for a) reducing cost, b) having optimum forwarding, and c) reducing provisioning. This document describes a unified solution based on RFCs 6513 & 6514 for seamless interoperability of Multicast VPN between EVPN and MVPN PEs. Furthermore, it describes how the proposed solution can be used as a routed multicast solution in data centers with only EVPN PEs. | |||||||||||||
| draft-ietf-bess-evpn-umr-mobility-01.txt | ||||||||||||||
| Applications and Procedures for the Unknown MAC Route in EVPN | ||||||||||||||
|
The Interconnect Solution for Ethernet VPN defines Unknown MAC (Media Access Control) Route (UMR) utilization for Data Center Interconnect (DCI) when EVPN MPLS or EVPN VXLAN is used as an overlay network for such interconnects. The use of UMR has implications for EVPN MAC mobility procedures, for EVPN Layer 2 and IRB operations, and for EVPN Proxy ARP/ND operations. This document describes additional enhancements required to EVPN procedures and operations when using UMR. This document updates RFC9014 to clarify and extend the procedures for UMR usage. | |||||||||||||
| draft-ietf-bess-evpn-unequal-lb-35.txt | ||||||||||||||
| Weighted Multi-Path Procedures for EVPN Multi-Homing | ||||||||||||||
|
Ethernet VPN (EVPN) provides all-active multi-homing for Customer Equipment (CE) devices connected to multiple Provider Edge (PE) devices, enabling equal cost load balancing of both bridged and routed traffic across the set of multi-homing PEs. However, existing procedures implicitly assume equal access bandwidth distribution among the multi-homing PEs, which can constrain link additions or removals and may not handle unequal PE-CE link bandwidth following link failures. This document specifies extensions to EVPN procedures to support weighted multi-pathing in proportion to PE-CE link bandwidth or operator-defined weights, thereby providing greater flexibility and resilience in multi-homing deployments. The extensions include signaling mechanisms to distribute traffic across egress PEs based on relative bandwidth or weight, and enhancements to Broadcast, Unknown Unicast, and Multicast (BUM) designated forwarder (DF) election to achieve weighted DF distribution across the multi- homing PE set. | |||||||||||||
| draft-ietf-bess-extended-evpn-optimized-ir-09.txt | ||||||||||||||
| Extended Procedures for EVPN Optimized Ingress Replication | ||||||||||||||
|
In the Virtualization Overlay (NVO) network with Ethernet VPN (EVPN), optimized ingress replication uses Assisted-Replication (AR) to achieve more efficient delivery of Broadcast and Multicast (BM) traffic. An AR-LEAF, which is a Network Virtualization Edge (NVE) device, forwards received BM traffic from its tenant system to an AR- REPLICATOR. The AR-REPLICATOR then replicates it to the remaining AR-LEAFs in the network. However, when replicating the packet on behalf of its multihomed AR-LEAF, an AR-REPLICATOR may face challenges in retaining the source IP address or including the expected Ethernet Segment Identifier (ESI) label that is required for EVPN split-horizon filtering. This document extends the optimized ingress replication procedures to address such limitations. The extended procedures specified in this document allow the support of EVPN multihoming on the AR-LEAFs as well as optimized ingress replication for the rest of the EVPN NVO network. | |||||||||||||
| draft-ietf-bess-mup-safi-01.txt | ||||||||||||||
| BGP Extensions for the Mobile User Plane (MUP) SAFI | ||||||||||||||
|
This document defines a new SAFI known as a BGP Mobile User Plane (BGP-MUP) SAFI to support MUP Extensions and a extended community for BGP. This document also provides BGP signaling and procedures for the new SAFI to convert mobile session information into appropriate IP forwarding information. These extensions can be used by operators between a PE, and a Controller for integrating mobile user plane into BGP MUP network using the IP based routing. | |||||||||||||
| draft-ietf-bess-rfc6514bis-00.txt | ||||||||||||||
| BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs | ||||||||||||||
|
RFC 6514 describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. This document updates and obsoletes RFC 6514. The original authors of RFC 6514 are listed at the end of this document. | |||||||||||||
| draft-ietf-bess-vpls-multihoming-07.txt | ||||||||||||||
| BGP based Multi-homing in Virtual Private LAN Service | ||||||||||||||
|
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. | |||||||||||||
| draft-ietf-bfd-rfc5880bis-01.txt | ||||||||||||||
| Bidirectional Forwarding Detection (BFD) | ||||||||||||||
|
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. This document obsoletes RFC 5880. | |||||||||||||
| draft-ietf-bfd-rfc5881bis-01.txt | ||||||||||||||
| Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) | ||||||||||||||
|
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. This document obsoletes RFC 5881. | |||||||||||||
| draft-ietf-bfd-rfc5882-bis-02.txt | ||||||||||||||
| Generic Application of Bidirectional Forwarding Detection (BFD) | ||||||||||||||
|
This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. This document obsoletes RFC 5882. | |||||||||||||
| draft-ietf-bfd-rfc5883-bis-02.txt | ||||||||||||||
| Bidirectional Forwarding Detection (BFD) for Multihop Paths | ||||||||||||||
|
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. This document obsoletes RFC 5883. | |||||||||||||
| draft-ietf-bfd-rfc5884-bis-01.txt | ||||||||||||||
| Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) | ||||||||||||||
|
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination of LSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. This document obsoletes RFC5884 and RFC7726. | |||||||||||||
| draft-ietf-bier-bfd-11.txt | ||||||||||||||
| BIER BFD | ||||||||||||||
|
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network. | |||||||||||||
| draft-ietf-bier-bierin6-14.txt | ||||||||||||||
| Supporting BIER in IPv6 Networks (BIERin6) | ||||||||||||||
|
BIER is a multicast forwarding architecture that does not require per-flow state inside the network yet still provides optimal replication. This document describes how the existing BIER encapsulation specified in RFC 8296 works in a non-MPLS IPv6 network, which is referred to as BIERin6. Specifically, like in an IPv4 network, BIER can work over L2 links directly or over tunnels. In case of IPv6 tunneling, a new IP "Next Header" type is to be assigned for BIER. | |||||||||||||
| draft-ietf-bier-frr-14.txt | ||||||||||||||
| A Framework for Fast Reroute with Bit Index Explicit Replication (BIER-FRR) | ||||||||||||||
|
This document provides a framework for the development of Fast Reroute (FRR) mechanisms for Bit Index Explicit Replication forwarding (BIER-FRR). BIER-FRR can provide protection against link or BFR failure by invoking locally pre-determined repair paths that can react in the same time-scales as (unicast) FRR for MPLS or IP networks - "sub 50msec", and without the creation of additional per- path or per-flow state coordinated across multiple routers/LSR. BIER-FRR can be implemed locally within a router/LSR with minimal interoperability requirements against other router/LSR. It can therefore easily be introduced incrementally or selectively where needed. BIER-FRR implementing nodes only need to understand the routing topology of the network for calculation of repair paths and know what type of unicast encapsulation can be used to send ("tunnel") BIER packets to remote BFR. This document proposes and discusses different options for BIER forwardng (BIFT) extensions to support BIER-FRR. These are exemplary and non-normative. This document does not specify any standards or experiments but aims to support such efforts. | |||||||||||||
| draft-ietf-bier-ospfv3-extensions-10.txt | ||||||||||||||
| OSPFv3 Extensions for BIER | ||||||||||||||
|
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. The BIER architecture uses MPLS or other encapsulations to steer the multicast traffic towards the receivers. This document describes the OSPFv3 protocol extensions required for BIER with MPLS encapsulation. Support for other encapsulation types is outside the scope of this document. | |||||||||||||
| draft-ietf-bier-php-16.txt | ||||||||||||||
| BIER Penultimate Hop Popping | ||||||||||||||
|
This document specifies a mechanism for Penultimate Hop Popping (PHP) in the Bit Index Explicit Replication (BIER) architecture. PHP enables the removal of the BIER header by the penultimate router, thereby reducing the processing burden on the final router in the delivery path. This extension to BIER enhances operational efficiency by optimizing packet forwarding in scenarios where the final hop's capabilities or requirements necessitate such handling. The document details the necessary extensions to the BIER encapsulation and forwarding processes to support PHP, providing guidance for implementation and deployment within BIER-enabled networks. | |||||||||||||
| draft-ietf-bier-ping-27.txt | ||||||||||||||
| Bit Index Explicit Replication (BIER) Ping and Trace | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-bier-prefix-redistribute-11.txt | ||||||||||||||
| BIER Prefix Redistribute | ||||||||||||||
|
This document defines a BIER proxy function to support one single BIER sub-domain over multiple underlay routing protocol regions (Autonomous Systems or IGP areas). A new BIER proxy range sub-TLV is defined to redistribute BIER BFR-id information across the routing regions. | |||||||||||||
| draft-ietf-bier-source-protection-10.txt | ||||||||||||||
| BIER (Bit Index Explicit Replication) Redundant Ingress Router Failover | ||||||||||||||
|
This document describes a failover in the Bit Index Explicit Replication domain with a redundant ingress router. | |||||||||||||
| draft-ietf-bmwg-containerized-infra-09.txt | ||||||||||||||
| Considerations for Benchmarking Network Performance in Containerized Infrastructures | ||||||||||||||
|
Recently, the Benchmarking Methodology Working Group extended the laboratory characterization from physical network functions (PNFs) to virtual network functions (VNFs). With the ongoing shift in network function implementation from virtual machine-based to container-based approaches, system configurations and deployment scenarios for benchmarking will be partially influenced by how resource allocation and network technologies are specified for containerized network functions. This draft outlines additional considerations for benchmarking network performance when network functions are containerized and executed on general-purpose hardware. | |||||||||||||
| draft-ietf-bmwg-network-tester-cfg-17.txt | ||||||||||||||
| A YANG Data Model for Network Tester Management | ||||||||||||||
|
This document specifies a YANG data model for use in network interconnect testing setups that contain instances of traffic generator and traffic analyzer. | |||||||||||||
| draft-ietf-bmwg-powerbench-02.txt | ||||||||||||||
| Characterization and Benchmarking Methodology for Power in Networking Devices | ||||||||||||||
|
This document defines a standard mechanism to measure, report, and compare power usage of different networking devices under different network configurations and conditions. | |||||||||||||
| draft-ietf-bmwg-savnet-sav-benchmarking-04.txt | ||||||||||||||
| Benchmarking Methodology for Intra-domain and Inter-domain Source Address Validation | ||||||||||||||
|
This document defines methodologies for benchmarking the performance of intra-domain and inter-domain source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules that prevent source address spoofing. The methodology treats a SAV device as a black box and is therefore agnostic to the specific SAV mechanism and implementation used by the device. This document defines test setups, performance indicators, and test cases for SAV accuracy, control-plane and data-plane performance, and resource utilization. | |||||||||||||
| draft-ietf-bmwg-sr-bench-meth-08.txt | ||||||||||||||
| Benchmarking Methodology for Segment Routing (SR) | ||||||||||||||
|
This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR- MPLS). | |||||||||||||
| draft-ietf-calext-ical-tasks-17.txt | ||||||||||||||
| Task Extensions to iCalendar | ||||||||||||||
|
The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) VTODO calendar component has seen limited adoption and use, mainly for personal reminders and to-do lists. This document updates and defines extensions to VTODO to provide improved status tracking, scheduling and specification of tasks to allow its use in other contexts, such as process control and project management. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. | |||||||||||||
| draft-ietf-calext-icalendar-jscalendar-extensions-08.txt | ||||||||||||||
| iCalendar Format Extensions for JSCalendar | ||||||||||||||
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("iCalendar") and its extension documents RFC 7986 and RFC 9073. | |||||||||||||
| draft-ietf-calext-jscalendar-icalendar-28.txt | ||||||||||||||
| JSCalendar: Converting from and to iCalendar | ||||||||||||||
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. This document updates RFC 5545 ("iCalendar") and jscalendarbis ("JSCalendar") by defining new properties and parameters for JSCalendar and iCalendar conversion. | |||||||||||||
| draft-ietf-calext-jscalendarbis-20.txt | ||||||||||||||
| JSCalendar 2.0: A JSON Representation of Calendar Data | ||||||||||||||
|
This specification defines version "2.0" of JSCalendar, a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. This document obsoletes RFC 8984, also referred to as version "1.0" in this document. The newly defined version "2.0" aims to improve interoperability with existing iCalendar-based systems. It also aligns its definitions with JSContact, such as the IANA registry policy, validation requirements, and versioning scheme. | |||||||||||||
| draft-ietf-calext-jscontact-cryptographic-key-01.txt | ||||||||||||||
| JSContact Cryptographic Key Extensions | ||||||||||||||
|
Extensions to the JSContact data model for contact card data are defined to improve support for describing cryptographic credentials to be used with applications and services by specifying which credential is used for which online service. This allows a contact application to identify the specific credential to be used with an application without the need for the contact application to understand the syntax or semantics of the credential used. An additional extension allows a contact to specify one of more mechanisms for obtaining updates to itself with optional verification under specified signature keys. The mechanisms used are outside the scope of this document. These features in combination provide a basis for establishing and maintaining peer-to-peer trust. | |||||||||||||
| draft-ietf-calext-jscontact-profiles-15.txt | ||||||||||||||
| Protocol-Specific Profiles for JSContact | ||||||||||||||
|
This document defines JSContact profiles, an IANA registry for named subsets of JSContact elements. It aims to facilitate using JSContact in context of contact data exchange protocols or other use cases, in which supporting all JSContact semantics might be inappropriate. | |||||||||||||
| draft-ietf-calext-rfc9555bis-01.txt | ||||||||||||||
| JSContact: Converting from and to vCard | ||||||||||||||
|
This document defines how to convert contact information between the JSContact and vCard data formats. It defines conversion rules for every JSContact and vCard element registered at IANA at the time of publication. It also defines new JSContact properties as well as vCard properties and parameters, to support converting arbitrary or unknown JSContact and vCard elements. This document obsoletes RFC 9555 and updates its definitions for JSContact version "2.0". Note This note is to be removed before publishing as an RFC. Differences from RFC 9555 are documented in Appendix A. | |||||||||||||
| draft-ietf-calext-vcard4-bis-00.txt | ||||||||||||||
| vCard Format Specification | ||||||||||||||
|
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFC 6350. | |||||||||||||
| draft-ietf-cats-framework-24.txt | ||||||||||||||
| A Framework for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document describes a framework for Computing-Aware Traffic Steering (CATS). Specifically, the document identifies a set of CATS functional components, describes their interactions, and provides illustrative workflows of the control and data planes. The framework covers only the case of a single service provider. | |||||||||||||
| draft-ietf-cats-metric-definition-11.txt | ||||||||||||||
| CATS Metrics Definition | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a service instance by considering the dynamic state of computing and network resources. To enable such decisions, CATS components exchange metrics that describe resource conditions affecting service instance selection. This document focuses on compute and communication metrics for CATS and defines a hierarchical abstraction of these metrics to improve interoperability, scalability, and operational simplicity. It does not aim to standardize raw infrastructure (Level 0) metrics; instead, it specifies higher-level representations that can be derived from raw measurements using aggregation and normalization functions. | |||||||||||||
| draft-ietf-cats-oam-fw-01.txt | ||||||||||||||
| Computing-Aware Traffic Steering (CATS) Operations,Administration,and Maintenance (OAM) Framework | ||||||||||||||
|
This document describes the Operations, Administration, and Maintenance (OAM) framework and requirements for Computing-Aware Traffic Steering (CATS). The framework defines the CATS OAM layering model and functional components. It also specifies the requirements to enable fault management and performance monitoring for CATS end- to-end connections across clients, network paths, and service instances. | |||||||||||||
| draft-ietf-cats-usecases-requirements-14.txt | ||||||||||||||
| Computing-Aware Traffic Steering (CATS) Problem Statement,Use Cases,and Requirements | ||||||||||||||
|
Distributed computing enhances service response time and energy efficiency by utilizing diverse computing facilities for compute- intensive and delay-sensitive services. To optimize throughput and response time, "Computing-Aware Traffic Steering" (CATS) selects servers and directs traffic based on compute capabilities and resources, rather than static dispatch or connectivity metrics alone. This document outlines the problem statement and scenarios for CATS within a single domain, and drives requirements for the CATS framework. | |||||||||||||
| draft-ietf-cbor-cddl-modules-07.txt | ||||||||||||||
| CDDL Module Structure | ||||||||||||||
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165 and RFC 9741. The latter two have used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. | |||||||||||||
| draft-ietf-cbor-edn-literals-27.txt | ||||||||||||||
| Concise Diagnostic Notation (CDN) | ||||||||||||||
|
This document formalizes and consolidates the definition of the Concise Diagnostic Notation (CDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing CDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies registry-based extension points and uses them to support text representations such as of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) This is the // editorial round focusing on editorial cleanup, specifically where // that causes moving text around. It does not have WG input yet on // any renaming decisions (CDN name, b1/t1 name), ABNF cleanup, or // Rohan's suggestion to fix the questionable figure in 3.8. | |||||||||||||
| draft-ietf-cbor-serialization-08.txt | ||||||||||||||
| CBOR Serialization and Determinism | ||||||||||||||
|
This document defines two CBOR serializations: "preferred-plus serialization" and "deterministic serialization." It also introduces the term "general serialization" to name the complete set of all serializations defined in RFC 8949. Together, these three form a set of serializations that cover the majority of CBOR serialization use cases. These serializations are largely compatible with those widely implemented by the CBOR community. | |||||||||||||
| draft-ietf-ccamp-actn-optical-transport-mgmt-05.txt | ||||||||||||||
| Integrating YANG Configuration and Management into an Abstraction and Control of TE Networks (ACTN) System for Optical Networks | ||||||||||||||
|
Many network technologies are operated as Traffic Engineering (TE) networks. Optical networks are a particular case, and have complex technology-specific details. Abstraction and Control of TE Networks (ACTN) is a management architecture that abstracts TE network resources to provide a limited network view for customers to request and self-manage connectivity services. It also provides functional components to orchestrate and operate the network. Management of legacy optical networks is often provided via Fault, Configuration, Accounting, Performance, and Security (known as FCAPS) using mechanisms such as the Multi-Technology Operations System Interface (MTOSI) and the Common Object Request Broker Architecture (CORBA). FCAPS can form a critical part of configuration management and service assurance for network operations. However, the ACTN architecture as described in RFC 8453 does not include consideration of FCAPS. This document enhances the ACTN architecture as applied to optical networks by introducing support for detailed YANG Configuration and Management, effectively adding support for FCAPS. It considers which elements of existing IETF YANG work can be used to solve existing scenarios and emerging technologies, and what new work may be needed. In doing so, this document adds rich-detail network management (RDNM) to the ACTN architecture. This enhanced architecture may then be used to evolve networks from CORBA and MTOSI FCAPS interfaces to IETF-based YANG and RESTful APIs. | |||||||||||||
| draft-ietf-ccamp-client-signal-yang-18.txt | ||||||||||||||
| A YANG Data Model for Transport Network Client Signals | ||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. The topology and tunnel information in the transport layer has already been defined by generic Traffic- engineered models and technology-specific models (e.g., OTN, WSON). However, how the client signals are accessing to the network has not been described. These information is necessary to both client and provider. This draft describes how the client signals are carried over transport network and defines YANG data models which are required during configuration procedure. More specifically, several client signal (of transport network) models including ETH, STM-n, FC and so on, are defined in this draft. | |||||||||||||
| draft-ietf-ccamp-dwdm-if-param-yang-16.txt | ||||||||||||||
| A YANG data model to manage configurable DWDM optical interfaces | ||||||||||||||
|
This document defines a YANG model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple Forward Error Correction (FEC) codes including some not yet specified (or in phase of specification by) ITU-T G.698.2 or any other ITU-T recommendation. Use cases are described in RFC7698. The YANG model defined in this document can be used for Optical Parameters monitoring and/or configuration of Dense Wavelength Division Multiplexing (DWDM) interfaces. The use of this model does not guarantee interworking of DWDM transceivers. Optical path feasibility and interoperability has to be determined by tools and algorithms outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers. | |||||||||||||
| draft-ietf-ccamp-eth-client-te-topo-yang-11.txt | ||||||||||||||
| A YANG Data Model for Ethernet TE Topology | ||||||||||||||
|
This document describes a YANG data model for Ethernet networks when used either as a client-layer network of an underlay transport network (e.g., an Optical Transport Network (OTN)) or as a transport network itself. | |||||||||||||
| draft-ietf-ccamp-fgotn-yang-01.txt | ||||||||||||||
| YANG Data Models for fine grain Optical Transport Network | ||||||||||||||
|
This document defines YANG data models to describe the topology and tunnel information of a fine grain Optical Transport Network. The YANG data models defined in this document are designed to meet the requirements for efficient transmission of sub-1Gbit/s client signals in transport network. | |||||||||||||
| draft-ietf-ccamp-flexe-yang-cm-09.txt | ||||||||||||||
| YANG Data Model for FlexE Management | ||||||||||||||
|
This document defines a service provider targeted YANG data model for the configuration and management of a Flex Ethernet (FlexE) network, including FlexE group and FlexE client. | |||||||||||||
| draft-ietf-ccamp-flexigrid-yang-19.txt | ||||||||||||||
| A YANG Data Model for Flexi-Grid Optical Networks | ||||||||||||||
|
This document defines a YANG module for managing flexi-grid optical networks. The model defined in this document specifies a flexi-grid traffic engineering database that is used to describe the topology of a flexi-grid network. It is based on and augments existing YANG models that describe network and traffic engineering topologies. | |||||||||||||
| draft-ietf-ccamp-l1csm-yang-28.txt | ||||||||||||||
| A YANG Data Model for L1 Connectivity Service Model (L1CSM) | ||||||||||||||
|
This document provides a YANG Layer 1 Connectivity Service Model (L1CSM). This model can be utilized by a customer network controller to initiate a connectivity service request as well as to retrieve service states for a Layer 1 network controller communicating with its customer network controller. | |||||||||||||
| draft-ietf-ccamp-layer1-types-20.txt | ||||||||||||||
| Common YANG Data Types for Layer 1 Networks | ||||||||||||||
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. | |||||||||||||
| draft-ietf-ccamp-optical-impairment-topology-yang-24.txt | ||||||||||||||
| A YANG Data Model for Optical Impairment-aware Topology | ||||||||||||||
|
Provisioning an optical connection requires that path continuity, resource availability, and impairment constraints be satisfied in order to determine viable paths through the network. This process is known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in Wavelength Switched Optical Networks (WSONs) and as Impairment- Aware Routing and Spectrum Assignment (IA-RSA) in Spectrum Switched Optical Networks (SSONs). This document defines a YANG data model for impairment-aware Traffic Engineering (TE) topologies in optical networks. The model augments the technology-agnostic YANG data model for TE topologies and provides read-only topology information, including optical impairments. Such information can be used, for example, by a Path Computation Engine (PCE) to compute optically feasible paths prior to connection establishment. | |||||||||||||
| draft-ietf-ccamp-optical-path-computation-yang-09.txt | ||||||||||||||
| YANG Data Models for requesting Path Computation in WDM Optical Networks | ||||||||||||||
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. | |||||||||||||
| draft-ietf-ccamp-otn-path-computation-yang-09.txt | ||||||||||||||
| A YANG Data Model for requesting Path Computation in an Optical Transport Network (OTN) | ||||||||||||||
|
This document provides a mechanism to request path computation in an Optical Transport Network (OTN) by augmenting the Remote Procedure Calls (RPCs) defined in RFC YYYY. | |||||||||||||
| draft-ietf-ccamp-otn-topo-yang-21.txt | ||||||||||||||
| A YANG Data Model for Optical Transport Network Topology | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating Optical Transport Network (OTN) topologies. It is independent of control plane protocols and captures topological and resource-related information pertaining to OTN. | |||||||||||||
| draft-ietf-ccamp-otn-tunnel-model-26.txt | ||||||||||||||
| A YANG Data Model for Optical Transport Network (OTN) Tunnels and Label Switched Paths | ||||||||||||||
|
This document describes the YANG data model for tunnels in OTN TE networks. The model can be used to do the configuration in order to establish the tunnel in OTN network. This work is independent with the control plane protocols. | |||||||||||||
| draft-ietf-ccamp-rfc9093-bis-20.txt | ||||||||||||||
| Common YANG Data Types for Layer 0 Optical Networks | ||||||||||||||
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These common types and groupings, derived from the built-in YANG data types, identities, and groupings are intended to be imported by modules that model Optical Layer 0 configuration and state capabilities, such as Wavelength Switched Optical Networks (WSONs) and flexi-grid Dense Wavelength Division Multiplexing (DWDM) networks. This document obsoletes RFC 9093 by replacing the YANG module it contained with a new revision that includes additional YANG data types, identities and groupings. | |||||||||||||
| draft-ietf-ccamp-wdm-tunnel-yang-08.txt | ||||||||||||||
| A YANG Data Model for WDM Tunnels | ||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels and Label Switched Paths (LSPs) in Optical Networks (Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks). The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-ccamp-yang-otn-slicing-12.txt | ||||||||||||||
| Framework and Data Model for OTN Network Slicing | ||||||||||||||
|
The requirement of slicing network resources with desired quality of service is emerging at every network technology, including the Optical Transport Networks (OTN). As a part of the transport network, OTN can provide hard pipes with guaranteed data isolation and deterministic low latency, which are highly demanded in the Service Level Agreement (SLA). This document describes a framework for OTN network slicing and defines YANG data models with OTN technology-specific augments deployed at both the north and south bound of the OTN network slice controller. Additional YANG data model augmentations will be defined in a future version of this draft. | |||||||||||||
| draft-ietf-ccwg-bbr-06.txt | ||||||||||||||
| BBR Congestion Control | ||||||||||||||
|
This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC9438], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC9293] and QUIC [RFC9000]. This document specifies version 3 of the BBR algorithm, BBRv3. | |||||||||||||
| draft-ietf-ccwg-ratelimited-increase-11.txt | ||||||||||||||
| Increase of the Congestion Window when the Sender Is Rate-Limited | ||||||||||||||
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFCs 4341, 5681, 9002, 9260, and 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. | |||||||||||||
| draft-ietf-ccwg-rfc8298bis-screamv2-01.txt | ||||||||||||||
| Self-Clocked Rate Adaptation for Multimedia | ||||||||||||||
|
This memo describes Self-Clocked Rate Adaptation for Multimedia version 2 (SCReAMv2), an update to SCReAM congestion control for media streams such as RTP [RFC3550]. SCReAMv2 includes several algorithm simplifications and adds support for L4S. The algorithm supports handling of multiple media streams, typical use cases are streaming for remote control, AR and 3D VR goggles. This specification obsoletes RFC 8298. | |||||||||||||
| draft-ietf-cdni-cache-control-metadata-06.txt | ||||||||||||||
| CDNI Cache Control Metadata | ||||||||||||||
|
This specification adds new Cache Control objects that complement the basic Cache Control Metadata object defined in RFC8006, providing content providers and upstream Content Delivery Networks (uCDNs) more fine-grained control over downstream CDN (dCDN) caching. Use cases include overriding or adjusting cache control headers from the Content Service Provider (CSP) source or origin, bypassing caching altogether, or altering cache keys with dynamically generated values. | |||||||||||||
| draft-ietf-cdni-ci-triggers-rfc8007bis-20.txt | ||||||||||||||
| Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition | ||||||||||||||
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition, invalidate, and/or purge metadata and/or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. | |||||||||||||
| draft-ietf-cdni-client-access-control-metadata-05.txt | ||||||||||||||
| CDNI Client Access Control Metadata | ||||||||||||||
|
This specification adds to the basic client access control metadata in RFC8006, providing content providers and upstream content delivery networks (uCDNs) extended capabilities in defining location and time window restrictions. Support is also provided to define required Transport Layer Security (TLS) certificates and encryption levels. The specification also defines configuration metadata for the Common Access Token (CAT), developed jointly by the Streaming Video Technology Alliance (SVTA) and Consumer Technology Association Web Application Video Ecosystem (CTA-WAVE). | |||||||||||||
| draft-ietf-cdni-delivery-metadata-03.txt | ||||||||||||||
| CDNI Delivery Metadata | ||||||||||||||
|
This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, request delegation behavior and CDN transport arrangements selection of a downstream CDN. | |||||||||||||
| draft-ietf-cdni-edge-control-metadata-12.txt | ||||||||||||||
| Content Delivery Network Interconnection (CDNI) Edge Control Metadata | ||||||||||||||
|
This specification defines configuration metadata objects used to manage how edge servers control access to resources within Content Delivery Networks (CDNs) and Open Caching systems. A key feature of these configurations is the configuring of Cross-Origin Resource Sharing (CORS) access rules and the dynamic generation of CORS headers. This specification also provides the ability to define response body compression rules and client connection timeouts. | |||||||||||||
| draft-ietf-cdni-logging-extensions-04.txt | ||||||||||||||
| CDNI Logging Extensions | ||||||||||||||
|
This document defines a set of extensions to CDNI for supporting transmission of transaction logs in both push and pull operational modes, new log container formats and log record formats, new logging fields, and metadata for describing the transformation, obfuscation, and encryption of log record fields. | |||||||||||||
| draft-ietf-cdni-metadata-expression-language-02.txt | ||||||||||||||
| CDNI Metadata Expression Language | ||||||||||||||
|
This document specifies the syntax and provides usage examples for an expression language to be used within Content Delivery Network Interconnection (CDNI) Metadata Interface (MI) objects. The purpose of this expression language is to enable metadata to be applied conditionally (based on aspects of an HTTP request), and to enable Hypertext Transfer Protocol (HTTP) responses to be generated or altered dynamically. | |||||||||||||
| draft-ietf-cdni-processing-stages-metadata-01.txt | ||||||||||||||
| CDNI Processing Stages Metadata | ||||||||||||||
|
This document specifies a set of objects extending the Content Delivery Network Interconnection (CDNI) metadata model to allow for metadata to be applied conditionally and at various points in a dCDNs processing of requests. The concept of Processing Stages are introduced, where each stage in a CDN's processing pipeline presents an opportunity to examine requests and responses and make alterations as needed. Metadata, such as caching rules, can be applied conditionally (based on aspects of an HTTP request header), and HTTP responses from a source can be altered dynamically (such as adding or dropping an HTTP header). This standard leverages the expression language documented in the Metadata Expression Language (MEL) Specification. | |||||||||||||
| draft-ietf-cdni-protected-secrets-metadata-07.txt | ||||||||||||||
| CDNI Protected Secrets Metadata | ||||||||||||||
|
This document defines a simple mechanism for protected secret data (such as salt values or encryption keys) that may be embedded in configuration metadata or capabilities advertisements. | |||||||||||||
| draft-ietf-cdni-source-access-control-metadata-01.txt | ||||||||||||||
| CDNI Source Access Control Metadata | ||||||||||||||
|
This specification provides an alternative to the MI.SourceMetadata objects defined in RFC8006, providing greatly extended capabilities with regards to defining multiple sources, load balancing, and failover rules across those sources, as well as a mechanism for a content delivery network (CDN) to monitor source health and pull unhealthy sources out of rotation. Additionally, new methods are defined for authentication access to an upstream source/origin. | |||||||||||||
| draft-ietf-cellar-codec-20.txt | ||||||||||||||
| Matroska Media Container Codec Specifications | ||||||||||||||
|
This document defines the Matroska multimedia container codec mappings, including the codec ID, layout of data in a Block element and in an optional CodecPrivate element. | |||||||||||||
| draft-ietf-cellar-tags-25.txt | ||||||||||||||
| Matroska Media Container Tag Specifications | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-core-cacheable-oscore-02.txt | ||||||||||||||
| End-to-End Protected and Cacheable CoAP Responses using Group Object Security for Constrained RESTful Environments (Group OSCORE) | ||||||||||||||
|
When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-to-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group. | |||||||||||||
| draft-ietf-core-coap-bp-04.txt | ||||||||||||||
| Constrained Application Protocol (CoAP) over Bundle Protocol (BP) | ||||||||||||||
|
The Bundle Protocol (BP) was designed to enable end-to-end communication in challenged networks. The Constrained Application Protocol (CoAP), which was designed for constrained-node networks, may be a suitable application-layer protocol for the scenarios where BP is used. This document specifies how CoAP is carried over BP. | |||||||||||||
| draft-ietf-core-coap-over-gatt-00.txt | ||||||||||||||
| CoAP over GATT (Bluetooth Low Energy Generic Attributes) | ||||||||||||||
|
Interaction from computers and cell phones to constrained devices is limited by the different network technologies used, and by the available APIs. This document describes a transport for the Constrained Application Protocol (CoAP) that uses Bluetooth GATT (Generic Attribute Profile) and its use cases. | |||||||||||||
| draft-ietf-core-coap-pubsub-21.txt | ||||||||||||||
| A publish-subscribe architecture for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. | |||||||||||||
| draft-ietf-core-conditional-attributes-14.txt | ||||||||||||||
| Conditional Query Parameters for CoAP Observe | ||||||||||||||
|
This specification defines Conditional Notification and Control Query Parameters compatible with CoAP Observe (RFC7641). | |||||||||||||
| draft-ietf-core-corr-clar-04.txt | ||||||||||||||
| Constrained Application Protocol (CoAP): Corrections and Clarifications | ||||||||||||||
|
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided. | |||||||||||||
| draft-ietf-core-groupcomm-bis-18.txt | ||||||||||||||
| Group Communication for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. | |||||||||||||
| draft-ietf-core-groupcomm-proxy-07.txt | ||||||||||||||
| Proxy Operations in Group Communication for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document defines a specific realization of proxy intended for scenarios that use group communication for the Constrained Application Protocol (CoAP). Such a proxy processes a single request sent by a client typically over unicast and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. | |||||||||||||
| draft-ietf-core-href-30.txt | ||||||||||||||
| Constrained Resource Identifiers | ||||||||||||||
|
The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. | |||||||||||||
| draft-ietf-core-multicast-notifications-proxy-02.txt | ||||||||||||||
| Using Proxies for Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. Instead of sending a distinct unicast notification to each different client, a server can alternatively send a single notification as a response message over multicast, to all the clients observing the same target resource. When doing so, the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to-end between the server and the observer clients. This document describes how multicast notifications can be used in network setups that leverage a proxy, e.g., in order to accommodate clients that are not able to directly listen to multicast traffic. | |||||||||||||
| draft-ietf-core-observe-multicast-notifications-15.txt | ||||||||||||||
| Observe Notifications as CoAP Multicast Responses | ||||||||||||||
|
The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as those based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and it defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to- end between the server and the observer clients. | |||||||||||||
| draft-ietf-core-oscore-capable-proxies-07.txt | ||||||||||||||
| OSCORE-capable Proxies | ||||||||||||||
|
When using the Constrained Application Protocol (CoAP), messages exchanged between two endpoints can be protected end-to-end at the application layer by means of Object Security for Constrained RESTful Environments (OSCORE), also in the presence of intermediaries such as proxies. This document defines how to use OSCORE for protecting CoAP messages also between an origin application endpoint and an intermediary, or between two intermediaries. Also, it defines rules to escalate the protection of a CoAP option, in order to encrypt and integrity-protect it whenever possible. Finally, it defines how to secure a CoAP message by applying multiple, nested OSCORE protections, e.g., both end-to-end between origin application endpoints; and between an application endpoint and an intermediary or between two intermediaries. Therefore, this document updates RFC 8613. Furthermore, this document updates RFC 8768, by explicitly defining the processing with OSCORE for the CoAP Hop-Limit Option. The approach defined in this document can be seamlessly employed also with Group OSCORE, for protecting CoAP messages when group communication is used in the presence of intermediaries. | |||||||||||||
| draft-ietf-core-oscore-groupcomm-28.txt | ||||||||||||||
| Group Object Security for Constrained RESTful Environments (Group OSCORE) | ||||||||||||||
|
This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. | |||||||||||||
| draft-ietf-core-oscore-id-update-07.txt | ||||||||||||||
| Identifier Update for OSCORE | ||||||||||||||
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. | |||||||||||||
| draft-ietf-core-oscore-key-limits-08.txt | ||||||||||||||
| Key Usage Limits for OSCORE | ||||||||||||||
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. | |||||||||||||
| draft-ietf-core-oscore-key-update-14.txt | ||||||||||||||
| Key Update for OSCORE (KUDOS) | ||||||||||||||
|
Communications with the Constrained Application Protocol (CoAP) can be protected end-to-end at the application-layer by using the security protocol Object Security for Constrained RESTful Environments (OSCORE). Under some circumstances, two CoAP endpoints need to update their OSCORE keying material before communications can securely continue, e.g., due to approaching key usage limits. This document defines Key Update for OSCORE (KUDOS), a lightweight key update procedure that two CoAP endpoints can use to update their OSCORE keying material by establishing a new OSCORE Security Context. Accordingly, this document updates the use of the OSCORE flag bits in the CoAP OSCORE Option as well as the protection of CoAP response messages with OSCORE. Also, it deprecates the key update procedure specified in Appendix B.2 of RFC 8613. Therefore, this document updates RFC 8613. | |||||||||||||
| draft-ietf-core-responses-01.txt | ||||||||||||||
| CoAP: Non-traditional Response Forms | ||||||||||||||
|
In CoAP as defined by RFC 7252, there is generally one response for each request. Various CoAP extensions have individually relaxed that practice. The present memo presents a generalized model beyond 1:1 responses, describes different forms in which it can be used, and introduces new CoAP Options that make use of that model. Beyond that, this document provides implementation guidance to simplify prior extensions, and outlines future possibilities of using it. // This revision -01 has been created as discussion input for IETF // 126. It makes a first attempt to sort the proposals into short- // term actionable ones and more long-term considerations for more // kinds of responses that could help additional use cases through // future work. | |||||||||||||
| draft-ietf-core-transport-indication-10.txt | ||||||||||||||
| CoAP Transport Indication | ||||||||||||||
|
The Constrained Application Protocol (CoAP, [RFC7252]) is available over different transports (UDP, DTLS, TCP, TLS, WebSockets), but lacks a way to unify these addresses. This document provides terminology and provisions based on Web Linking [RFC8288] and Service Bindings (SVCB, [RFC9460]) to express alternative transports available to a device, and to optimize exchanges using these. | |||||||||||||
| draft-ietf-core-uri-path-abbrev-05.txt | ||||||||||||||
| URI Path abbreviation in CoAP | ||||||||||||||
|
Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus using (relatively verbose) well-known URI paths. This document introduces the Uri-Path-Abbrev CoAP option that allows expressing well-known URI paths in as little as two bytes. Using this option revealed a subtle flaw in RFC7252 that severely limited the extension point of critical options. This document updates RFC7252 to rectify that. | |||||||||||||
| draft-ietf-cose-c509-test-vectors-02.txt | ||||||||||||||
| Test Vectors for CBOR-Encoded X.509 (C509) Certificates | ||||||||||||||
|
This document contains examples of CBOR-encoded X.509 (C509) certificates, certification requests, and certification request templates. | |||||||||||||
| draft-ietf-cose-cbor-encoded-cert-20.txt | ||||||||||||||
| CBOR Encoded X.509 Certificates (C509 Certificates) | ||||||||||||||
|
This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. | |||||||||||||
| draft-ietf-cose-cmac-01.txt | ||||||||||||||
| AES-CMAC for COSE | ||||||||||||||
|
The CBOR Object Signing and Encryption (COSE) specification defines structures for generating, conveying, and verifying Message Authentication Code (MAC) tags. This document registers code points for using the Advanced Encryption Standard (AES) block cipher in Cipher-based Message Authentication Code (CMAC) mode within those COSE structures. Specifically, these uses are for computing MAC tag values with no additional parameters. | |||||||||||||
| draft-ietf-cose-hpke-27.txt | ||||||||||||||
| Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) | ||||||||||||||
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. | |||||||||||||
| draft-ietf-cose-hpke-pq-pqt-01.txt | ||||||||||||||
| COSE HPKE PQ & PQ/T Algorithm Registrations | ||||||||||||||
|
This document registers Post-Quantum (PQ) and Post-Quantum/ Traditional (PQ/T) hybrid algorithm identifiers for use with CBOR Object Signing and Encryption (COSE), building on the Hybrid Public Key Encryption (HPKE) framework. | |||||||||||||
| draft-ietf-cose-sphincs-plus-10.txt | ||||||||||||||
| SLH-DSA for JOSE and COSE | ||||||||||||||
|
Digital signatures are used within JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) to protect the integrity and authenticity of messages, such as JSON Web Signatures and signed COSE structures. This document specifies JOSE and COSE serializations for the Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205. The conventions for the associated algorithm identifiers, signatures, public keys, and private keys are also specified. | |||||||||||||
| draft-ietf-cose-split-signing-algs-01.txt | ||||||||||||||
| Split Signing Algorithms for COSE | ||||||||||||||
|
This specification defines COSE algorithm identifiers for negotiating how to split a signature algorithm between two cooperating parties. Typically the first party hashes the data to be signed and the second party finishes the signature over the hashed data. This is a common technique, useful for example when the signing private key is held in a smart card or similar hardware component with limited processing power and communication bandwidth. The resulting signatures are identical in structure to those computed by a single party, and can be verified using the same verification algorithm without additional steps to preprocess the signed data. | |||||||||||||
| draft-ietf-dance-architecture-10.txt | ||||||||||||||
| An Architecture for DNS-Bound Client and Sender Identities | ||||||||||||||
|
This architecture document defines terminology, interaction, and authentication patterns, related to the use of DANE DNS records for TLS client and messaging peer identity, within the context of existing object security and TLS-based protocols. | |||||||||||||
| draft-ietf-dance-client-auth-14.txt | ||||||||||||||
| TLS Client Authentication via DANE TLSA records | ||||||||||||||
|
The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. In addition, it defines a new TLS extension, DANE Client Identity, to convey the client's domain name identity to the server. | |||||||||||||
| draft-ietf-dconn-domainconnect-03.txt | ||||||||||||||
| Domain Connect Protocol - DNS provisioning between Services and DNS Providers | ||||||||||||||
|
This document provides specification of the Domain Connect Protocol that was built to support DNS configuration provisioning between Service Providers (hosting, social, email, hardware, etc.) and DNS Providers. | |||||||||||||
| draft-ietf-dconn-domainconnect-async-00.txt | ||||||||||||||
| Domain Connect Protocol - Asynchronous Flow Extension | ||||||||||||||
|
This document defines the Asynchronous OAuth 2.0 extension to the Domain Connect Protocol specified in I-D.draft-ietf-dconn- domainconnect-02, Section . | |||||||||||||
| draft-ietf-deleg-11.txt | ||||||||||||||
| Extensible Delegation for DNS | ||||||||||||||
|
This document specifies a new extensible method for the delegation of authority for a domain in the Domain Name System (DNS) using DELEG and DELEGPARAM records. A delegation in the DNS enables efficient and distributed management of the DNS namespace. The traditional DNS delegation is based on NS records which contain only hostnames of servers and no other parameters. In classic DNS, both parent and child zones contain copies of NS delegation records, which can potentially be out of sync and confusing. The new delegation records are extensible, can be secured with DNSSEC, and eliminate the problem of having two sources of truth for delegation information. | |||||||||||||
| draft-ietf-detnet-dataplane-taxonomy-06.txt | ||||||||||||||
| Dataplane Enhancement Taxonomy | ||||||||||||||
|
This draft is to facilitate the understanding of the data plane enhancement solutions, which are suggested currently or can be suggested in the future, for deterministic networking. This draft provides criteria for classifying data plane solutions. Examples of each category are listed, along with reasons where necessary. Strengths and limitations of the categories are described. Suitability of the solutions for various services of deterministic networking are also mentioned. Reference topologies for evaluation of the solutions are given as well. | |||||||||||||
| draft-ietf-detnet-deadline-based-forwarding-01.txt | ||||||||||||||
| Deadline Based Deterministic Forwarding | ||||||||||||||
|
This document describes a deadline based deterministic forwarding mechanism for IP/MPLS network with the corresponding resource reservation, admission control, scheduling and policing processes to provide guaranteed latency bound. It employs a latency compensation technique with a stateless core, to replace reshaping, making it suitable for the Differentiated Services (Diffserv) architecture [RFC2475]. | |||||||||||||
| draft-ietf-detnet-glbf-01.txt | ||||||||||||||
| Deterministic Networking (DetNet) Data Plane - guaranteed Latency Based Forwarding (gLBF) for bounded latency with low jitter and asynchronous forwarding in Deterministic Networks | ||||||||||||||
|
This memo proposes a mechanism called "guaranteed Latency Based Forwarding" (gLBF) as part of DetNet for hop-by-hop packet forwarding with per-hop deterministically bounded latency and minimal jitter. gLBF is intended to be useful across a wide range of networks and applications with need for high-precision deterministic networking services, including in-car networks or networks used for industrial automation across on factory floors, all the way to ++100Gbps country-wide networks. Contrary to other mechanisms, gLBF does not require network wide clock synchronization, nor does it need to maintain per-flow state at network nodes, avoiding drawbacks of other known methods while leveraging their advantages. Specifically, gLBF uses the queuing model and calculus of Urgency Based Scheduling (UBS, [UBS]), which is used by TSN Asynchronous Traffic Shaping [TSN-ATS]. gLBF is intended to be a plug-in replacement for TSN-ATN or as a parallel mechanism beside TSN-ATS because it allows to keeping the same controller-plane design which is selecting paths for TSN-ATS, sizing TSN-ATS queues, calculating latencies and admitting flows to calculated paths for calculated latencies. In addition to reducing the jitter compared to TSN-ATS by additional buffering (dampening) in the network, gLBF also eliminates the need for per-flow, per-hop state maintenance required by TSN-ATS. This avoids the need to signal per-flow state to every hop from the controller-plane and associated scaling problems. It also reduces implementation cost for high-speed networking hardware due to the avoidance of additional high-speed speed read/write memory access to retrieve, process and update per-flow state variables for a large number of flows. | |||||||||||||
| draft-ietf-detnet-multi-domain-framework-02.txt | ||||||||||||||
| A Control Plane Framework for Multi-Domain Deterministic Networking (DetNet) | ||||||||||||||
|
Deterministic Networking (DetNet) provides the capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency over a path or network. As DetNet deployments expand, they will inevitably need to span multiple domains that may be under separate technological control. This creates a need for a control plane solution that can establish and maintain end-to-end DetNet services across these domain boundaries. This document defines a generic framework for a multi-domain DetNet control plane. It first establishes a working definition of a "DetNet Domain" for the purpose of path computation and control. It then describes two high-level architectural approaches for inter- domain path computation and resource reservation: a Hierarchical model and a peer-to-peer "stitching" model. While a Path Computation Element (PCE)-based realization is used as an illustrative example, the framework is designed to be applicable to any controller-plane technology that satisfies the stated functional requirements. This framework provides the foundation for more specific work on multi- domain DetNet solutions. | |||||||||||||
| draft-ietf-detnet-nscore-02.txt | ||||||||||||||
| On-time Forwarding with Non-Work Conserving Stateless Core Fair Queuing | ||||||||||||||
|
This document specifies the framework and operational procedure for deterministic networking that guarantees maximum and minimum end-to- end latency bounds to flows. The solution has non-periodic, asynchronous, flow-level, non-work conserving, on-time, and rate- based functional characteristics, according to the taxonomy suggested by [I-D.ietf-detnet-dataplane-taxonomy]. The packets are stored in the queue in ascending order of the ideal service start time, called Eligible Time (ET), and the ideal service completion time, called Finish Time (FT). The queued packets were forwarded after ET, in ascending ordering of FT, in a non-work conserving manner. The ET and FT are calculated at the entrance node according to the packet size and rate of the flow. All subsequent core nodes are stateless and asynchronously update ET and FT based on metadata received via packet headers. This mechanism is called non- work conserving stateless fair queuing (N-SCORE), which guarantees both E2E latency upper and lower bounds, thus E2E jitter bound. N-SCORE supports two alternative methods for determining ET and FT at stateless core nodes. The Direct ET/FT Method propagates ET and FT generated by the previous node using the delay factor function. The Arrival-based ET/FT Method reconstructs ET and FT from the locally observed packet arrival time together with metadata carried in the packet header. Both methods provide identical scheduling semantics while allowing different implementation choices. | |||||||||||||
| draft-ietf-detnet-ontime-forwarding-02.txt | ||||||||||||||
| On-time Forwarding with Push-In First-Out (PIFO) queue | ||||||||||||||
|
This document describes operations of data plane and controller plane for Deterministic Networking (DetNet) to forward packets to meet minimum and maximum end-to-end latency requirements, while utilizing Push-In First-Out (PIFO) queue. According to the solution described in this document, forwarding nodes do not need to maintain flow states or to be time-synchronized with each other. | |||||||||||||
| draft-ietf-detnet-packet-timeslot-mechanism-01.txt | ||||||||||||||
| Timeslot Queueing and Forwarding Mechanism | ||||||||||||||
|
IP/MPLS networks use packet switching (with the feature store-and- forward) and are based on statistical multiplexing. Statistical multiplexing is essentially a variant of time division multiplexing, which refers to the asynchronous and dynamic allocation of link timeslot resources. Statistical multiplexing has certain challenges and complexity in meeting deterministic QoS. This document describes a generic time division multiplexing scheme for layer-3 in an IP/MPLS networks, called timeslot queueing and forwarding (TQF) mechanism. TQF is an enhancement based on TSN TAS and allows the data plane to create a flexible timeslot mapping based on available timeslot resources. It defines a cyclic period consisting of multiple timeslots where a flow is assigned to be transmitted within one or more dedicated timeslots. The objective of TQF is to better handle large scaling requirements. | |||||||||||||
| draft-ietf-detnet-scaling-requirements-11.txt | ||||||||||||||
| Requirements for Scaling Deterministic Networks | ||||||||||||||
|
To support the scaling of deterministic networks, this document describes the technical and operational requirements for networks that exhibit large hop-to-hop latency variation, a large number of flows, and/or multiple domains that do not share a common time source. Applications with varying levels of determinism coexist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. | |||||||||||||
| draft-ietf-detnet-srv6-svc-protection-00.txt | ||||||||||||||
| Deterministic Networking SRv6 Data Plane for Service Protection | ||||||||||||||
|
This document specifies the Deterministic Networking (DetNet) data plane aspects for service protection when operating over an IPv6/SRv6 Packet Switched Network. It leverages existing IPv6 encapsulations and behaviors. It uses the Redundancy SIDs in DetNet scenarios and optionally the Traffic Engineering mechanisms provided by SRv6. This document builds on the DetNet architecture and data plane framework. | |||||||||||||
| draft-ietf-detnet-stateless-fair-queuing-01.txt | ||||||||||||||
| Latency Guarantee with Stateless Fair Queuing | ||||||||||||||
|
This document specifies the implementation details for the framework specified in ITU-T Y.3129 [Y.3129] and ITU-T Y.3148 [Y.3148]. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update the FT by adding a delay factor, which is a function of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. This document specifies the metadata, formats of metadata, the admission control procedure, and an approximation of stateless fair queuing implemented via a strict priority (SP) scheduler. | |||||||||||||
| draft-ietf-detnet-tcqf-01.txt | ||||||||||||||
| Deterministic Networking (DetNet) Data Plane - Tagged Cyclic Queuing and Forwarding (TCQF) for bounded latency with low jitter in large scale DetNets | ||||||||||||||
|
This memo specifies a forwarding method for bounded latency and bounded jitter for Deterministic Networks and is a variant of the IEEE TSN Cyclic Queuing and Forwarding (CQF) method. Tagged CQF (TCQF) supports more than 2 cycles and indicates the cycle number via an existing or new packet header field called the tag to replace the cycle mapping in CQF which is based purely on synchronized reception clock. This memo standardizes TCQF as a mechanism independent of the tagging method used. It also specifies tagging via the (1) the existing MPLS packet Traffic Class (TC) field for MPLS packets, (2) the IP/IPv6 DSCP field for IP/IPv6 packets, and (3) a new TCQF Option header for IPv6 packets. Target benefits of TCQF include low end-to-end jitter, ease of high- speed hardware implementation, optional ability to support large number of flow in large networks via DiffServ style aggregation by applying TCQF to the DetNet aggregate instead of each DetNet flow individually, and support of wide-area DetNet networks with arbitrary link latencies and latency variations as well as low accuracy clock synchronization. | |||||||||||||
| draft-ietf-diem-requirements-03.txt | ||||||||||||||
| Digital Emblems - Use Cases and Requirements | ||||||||||||||
|
Digital emblems are a means for an asset to signal to validating entities that it should be protected or treated in a specific way, using some normative framework. This document lists the requirements and use cases that an architecture for digital emblems must accommodate. | |||||||||||||
| draft-ietf-dkim-dkim2-bcp-01.txt | ||||||||||||||
| DKIM2 Best Practices | ||||||||||||||
|
[DKIM2] and its associated documents describe the DomainKeys Identified Mail v2 (DKIM2) email authentication protocol. DKIM2 is designed to address shortcomings in email authentication protocols and mechanisms released prior to DKIM2, specifically SPF [RFC7208], DKIM [RFC6376], DMARC [RFC9989], and ARC [RFC8617]. This document discusses best practices for signing, handling, and validating messages that carry DKIM2 signatures, and for interoperating with the authentication protocols and mechanisms that preceded DKIM2. | |||||||||||||
| draft-ietf-dkim-dkim2-dns-00.txt | ||||||||||||||
| Domain Name Specification for DKIM2 | ||||||||||||||
|
The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer’s domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record. | |||||||||||||
| draft-ietf-dkim-dkim2-spec-06.txt | ||||||||||||||
| DomainKeys Identified Mail Signatures v2 (DKIM2) | ||||||||||||||
|
DomainKeys Identified Mail v2 (DKIM2) permits a person, role, or organization that owns a signing domain to document that it has handled an email message by associating their domain with the message. This is achieved by providing a hash value that has been calculated on the current contents of the message and then applying a cryptographic signature that covers the hash values and other details about the transmission of the message. Verification is performed by querying an entry within the signing domain's DNS space to retrieve an appropriate public key. As a message is transferred from author to recipient systems that alter the body or header fields will provide details of their changes and calculate new hash values. Further signatures will be added to provide a validatable "chain". This permits validators to identify the nature of changes made by intermediaries and apply a reputation to the systems that made changed. DKIM2 also allows recipients to detect when messages have been unexpectedly "replayed" and will ensure that Delivery Status Notifications are only sent to entities that were involved in the transmission of a message. | |||||||||||||
| draft-ietf-dmarc-arc-to-historic-00.txt | ||||||||||||||
| Reclassifying ARC as Historic | ||||||||||||||
|
This document calls for a conclusion to the experiment defined by “The Authenticated Received Chain (ARC) Protocol” [RFC8617], and recommends that ARC no longer be deployed or relied upon between disparate senders and receivers. The document summarizes what ARC set out to do, reports on operational experience, and explains how the experience gained during the experiment is being incorporated into the proposed DKIM2 work as the successor to DomainKeys Identified Mail [RFC6376]. To avoid any future confusion, it is therefore requested that ARC [RFC8617] be reclassified as “Historic”. | |||||||||||||
| draft-ietf-dmm-mts-02.txt | ||||||||||||||
| Mobile Traffic Steering | ||||||||||||||
|
The evolution of cellular mobile communication systems is aligned with an increasing demand for customized deployments, energy efficiency, dynamic re-configurability and the integration and use of other network technologies, such as non-cellular radio access technologies and non-terrestrial networks. In order to achieve and maintain the expected service quality and continuity, such systems should be designed and controllable end-to-end, taking all involved network domains and segments into account. This document discusses an end-to-end system from an advanced use cases perspective and substantiates the demand for solutions to share information and enable control interfaces between all connected network domains, including the mobile communication system and the transport network that stretches up to the data networks that host service instances. In the view of flexible implementations and deployment, two architectural principles, leveraging either a dedicated controller or a decentralized control plane, are described and discussed, accompanied by operational aspects and an associated information model that enable end-to-end mobile traffic treatment and steering in such complex and dynamically changing networks. | |||||||||||||
| draft-ietf-dmm-mup-architecture-02.txt | ||||||||||||||
| Mobile User Plane Architecture for Distributed Mobility Management | ||||||||||||||
|
This document defines the Mobile User Plane (MUP) architecture for Distributed Mobility Management. The requirements for Distributed Mobility Management described in [RFC7333] can be satisfied by routing fashion. In MUP Architecture, session information between the entities of the mobile user plane is turned to routing information so that mobile user plane can be integrated into dataplane. MUP architecture is designed to be pluggable user plane part of existing mobile service architectures, enabled by auto-discovery for the use plane. Segment Routing provides network programmability for a scalable option with it. While MUP architecture itself is independent from a specific dataplane protocol, several dataplane options are available for the architecture. This document describes IPv6 dataplane in Segment Routing case (SRv6 MUP) due to the DMM requirement, and is suitable for mobile services which require a large IP address space. | |||||||||||||
| draft-ietf-dmm-srv6mob-arch-04.txt | ||||||||||||||
| Architecture Discussion on SRv6 Mobile User plane | ||||||||||||||
|
This document describes the solution approach and its architectural benefits of transforming mobile session information into routing information, leveraging segment routing capabilities, and operating within the IP routing paradigm. | |||||||||||||
| draft-ietf-dmm-tn-aware-mobility-32.txt | ||||||||||||||
| Mapping 5G slice to Transport Network slice with UDP Source Ports | ||||||||||||||
|
Network slicing in 5G enables logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G infrastructure and services, user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC) use IP in many segments of an end-to-end 5G slice. When end-to-end slices in a 5G System use network resources, they are mapped to corresponding Transport Network (TN) slice(s) which in turn provide the bandwidth, latency, isolation, and other criteria required for the realization of a 5G slice. This document describes mapping of 5G slices to TN slices using UDP source port number of the GTP-U bearer when the TN slice provider is separated by an "attachment circuit" from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session anchors. | |||||||||||||
| draft-ietf-dmm-udp-tunnel-acaas-extn-01.txt | ||||||||||||||
| A YANG Data Model Extension for Attachment Circuit as a Service with UDP Tunnel Support | ||||||||||||||
|
Delivery of network services over a Layer 3 tunnel assumes that the appropriate setup is provisioned over links that connect the customer termination points and provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC) while the underlying link for carrying network services is referred to as "bearer", in this case a Layer 3 UDP tunnel. This document specifies an extension for UDP tunnel as Layer 3 bearer to the YANG service data model for AC. | |||||||||||||
| draft-ietf-dnsop-delegation-mgmt-via-ddns-02.txt | ||||||||||||||
| Automating DNS Delegation Management via DDNS | ||||||||||||||
|
Delegation information (i.e. the NS RRset, possible glue, possible DS records) should always be kept in sync between child zone and parent zone. However, in practice that is not always the case. When the delegation information is not in sync the child zone is usually working fine, but without the amount of redundancy that the zone owner likely expects to have. Hence, should any further problems ensue it could have catastrophic consequences. The DNS name space has lived with this problem for decades and it never goes away. Or, rather, it will never go away until a fully automated mechanism for how to keep the information in sync automatically is deployed. This document proposes such a mechanism based on DNS Dynamic Updates (DDNS) secured with SIG(0) signatures, sent from the child to the parent across the zone cut. The target of the update is discovered via the DSYNC record defined in [RFC9859]. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via-ddns (https://github.com/johanix/draft-ietf-dnsop-delegation-mgmt-via- ddns). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| draft-ietf-dnsop-delext-11.txt | ||||||||||||||
| DNS Protocol Modifications for Delegation Extensions | ||||||||||||||
|
The Domain Name System (DNS) protocol permits Delegation Signer (DS) records at delegation points. This document specifies modifications to the DNS protocol to permit a range of Resource Record types at delegation points. These modifications are designed to maintain compatibility with existing DNS resolution mechanisms and provide a secure method for processing these records at delegation points. This document updates RFCs 1034, 4035, 6672, 6840, 6895 and 9824. | |||||||||||||
| draft-ietf-dnsop-dnssec-automation-05.txt | ||||||||||||||
| DNSSEC automation | ||||||||||||||
|
This document describes an algorithm and protocol to automate the setup, operations, and decommissioning of Multi-Signer DNSSEC [RFC8901] configurations. To accomplish this, it employs Model 2 of the multi-signer specification (where each operator has their own distinct KSK and ZSK sets, or CSK sets), management of DS records from the parent via CDS/CDNSKEY [RFC8078], and Child-to-Parent Synchronization in DNS [RFC7477]. | |||||||||||||
| draft-ietf-dnsop-dnssec-keyrestore-02.txt | ||||||||||||||
| DNSSEC Key Restore | ||||||||||||||
|
This document describes the issues surrounding the handling of DNSSEC private keys in a DNSSEC signer. It presents operational guidance in case a DNSSEC private key becomes inoperable. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Domain Name System Operations Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/dnsop/. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-dnssec-keyrestore. | |||||||||||||
| draft-ietf-dnsop-domain-verification-techniques-13.txt | ||||||||||||||
| Domain Control Validation using DNS | ||||||||||||||
|
Many application services on the Internet need to verify ownership or control of a domain in the Domain Name System (DNS). The general term for this process is "Domain Control Validation", and it can be done using a variety of methods such as email, HTTP/HTTPS, or the DNS itself. This document focuses only on DNS-based methods, which typically involve the Application Service Provider requesting a DNS record with a specific format and content to be visible in the domain to be verified. There is wide variation in the details of these methods today. This document provides some best practices to avoid known problems. | |||||||||||||
| draft-ietf-dnsop-dry-run-dnssec-01.txt | ||||||||||||||
| dry-run DNSSEC | ||||||||||||||
|
This document describes a method called "dry-run DNSSEC" that allows for testing DNSSEC deployments without affecting the DNS service in case of DNSSEC errors. It accomplishes that by introducing new DS Type Digest Algorithms that when used in every record of a DS RRset, referred to as dry-run DS, signal to validating resolvers that dry- run DNSSEC is used for the zone. DNSSEC errors are then reported with DNS Error Reporting, but any bogus responses to clients are withheld. Instead, validating resolvers fallback from dry-run DNSSEC and provide the response that would have been answered without the presence of the dry-run DS. A further EDNS option is presented for clients to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC testing. | |||||||||||||
| draft-ietf-dnsop-filtering-transparency-00.txt | ||||||||||||||
| DNS Filtering Transparency | ||||||||||||||
|
[I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This specification allows more specific details of filtering incidents to be conveyed. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. | |||||||||||||
| draft-ietf-dnsop-grease-03.txt | ||||||||||||||
| Greasing Protocol Extension Points in the DNS | ||||||||||||||
|
Long term evolvability of the Domain Name System (DNS) protocol requires the ability to support change. Greasing is one technique that exercises the regular use of unallocated protocol extension points to prevent ossification of their current usage patterns by middleboxes or DNS implementations. This document describes considerations and proposals for applying grease to the DNS protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-grease. | |||||||||||||
| draft-ietf-dnsop-integration-04.txt | ||||||||||||||
| Integration of DNS Domain Names into Application Environments: Motivations and Considerations | ||||||||||||||
|
This document describes considerations when integrating a DNS domain name into an application environment. Goals of this document include minimizing conflicts between the global DNS and applications that integrate with the global DNS, providing a consistent user experience (unique identifier across environments), and avoiding impacts to the security, stability, and resiliency of the global DNS. While all sources of potential concern cannot be enumerated in one document, accounting for at least the considerations discussed here should improve the security posture of both the global DNS and integrating applications. | |||||||||||||
| draft-ietf-dnsop-ns-revalidation-14.txt | ||||||||||||||
| Delegation Revalidation by DNS Resolvers | ||||||||||||||
|
This document describes an optional algorithm for the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution, and describes the benefits and considerations of using this approach. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the delegation by re-querying the parent zone at the expiration of the shortest TTL among the parent NS RRset, the DS RRset (if present), and the child NS RRset. | |||||||||||||
| draft-ietf-dnsop-rfc9364bis-01.txt | ||||||||||||||
| DNS Security Extensions (DNSSEC) | ||||||||||||||
|
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. This document obsoletes RFC 9364. This document is being tracked at (https://github.com/paulehoffman/ rfc9364bis). | |||||||||||||
| draft-ietf-dnsop-structured-dns-error-27.txt | ||||||||||||||
| Structured Error Data for Filtered DNS | ||||||||||||||
|
DNS filtering is widely deployed for various reasons, including network security and policy enforcement. However, filtered DNS responses lack structured information for end users to understand the reason for the filtering. Existing mechanisms to provide explanatory details to end users cause harm especially if the blocked DNS response is for HTTPS resources. This document updates RFC 8914 by signaling client support for structuring the EXTRA-TEXT field of the Extended DNS Error to provide details on the DNS filtering. Such details can be parsed by the client and displayed, logged, or used for other purposes. | |||||||||||||
| draft-ietf-dnssd-advertising-proxy-06.txt | ||||||||||||||
| Advertising Proxy for DNS-SD Service Registration Protocol | ||||||||||||||
|
An Advertising Proxy advertises the contents of a DNS zone, for example maintained using the DNS-SD Service Registration Protocol (SRP), using Multicast DNS. This allows legacy clients to discover services registered with SRP using Multicast DNS. | |||||||||||||
| draft-ietf-dnssd-tsr-03.txt | ||||||||||||||
| Multicast DNS conflict resolution using the Time Since Received (TSR) EDNS option | ||||||||||||||
|
This document specifies a new conflict resolution mechanism for DNS, for use in cases where the advertisement is being proxied, rather than advertised directly, e.g. when using a combined DNS-SD advertising proxy and SRP registrar. A new EDNS option is defined that communicates the time at which the set of resource records on a particular DNS owner name was most recently updated. | |||||||||||||
| draft-ietf-dnssd-uld-00.txt | ||||||||||||||
| Providing Local Unicast DNS-SD Service on Infrastructure | ||||||||||||||
|
DNS Service Discovery provides several mechanisms whereby hosts can discover and advertise services on an IP network. Such discovery can be done using Multicast DNS (mDNS) or DNS, and advertising can be done with DNS-SD Service Registration Protocol (SRP) or mDNS. This document defines Unicast Local Discovery (ULD), a service that combines an SRP registrar, a Discovery Proxy, and an Advertising Proxy. Hosts can use a ULD server to advertise and discover services on the local link entirely via unicast SRP and DNS while remaining interoperable with hosts that use mDNS. | |||||||||||||
| draft-ietf-drip-dki-10.txt | ||||||||||||||
| The DRIP DET public Key Infrastructure | ||||||||||||||
|
The DRIP Entity Tag (DET) public Key Infrastructure (DKI) is a specific variant of classic Public Key Infrastructures (PKI) where the organization is around the DET, in place of X.520 Distinguished Names. Further, the DKI uses DRIP Endorsements in place of X.509 certificates for establishing trust within the DKI. There are two X.509 profiles for shadow PKI behind the DKI, with many of their X.509 fields mirroring content in the DRIP Endorsements. These PKIs can at times be used where X.509 is expected and non- constrained communication links are available that can handle their larger size. It is recommended that a DRIP deployment implement both of these along side the Endorsement trees. C509 (CBOR) encoding of all X.509 certificates are also provided as an alternative for where there are gains in reduced object size. | |||||||||||||
| draft-ietf-dtn-adm-yang-07.txt | ||||||||||||||
| DTNMA Application Data Model (ADM) YANG Syntax | ||||||||||||||
|
This document defines a concrete syntax for encoding a Delay-Tolerant Networking Management Architecture (DTNMA) Application Data Model (ADM) using the syntax and modular structure, but not the full data model, of YANG. Extensions to YANG are defined to capture the specifics needed to define DTNMA Application Management Model (AMM) objects and to use the Application Resource Identifier (ARI) data- value syntax. | |||||||||||||
| draft-ietf-dtn-amm-07.txt | ||||||||||||||
| DTNMA Application Management Model (AMM) and Data Models | ||||||||||||||
|
This document defines a model that captures the information necessary to asynchronously manage applications within the Delay-Tolerant Networking Management Architecture (DTNMA). This model provides a set of common managed object types, data types and structures, and a template for information needed within each application data model. The built-in definitions are made to be extensible by applications without needing to modify core Agent or Manager behavior. | |||||||||||||
| draft-ietf-dtn-amp-04.txt | ||||||||||||||
| DTNMA Asynchronous Management Protocol (AMP) | ||||||||||||||
|
This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport binding for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing remote management of resource constrained devices possibly over challenged networks. | |||||||||||||
| draft-ietf-dtn-ari-09.txt | ||||||||||||||
| DTNMA Application Resource Identifier (ARI) | ||||||||||||||
|
This document defines the structure, format, and features of the naming scheme for the objects defined in the Delay-Tolerant Networking Management Architecture (DTNMA) Application Management Model (AMM), in support of challenged network management solutions described in the DTNMA document. This document defines the DTNMA Application Resource Identifier (ARI), using a text-form based on the common Uniform Resource Identifier (URI) and a binary-form based on Concise Binary Object Representation (CBOR). These meet the needs for a concise, typed, parameterized, and hierarchically organized set of managed data elements. | |||||||||||||
| draft-ietf-dtn-bibe-00.txt | ||||||||||||||
| Bundle-in-Bundle Encapsulation | ||||||||||||||
|
This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) tunneling mechanism by which a bundle is carried as the payload of one or more encapsulating bundles, allowing security measures, routing policy, and protocol version translation to be applied to the encapsulating bundle without modification of the encapsulated bundle. The protocol includes an optional segmentation mechanism, allowing a large encapsulated bundle to be carried in multiple encapsulating bundles. | |||||||||||||
| draft-ietf-dtn-bp-sand-04.txt | ||||||||||||||
| Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery (SAND) | ||||||||||||||
|
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). This protocol defines a general purpose advertisement mechanism with an initial set of message and data types able to be advertised by participating nodes in a BPv7 network. The focus of this document is for advertisement to topological neighbors about local neighborhoods but can be expanded upon in the future through extension points. | |||||||||||||
| draft-ietf-dtn-bpsec-cose-17.txt | ||||||||||||||
| Bundle Protocol Security (BPSec) COSE Context | ||||||||||||||
|
This document defines a security context suitable for using CBOR Object Signing and Encryption (COSE) algorithms within Bundle Protocol Security (BPSec) integrity and confidentiality blocks. A profile for COSE, organized by algorithm families, and for public key certificates are included for BPSec interoperation. This document updates BPSec RFC 9172 by providing Concise Data Definition Language (CDDL) rules for extensible security block content. | |||||||||||||
| draft-ietf-dtn-btpu-04.txt | ||||||||||||||
| Bundle Transfer Protocol - Unidirectional | ||||||||||||||
|
This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. | |||||||||||||
| draft-ietf-dtn-btpu-fec-02.txt | ||||||||||||||
| Forward Error Correction for the Bundle Transfer Protocol | ||||||||||||||
|
This document defines an optional extension to the Bundle Transfer Protocol - Unidirectional, as described in [BTPU], to enable forward error correction (FEC) coding to be applied selectively to the transfer of individual bundles on a case by case basis. The definition and use of FEC follows the FECFRAME framework defined in [RFC6363], and this document introduces new Message types to BTPU in order to carry the FEC information as defined in the framework. | |||||||||||||
| draft-ietf-dtn-eid-pattern-10.txt | ||||||||||||||
| Bundle Protocol Endpoint ID Patterns | ||||||||||||||
|
This document extends the Bundle Protocol Endpoint ID (EID) concept into an EID Pattern, which is used to categorize any EID as matching a specific pattern or not. EID Patterns are suitable for expressing configuration, for being used on-the-wire by protocols, and for being easily understandable by a layperson. EID Patterns include scheme- specific optimizations for expressing set membership and each scheme pattern includes text and binary encoding forms; the pattern for the "ipn" EID scheme being designed to be highly compressible in its binary form. This document also defines a Public Key Infrastructure Using X.509 (PKIX) Other Name form to contain an EID Pattern and a handling rule to use a pattern to match an EID. | |||||||||||||
| draft-ietf-dtn-udpcl-04.txt | ||||||||||||||
| Delay-Tolerant Networking UDP Convergence Layer Protocol Version 2 | ||||||||||||||
|
This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of the earlier experimental RFC 7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unacknowledged transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. | |||||||||||||
| draft-ietf-dult-threat-model-05.txt | ||||||||||||||
| DULT Threat Model | ||||||||||||||
|
Lightweight location-tracking tags are in wide use to allow users to locate items. These tags function as a component of a crowdsourced network in which devices belonging to other network users (e.g., phones) report which tags they see and their location, thus allowing the owner(s) of the tag to determine where their tag was most recently seen. While there are many legitimate uses of these tags, they are also susceptible to misuse for the purpose of stalking and abuse. A protocol that allows others to detect unwanted tracking must incorporate an understanding of the unwanted tracking landscape today. This document provides a threat analysis for this purpose, including a taxonomy of unwanted tracking and potential attacks against Detection of Unwanted Location Tracking (DULT) protocols. The document defines what is in and out of scope for the unwanted tracking protocols, and provides design requirements, constraints, and considerations for implementation of protocols to detect unwanted tracking. | |||||||||||||
| draft-ietf-ecrit-lost-planned-changes-18.txt | ||||||||||||||
| Validation of Locations Around a Planned Change | ||||||||||||||
|
This document defines an extension to the Location to Service Translation (LoST) protocol (RFC5222) that allows a LoST server to notify a client of planned changes to location data. This extension is only useful with the validation function of LoST. It is beneficial for LoST validation clients to be aware of planned changes, since at a known future date, previously valid records may become invalid, and new records may become valid. This extension adds an element to the | |||||||||||||
| draft-ietf-ecrit-similar-location-19.txt | ||||||||||||||
| A LoST extension to return complete and similar location info | ||||||||||||||
|
This document describes an extension to the LoST protocol of RFC 5222 that allows additional civic location information to be returned in a | |||||||||||||
| draft-ietf-ediint-rfc4130bis-02.txt | ||||||||||||||
| AS2 Specification Modernization | ||||||||||||||
|
This document provides an applicability statement (RFC 2026, Section 3.2) describing how to securely exchange structured business data over HTTP. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts (see Section 10.1). Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1" (RFC 3335). This document obsoletes RFC 4130 and stands on its own without reference to AS1 or SMTP, except where required for IANA registry updates. This document also updates IANA registries originally created by RFC 3335 and RFC 4130. | |||||||||||||
| draft-ietf-emailcore-as-30.txt | ||||||||||||||
| Applicability Statement for IETF Core Email Protocols | ||||||||||||||
|
Electronic mail is one of the oldest Internet applications that is still in very active use. While the basic protocols and formats for mail transport and message formats have evolved slowly over the years, events and thinking in more recent years have supplemented those core protocols with additional features and suggestions for their use. This Applicability Statement describes the relationship among many of those protocols and provides guidance and makes recommendations for the use of features of the core protocols. | |||||||||||||
| draft-ietf-emailcore-iana-cleanup-03.txt | ||||||||||||||
| Updates to SMTP related IANA registries | ||||||||||||||
|
While EMAILCORE working group was working on update to SMTP specification, it became clear that existing entries in SMTP related registries are missing information or contain stale information and need to be updated. This document updates such entries. | |||||||||||||
| draft-ietf-emailcore-rfc5321bis-44.txt | ||||||||||||||
| Simple Mail Transfer Protocol | ||||||||||||||
|
This document is a specification of the basic protocol for Internet electronic mail transport. It (including text carried forward from RFC 5321) consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. The document also provides information about use of SMTP for other than strict mail transport and delivery. This document replaces RFC 5321, the earlier version with the same title, and supersedes RFCs 1846, 7504, and 7505, incorporating all the relevant information in them. | |||||||||||||
| draft-ietf-emailcore-rfc5322bis-12.txt | ||||||||||||||
| Internet Message Format | ||||||||||||||
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 5322, itself a revision of Request For Comments (RFC) 2822, all of which supersede Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. | |||||||||||||
| draft-ietf-emu-eap-edhoc-12.txt | ||||||||||||||
| Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC) | ||||||||||||||
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. | |||||||||||||
| draft-ietf-emu-eap-ppt-03.txt | ||||||||||||||
| Extensible Authentication Protocol (EAP) Using Privacy Pass Token | ||||||||||||||
|
This document describes Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol specifies use of the Privacy Pass token for client authentication within EAP as defined in RFC3748. Privacy Pass is a privacy preserving authentication mechanism used for authorization, as defined in RFC9576. EAP-PPT must be performed only in a tunnel-based EAP method. | |||||||||||||
| draft-ietf-emu-pqc-eap-tls-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-emu-pqc-eapaka-02.txt | ||||||||||||||
| Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) in EAP-AKA prime | ||||||||||||||
|
Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) is specified in [RFC9678], providing updates to [RFC9048] with an optional extension that offers ephemeral key exchange using the traditional Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement algorithm for achieving perfect forward secrecy (PFS). However, it is susceptible to future threats from Cryptographically Relevant Quantum Computers, which could potentially compromise a traditional ephemeral public key. If the adversary has also obtained knowledge of the long-term key and ephemeral public key, it could compromise session keys generated as part of the authentication run in EAP-AKA'. This draft aims to enhance the security of EAP-AKA' FS protocol by making it quantum-safe using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs). | |||||||||||||
| draft-ietf-emu-teapv2-00.txt | ||||||||||||||
| Tunnel Extensible Authentication Protocol (TEAP) Version 2 | ||||||||||||||
|
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 2. It addresses a number of security and interoperability issues which were found during the publication of TEAPv1 ([I-D.ietf-emu-rfc7170bis]). | |||||||||||||
| draft-ietf-fann-problem-statement-00.txt | ||||||||||||||
| Fast Network Notifications Problem Statement | ||||||||||||||
|
Many network applications, ranging from Artificial Intelligence (AI) /Machine Learning (ML) training/inference to cloud services, require networks with various combination of high bandwidth, low delay and low jitter and minimal packet loss in data transfer. This requires that the networks must rapidly adapt to the presence of faults, degradation and congestion. However, existing routing and traffic management mechanisms often face limitations in responsiveness, coverage, and operational complexity, particularly in large-scale and high-bandwidth network environments (e.g. data center (DC) and data center interconnect (DCI)). A good and timely understanding of network conditions can help to enable faster response to critical events, so as to enable the selection of paths with reduced latency and improve network utilization. This document describes the gap analysis and the need for fast network notification, and identifies the set of problems which a fast network notification solution needs to address. | |||||||||||||
| draft-ietf-green-framework-02.txt | ||||||||||||||
| Framework for Energy Efficiency Management | ||||||||||||||
|
Recognizing the urgent need for energy efficiency, this document specifies a management framework focused on networks, devices and device components within, or connected to, interconnected systems. The framework aims to enable energy usage optimization, based on the network condition while achieving the network's functional and performance requirements (e.g., improving overall network utilization) and also ensure interoperability across diverse systems. Leveraging data from existing use cases, it delivers actionable metrics to support effective energy management and informed decision- making. Furthermore, the framework defines mechanisms for representing and organizing timestamped telemetry data using YANG data models and metadata, enabling transparent and reliable monitoring. This structured approach facilitates improved energy efficiency through consistent energy management practices. | |||||||||||||
| draft-ietf-green-power-and-energy-yang-04.txt | ||||||||||||||
| Power and Energy YANG Module | ||||||||||||||
|
This document defines the YANG data model for Power and Energy monitoring of devices within or connected to communication networks. | |||||||||||||
| draft-ietf-green-terminology-02.txt | ||||||||||||||
| Terminology for Energy Efficiency Network Management | ||||||||||||||
|
Energy-efficient network management is primarily meant to enhance conventional network management with energy-related management capabilities that optimize overall network energy consumption. To that aim, specific features and capabilities are required to control (and thus optimize) the energy use of involved network elements and their components. This document defines a set of key terms used within the IETF when discussing energy efficiency in network management. Such reference document helps framing discussion and agreeing upon a set of main concepts in this area. | |||||||||||||
| draft-ietf-green-use-cases-02.txt | ||||||||||||||
| Use Cases for Energy Efficiency Management | ||||||||||||||
|
This document groups use cases for Energy efficiency Management of network devices. Discussion Venues Source of this draft and an issue tracker can be found at https://github.com/emile22/draft-ietf-green-use-cases | |||||||||||||
| draft-ietf-grow-as-path-prepending-19.txt | ||||||||||||||
| AS Path Prepending | ||||||||||||||
|
Autonomous System (AS) path prepending is a tool to manipulate the BGP AS_PATH attribute through prepending one or more Autonomous System Numbers (ASNs). AS path prepending is used to deprioritize a route in the presence of a route with a shorter AS_PATH. By prepending a local ASN multiple times, ASes can make advertised AS paths appear artificially longer. However, excessive AS path prepending has caused routing issues in the Internet. This document provides guidance for the use of AS path prepending, including alternative solutions, in order to avoid negatively affecting the Internet. | |||||||||||||
| draft-ietf-grow-bgpopsecupd-15.txt | ||||||||||||||
| BGP Operations and Security | ||||||||||||||
|
The Border Gateway Protocol (BGP) is a critical component in the Internet to exchange routing information between network domains. It is important to understand the security and reliability requirements that can and should be met to prevent accidental or intentional routing disturbances. Previously, security considerations for BGP have been described in RFC7454 / BCP194. Since the publication of RFC7454, changes in operational practice have taken place, which are partially conflicting with the advice given in RFC7454. This document obsoletes RFC7454, and provides less implementation-specific best practices, with the goal of being less prone to becoming outdated or conflicting with changed operational practices. | |||||||||||||
| draft-ietf-grow-bmp-over-quic-00.txt | ||||||||||||||
| Using BMP over QUIC connection | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) provides a convenient interface for obtaining route views by monitoring BGP sessions. BMP operates over TCP and is unidirectional (from client to server). QUIC provides multiple simultaneous streams to carry data in one direction, enabling much better efficiency and performance for both peers, in particular unidirectional streams can provide reverse data protection for the sender. QUIC also provides shorter handshake and includes TLS. This document describes how to use BMP over the QUIC transport protocol, named BMPoQUIC. | |||||||||||||
| draft-ietf-grow-bmp-path-marking-tlv-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-grow-bmp-rel-06.txt | ||||||||||||||
| Logging of routing events in BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) does provide for BGP session event logging (Peer Up, Peer Down), state synchronization (Route Monitoring), debugging (Route Mirroring) and Statistics messages, among others. This document defines a new Route Event Logging (REL) message type for BMP with the aim of covering use cases with affinity to alerting, reporting and on-change analysis. | |||||||||||||
| draft-ietf-grow-bmp-stats-informational-tlv-01.txt | ||||||||||||||
| 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, percentiles, or snapshot values. This enables BMP collectors to better understand the dynamics of monitored statistics even when the reported snapshot values appear constant. | |||||||||||||
| draft-ietf-grow-bmp-tlv-21.txt | ||||||||||||||
| BMP v4: Extended TLV Support for BGP Monitoring Protocol (BMP) | ||||||||||||||
|
Most of the BGP Monitoring Protocol (BMP) message types make provision for data in Type, Length, Value (TLV) format. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) Stats Reports (which supply periodical counters) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting (optional) data in TLV format across all BMP message types provides consistent and extensible structures that would be useful among the various use- cases where conveying additional data to a monitoring station is required. This document updates RFC 7854 [RFC7854] to support TLV data in all message types and defines some essential TLVs. Additionally, this document introduces support for enterprise- specific TLVs in the BGP Monitoring Protocol by defining an Enterprise Bit (E-bit) that allows usage of per-vendor Type values. | |||||||||||||
| draft-ietf-grow-bmp-yang-09.txt | ||||||||||||||
| A YANG Data Model for BMP | ||||||||||||||
|
This document defines a YANG data model for the configuration and monitoring of the BGP Monitoring Protocol (BMP). | |||||||||||||
| draft-ietf-grow-nrtm-v4-11.txt | ||||||||||||||
| Near Real Time Mirroring (NRTM) version 4 | ||||||||||||||
|
This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records, called Near Real Time Mirroring version 4 (NRTMv4), in which files are distributed over HTTPS. The protocol allows instances of IRR database servers to mirror IRR records, specified in the Routing Policy Specification Language (RPSL), between each other. | |||||||||||||
| draft-ietf-grow-routing-ops-sec-inform-02.txt | ||||||||||||||
| Current Options for Securing Global Routing | ||||||||||||||
|
The Border Gateway Protocol (BGP) is the protocol is a critical component in the Internet to exchange routing information between network domains. Due to this central nature, it is an accepted best practice to ensure basic security properties for BGP and BGP speaking routers. While these general principles are outlined in BCP194, it does not provide a list of technical and implementation options for securing BGP. This document lists available options for securing BGP, serving as a contemporary, non-exhaustive, repository of options and methods. The document explicitly does not make value statements on the efficacy of individual techniques, not does it mandate or prescribe the use of specific technique or implementations. Operators are advised to carefully consider whether the listed methods are applicable for their use-case to ensure best current practices are followed in terms of which security properties need to be ensured when operating BGP speakers. Furthermore, the listed options in this document may change over time, and should not be used as a timeless ground-truth of applicable or sufficient methods. | |||||||||||||
| draft-ietf-grow-routing-ops-terms-02.txt | ||||||||||||||
| Currently Used Terminology in Global Routing Operations | ||||||||||||||
|
Operating the global routing ecosystem entails a divers set of interacting components, while operational practice evolved over time. In that time, terms emerged, disappeared, and sometimes changed their meaning. To aid operators and implementers in reading contemporary drafts, this document provides an overview of terms and abbreviations used in the global routing operations community. The document explicitly does not serve as an authoritative source of correct terminology, but instead strives to provide an overview of practice. | |||||||||||||
| draft-ietf-grow-rpsl-registry-scoped-members-00.txt | ||||||||||||||
| Registry scoped members for RPSL set objects | ||||||||||||||
|
This document updates RFC2622 and RFC4012 by specifying src-members, a new attribute on as-set and route-set objects in the Routing Policy Specification Language (RPSL). This attribute allows a specific registry to be defined for each member in a set, avoiding problematic ambiguity when resolving set members. A new validation rule allows gradual upgrades and backwards compatibility. | |||||||||||||
| draft-ietf-grow-yang-bgp-communities-10.txt | ||||||||||||||
| A YANG Data Model for BGP Communities | ||||||||||||||
|
This document defines a YANG data model for the structured specification of BGP communities. The model provides operators with a way to publish their locally defined BGP communities in a standardized format. Two YANG modules are defined in this document. The first is designed for stand-alone usage. The second is used to augment the "ietf-bgp" YANG module[I-D.ietf-idr-bgp-model] with BGP community annotations. Additionally, this document provides an optional discovery mechanism based on publishing of community definition locations through the Resource Public Key Infrastructure (RPKI). | |||||||||||||
| draft-ietf-happy-happyeyeballs-v3-04.txt | ||||||||||||||
| Happy Eyeballs Version 3: Better Connectivity Using Concurrency | ||||||||||||||
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document defines the algorithm for "Happy Eyeballs", a technique for reducing user-visible delays on dual-stack hosts. This document updates the algorithm in RFC 8305. | |||||||||||||
| draft-ietf-hpke-hpke-04.txt | ||||||||||||||
| Hybrid Public Key Encryption | ||||||||||||||
|
This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes a variant that authenticates possession of a pre-shared key. HPKE works for any combination of an asymmetric Key Encapsulation Mechanism (KEM), key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. This document provides instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA-2. This document obsoletes RFC 9180. | |||||||||||||
| draft-ietf-hpke-pq-05.txt | ||||||||||||||
| Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE | ||||||||||||||
|
Updating key exchange and public-key encryption protocols to resist attack by quantum computers is a high priority given the possibility of "harvest now, decrypt later" attacks. Hybrid Public Key Encryption (HPKE) is a widely-used public key encryption scheme based on combining a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme. In this document, we define KEM algorithms for HPKE based on both post-quantum KEMs and hybrid constructions of post- quantum KEMs with traditional KEMs, as well as a KDF based on SHA-3 that is suitable for use with these KEMs. When used with these algorithms, HPKE is resilient with respect to attacks by a quantum computer. | |||||||||||||
| draft-ietf-httpapi-digest-fields-problem-types-06.txt | ||||||||||||||
| HTTP Problem Types for Digest Fields | ||||||||||||||
|
This document specifies HTTP problem types that servers can use in responses to problems encountered while dealing with a request carrying integrity fields and integrity preference fields. Using an HTTP problem type, the server can provide machine-readable error details to aid debugging or error reporting. | |||||||||||||
| draft-ietf-httpapi-patch-byterange-04.txt | ||||||||||||||
| Byte Range PATCH | ||||||||||||||
|
This document specifies a media type for PATCH payloads that overwrites a specific byte range, facilitating random access writes and segmented uploads of resources. | |||||||||||||
| draft-ietf-httpapi-privacy-06.txt | ||||||||||||||
| Protecting Credentials with HTTP APIs | ||||||||||||||
|
Redirecting HTTP requests to HTTPS is a common pattern for human- facing web resources. When done for authenticated HTTP API traffic, client credentials are exposed to the network. This document discusses the pitfalls of the redirect approach and makes deployment recommendations for authenticated HTTP APIs. It does not specify a protocol. | |||||||||||||
| draft-ietf-httpapi-ratelimit-headers-11.txt | ||||||||||||||
| RateLimit header fields for HTTP | ||||||||||||||
|
This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. | |||||||||||||
| draft-ietf-httpapi-rest-api-mediatypes-09.txt | ||||||||||||||
| REST API Media Types | ||||||||||||||
|
This document registers the following media types used in APIs on the IANA Media Types registry: application/openapi+json, and application/ openapi+yaml. | |||||||||||||
| draft-ietf-httpbis-connect-tcp-14.txt | ||||||||||||||
| Template-Driven HTTP CONNECT Proxying for TCP | ||||||||||||||
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. | |||||||||||||
| draft-ietf-httpbis-layered-cookies-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-httpbis-no-vary-search-09.txt | ||||||||||||||
| The No-Vary-Search HTTP Caching Extension | ||||||||||||||
|
This specification defines an extension to HTTP Caching, changing how the URI query component impacts caching. It introduces the "No-Vary- Search" response header field, which allows origin servers to signal to caches that certain parts of the query component do not semantically affect the served response and can be ignored for cache matching purposes. | |||||||||||||
| draft-ietf-httpbis-pre-denied-01.txt | ||||||||||||||
| The Purpose Declined HTTP Status Code | ||||||||||||||
|
This specification defines an HTTP status code to indicate that the server is denying a request based upon its declared purpose. | |||||||||||||
| draft-ietf-httpbis-resumable-upload-12.txt | ||||||||||||||
| Resumable Uploads for HTTP | ||||||||||||||
|
HTTP data transfers can encounter interruption due to reasons such as canceled requests or dropped connections. If the intended recipient can indicate how much of the data was processed prior to interruption, a sender can resume data transfer at that point instead of attempting to transfer all of the data again. HTTP range requests support this concept of resumable downloads from server to client. This document describes a mechanism that supports resumable uploads from client to server using HTTP. | |||||||||||||
| draft-ietf-httpbis-rfc6265bis-22.txt | ||||||||||||||
| 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 flaws that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265. | |||||||||||||
| draft-ietf-httpbis-secondary-server-certs-02.txt | ||||||||||||||
| Secondary Certificate Authentication of HTTP Servers | ||||||||||||||
|
This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. | |||||||||||||
| draft-ietf-httpbis-unencoded-digest-05.txt | ||||||||||||||
| HTTP Unencoded Digest | ||||||||||||||
|
The Repr-Digest and Content-Digest integrity fields are subject to HTTP content coding considerations. There are some use cases that benefit from the unambiguous exchange of integrity digests of unencoded representation. The Unencoded-Digest and Want-Unencoded- Digest fields complement existing integrity fields for this purpose. This document updates the definitions of the terms "Integrity fields" and "Integrity preference fields" originally defined in RFC 9530. | |||||||||||||
| draft-ietf-i2nsf-applicability-19.txt | ||||||||||||||
| Applicability of Interfaces to Network Security Functions to Network-Based Security Services | ||||||||||||||
|
This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. | |||||||||||||
| draft-ietf-i2nsf-capability-data-model-32.txt | ||||||||||||||
| I2NSF Capability YANG Data Model | ||||||||||||||
|
This document defines an information model and the corresponding YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. | |||||||||||||
| draft-ietf-i2nsf-consumer-facing-interface-dm-31.txt | ||||||||||||||
| I2NSF Consumer-Facing Interface YANG Data Model | ||||||||||||||
|
This document describes a YANG data model of the Consumer-Facing Interface of the Security Controller in an Interface to Network Security Functions (I2NSF) system in a Network Functions Virtualization (NFV) environment. This document defines various types of managed objects and the relationship among them needed to build the flow policies from users' perspective. The YANG data model is based on the "Event-Condition-Action" (ECA) policy defined by a capability YANG data model for I2NSF. The YANG data model enables different users of a given I2NSF system to define, manage, and monitor flow policies within an administrative domain (e.g., user group). | |||||||||||||
| draft-ietf-i2nsf-nsf-facing-interface-dm-29.txt | ||||||||||||||
| I2NSF Network Security Function-Facing Interface YANG Data Model | ||||||||||||||
|
This document defines a YANG data model for configuring security policy rules on Network Security Functions (NSF) in the Interface to Network Security Functions (I2NSF) framework. The YANG data model in this document is for the NSF-Facing Interface between a Security Controller and NSFs in the I2NSF framework. It is built on the basis of the YANG data model in the I2NSF Capability YANG Data Model document for the I2NSF framework. | |||||||||||||
| draft-ietf-i2nsf-nsf-monitoring-data-model-20.txt | ||||||||||||||
| I2NSF NSF Monitoring Interface YANG Data Model | ||||||||||||||
|
This document proposes an information model and the corresponding YANG data model of an interface for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed with the NSF monitoring interface in a standard way, it is possible to detect the indication of malicious activity, anomalous behavior, the potential sign of denial-of-service attacks, or system overload in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only an information model for the NSF monitoring interface along with a YANG tree diagram, but also the corresponding YANG data model. | |||||||||||||
| draft-ietf-i2nsf-registration-interface-dm-26.txt | ||||||||||||||
| I2NSF Registration Interface YANG Data Model for NSF Capability Registration | ||||||||||||||
|
This document defines a YANG data model for the Registration Interface between Security Controller and Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) framework to register Network Security Functions (NSF) of the DMS with the Security Controller. The objective of this data model is to support NSF capability registration and query via I2NSF Registration Interface. | |||||||||||||
| draft-ietf-ianabis-early-registries-02.txt | ||||||||||||||
| Early IANA Registry Creation | ||||||||||||||
|
This memo describes the requirements for establishing an IANA registry before the IETF Stream document that creates the registry is approved for publication as an RFC. This process can be used when an IETF working group needs to coordinate allocations among multiple documents or with an organization outside the IETF. | |||||||||||||
| draft-ietf-ianabis-rfc7120bis-03.txt | ||||||||||||||
| Early IANA Code Point Allocation | ||||||||||||||
|
This document describes the requirements for securing IANA code point assignments for IETF Stream Internet-Drafts and specifications being drafted by other standards-related organizations. This document obsoletes RFC 7120. | |||||||||||||
| draft-ietf-ianabis-rfc8126bis-03.txt | ||||||||||||||
| Guidelines for Writing an IANA Considerations Section in RFCs | ||||||||||||||
|
Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the fourth edition of this document; it obsoletes RFC 8126. | |||||||||||||
| draft-ietf-idr-5g-edge-service-metadata-33.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-ietf-idr-bgp-attribute-escape-00.txt | ||||||||||||||
| BGP Attribute Escape | ||||||||||||||
|
BGP-4 [RFC 4271] has been very successful in being extended over the years it has been deployed. A significant part of that success is due to its ability to incrementally add new features to its Path Attributes when they are marked "optional transitive". Implementations that are ignorant of a feature for an unknown Path Attribute that are so marked will propagate BGP routes with such attributes. Unfortunately, this blind propagation of unknown Path Attributes may happen for features that are intended to be used in a limited scope. When such Path Attributes inadvertently are carried beyond that scope, it can lead to things such as unintended disclosure of sensitive information, or cause improper routing. In their worst cases, such propagation may be for malformed Path Attributes and lead to BGP session resets or crashes. This document calls such inadvertent propagation of BGP Path Attributes, "attribute escape". This document further describes some of the scenarios that leads to this behavior and makes recommendations on practices that may limit its impact. | |||||||||||||
| draft-ietf-idr-bgp-bestpath-selection-criteria-13.txt | ||||||||||||||
| BGP Bestpath Selection Criteria Enhancement | ||||||||||||||
|
BGP specification (RFC4271) prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and would desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. | |||||||||||||
| draft-ietf-idr-bgp-bfd-strict-mode-19.txt | ||||||||||||||
| BGP BFD Strict-Mode | ||||||||||||||
|
This document specifies extensions to RFC4271 BGP-4 that enable a BGP speaker to negotiate additional Bidirectional Forwarding Detection (BFD) extensions using a BGP capability. This BFD Strict-Mode Capability enables a BGP speaker to prevent a BGP session from being established until a BFD session is established. This is referred to as BFD "strict-mode". | |||||||||||||
| draft-ietf-idr-bgp-fsm-iana-02.txt | ||||||||||||||
| IANA Registrations for the BGP Finite State Machine (FSM) | ||||||||||||||
|
The Border Gateway Protocol, version 4 (BGP-4) finite state machine (FSM) is defined in RFC 4271. Over the years, various extensions to BGP have been authored that update the protocol's FSM. Some elements of the FSM are enumerated. Those elements are referred to across BGP extensions in their respective state machine changes, and may also be used for management purposes in things such as YANG (RFC 7950). To provide consistent naming and enumeration of these FSM elements, this document requests IANA to create and maintain registries for elements in the BGP FSM. | |||||||||||||
| draft-ietf-idr-bgp-ifit-capabilities-09.txt | ||||||||||||||
| Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP | ||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines a new Characteristic to advertise the In-situ Flow Information Telemetry (IFIT) capabilities. Within an IFIT domain, the IFIT capabilities advertisement from the tail node to the head node assists the head node to determine whether a particular IFIT Option type can be encapsulated in data packets. Such advertisement helps mitigating the leakage threat and facilitating the deployment of IFIT measurements on a per-service and on-demand basis. | |||||||||||||
| draft-ietf-idr-bgp-ls-bgp-only-fabric-07.txt | ||||||||||||||
| BGP Link-State Extensions for BGP-only Networks | ||||||||||||||
|
BGP is used as the only routing protocol in some networks today. In such networks, it is useful to get a detailed topology view similar to one available when using link state routing protocols. This document defines extensions to the BGP Link-state (BGP-LS) address- family and the procedures for advertisement of topology information in a BGP-only network. | |||||||||||||
| draft-ietf-idr-bgp-ls-flex-algo-ext-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-idr-bgp-ls-link-mtu-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle-09.txt | ||||||||||||||
| Segment Routing BGP Egress Peer Engineering over Layer 2 Bundle Members | ||||||||||||||
|
This document specifies how to support Segment Routing BGP Egress Peer Engineering over Layer 2 bundle members. It updates RFC 9085 to allow the L2 Bundle Member Attributes TLV in the BGP-LS Attribute of the BGP-LS Link NLRI for a BGP peering link. For SR-MPLS, it updates RFC 9085 and RFC 9086 to allow the PeerAdj SID TLV as a sub-TLV of the L2 Bundle Member Attributes TLV. | |||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-admin-flags-00.txt | ||||||||||||||
| Advertisement of SR Policy Operational States using BGP Link-State | ||||||||||||||
|
This document defines the extension of BGP Link-State to advertise the operational state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. | |||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-nrp-03.txt | ||||||||||||||
| SR Policies Extensions for Network Resource Partition in BGP-LS | ||||||||||||||
|
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 ID is an important network resource attribute associated with the Segment Routing (SR) policy and needs to be reported to the external components. This document defines a new TLV which enables the headend to report the NRP which the SR Policy Candidate Path (CP) is associated with using Border Gateway Protocol Link-State (BGP-LS). | |||||||||||||
| draft-ietf-idr-bgp-ls-sr-policy-path-segment-12.txt | ||||||||||||||
| SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS | ||||||||||||||
|
This document specifies the way of collecting configuration and states of SR policies carrying Path Segment and bidirectional path information by using BPG-LS. Such information can be used by external conponents for many use cases such as performance measurement, path re-optimization and end-to-end protection. | |||||||||||||
| draft-ietf-idr-bgp-model-21.txt | ||||||||||||||
| YANG Model for Border Gateway Protocol (BGP-4) | ||||||||||||||
|
This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier, and content provider operational requirements. | |||||||||||||
| draft-ietf-idr-bgp-sr-mpls-elp-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-idr-bgp4-rfc4271bis-01.txt | ||||||||||||||
| A Border Gateway Protocol 4 (BGP-4) | ||||||||||||||
|
This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP-speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 4271. | |||||||||||||
| draft-ietf-idr-bgpls-inter-as-topology-ext-44.txt | ||||||||||||||
| BGP-LS Extensions for Inter-AS Topology Retrieval | ||||||||||||||
|
This document specifies the procedures for distributing Border Gateway Protocol-Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems (ASes). It defines a new type within the BGP-LS Network Layer Reachability Information (NLRI) for an Inter-AS Link, along with three new Type-Length-Values (TLVs) descriptors for the BGP-LS Inter-AS Link. These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the inter-AS topology using information provided by the BGP-LS protocol. | |||||||||||||
| draft-ietf-idr-bgpls-sr-vtn-mt-14.txt | ||||||||||||||
| Applicability of Border Gateway Protocol - Link State (BGP-LS) with Multi-Topology (MT) for Segment Routing based Network Resource Partitions (NRPs) | ||||||||||||||
|
When Segment Routing (SR) is used for building Network Resource Partitions (NRPs), each NRP can be allocated with a group of Segment Identifiers (SIDs) to identify the topology and resource attributes of network segments in the NRP. This document describes how BGP-Link State (BGP-LS) with Multi-Topology (MT) can be used to distribute the information of SR-based NRPs to a network controller in a specific context where each NRP is associated with a separate logical topology identified by a Multi-Topology ID (MT-ID). This document sets out the targeted scenarios for the approach suggested, and presents the scalability limitations that arise. | |||||||||||||
| draft-ietf-idr-elc-01.txt | ||||||||||||||
| BGP Entropy Label Characteristic | ||||||||||||||
|
The BGP Next Hop Dependent Characteristics Attribute (NHC) provides a way for a BGP speaker to advertise certain characteristics of routes. In particular, it is useful to advertise forwarding plane features. This specification defines an NHC characteristic that can be used to advertise the ability to process the MPLS Entropy Label as an egress LSR for all NLRI advertised in the BGP UPDATE. It updates RFC 6790 and RFC 7447 concerning this BGP signaling. | |||||||||||||
| draft-ietf-idr-flowspec-nvo3-24.txt | ||||||||||||||
| BGP Dissemination of Flow Specification Rules for Tunneled Traffic | ||||||||||||||
|
This draft specifies a Border Gateway Protocol (BGP) Network Layer Reachability Information (NLRI) encoding format for flow specifications (RFC 8955) that can match on a variety of tunneled traffic. In addition, flow specification components are specified for certain tunneling header fields. | |||||||||||||
| draft-ietf-idr-flowspec-path-redirect-13.txt | ||||||||||||||
| Flowspec Indirection-id Redirect | ||||||||||||||
|
This document defines a new extended community known as "FlowSpec Redirect to indirection-id Extended Community". This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the operation of the available paths. | |||||||||||||
| draft-ietf-idr-flowspec-redirect-ip-16.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-ietf-idr-flowspec-srv6-10.txt | ||||||||||||||
| BGP Flow Specification for SRv6 | ||||||||||||||
|
This document specifies extensions to BGP Flow Specification (BGP-FS) to enable filtering of IPv6 packets based on the structural components of an SRv6 Segment Identifier (SID) present in the IPv6 Destination Address (representing the active segment of an SRv6 path). | |||||||||||||
| draft-ietf-idr-fsv2-ip-basic-07.txt | ||||||||||||||
| BGP Flow Specification Version 2 - for Basic IP | ||||||||||||||
|
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117, describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these issues. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2. The IDR WG requires two implementation. Early feedback on implementations of FSv2 indicate that FSv2 has a correct design direction, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions. | |||||||||||||
| draft-ietf-idr-linklocal-capability-06.txt | ||||||||||||||
| Link-Local Next Hop Capability for BGP | ||||||||||||||
|
To support IPv6 [RFC4291] reachability, BGP [RFC4271] relies on the Multiprotocol Extensions as defined in [RFC4760]. [RFC2545] defines the structure of IPv6 next hops. These IPv6 next hops may contain a Global IPv6 address, and optionally can contain an IPv6 Link-Local address when the BGP peer is directly attached and shares a common subnet with the IPv6 Global address. This document updates [RFC2545] to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 Link-Local address is available. A new BGP Capability [RFC5492] is defined to signal support for this updated encoding. This clarification applies specifically to IPv6 Link-Local addresses and does not pertain to IPv4 Link-Local addresses as defined in [RFC3927]. | |||||||||||||
| draft-ietf-idr-mpbgp-extension-4map6-06.txt | ||||||||||||||
| MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement | ||||||||||||||
|
This document defines MP-BGP extension and the procedures for IPv4 service delivery in multi-domain IPv6-only underlay networks. It defines a new TLV in the BGP Tunnel Encapsulation attribute, used in conjunction with a specific AFI/SAFI combination for advertising IPv4-over-IPv6 mapping rules. The behaviors of each type of network (IPv4 and IPv6) are also illustrated. In addition, this document provides the deployment and operation considerations when the extension is deployed. | |||||||||||||
| draft-ietf-idr-multinexthop-attribute-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-idr-next-next-hop-nodes-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-idr-nhc-07.txt | ||||||||||||||
| BGP Next Hop Dependent Characteristics Attribute | ||||||||||||||
|
RFC 5492 allows a BGP speaker to advertise its capabilities to a peer. When a route is propagated beyond the immediate peer, it is useful to allow certain characteristics to be conveyed further. In particular, it is useful to advertise forwarding plane features. This specification defines a BGP transitive attribute to carry such information, the "Next Hop Dependent Characteristics Attribute," or NHC. Unlike the capabilities defined by RFC 5492, the characteristics conveyed in the NHC apply solely to the routes advertised by the BGP UPDATE that contains the particular NHC. | |||||||||||||
| draft-ietf-idr-rfc4360-bis-09.txt | ||||||||||||||
| BGP Extended Communities Attribute | ||||||||||||||
|
This document describes the "Extended Communities" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. This document obsoletes RFC 4360. This document also updates RFC 5701 by adding an "Operational Considerations" section. | |||||||||||||
| draft-ietf-idr-rt-derived-community-10.txt | ||||||||||||||
| Extended Communities Derived from Route Targets | ||||||||||||||
|
This document specifies a way to derive an Extended Community from a Route Target and describes some example use cases. | |||||||||||||
| draft-ietf-idr-rtc-hierarchical-rr-06.txt | ||||||||||||||
| RT-Constrain Optimization in Hierarchical Route Reflection Scenarios | ||||||||||||||
|
The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes solutions to address the RT-Constrain issue in hierarchical RR scenarios. | |||||||||||||
| draft-ietf-idr-rtc-interas-00.txt | ||||||||||||||
| Inter Domain considerations for Constrained Route distribution | ||||||||||||||
|
RFC4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information in order to limit the propagation of Virtual Private Networks (VPN) Network Layer Reachability Information (NLRI). RFC4684 addresses both intra domain and inter domain distributions. Operational deployment experience shows that the current distribution model defined in RFC4684 for inter domain may cause some issue in specific scenarios. This document proposes alternate route distribution rules for inter domain in order to address these specific scenarios. | |||||||||||||
| draft-ietf-idr-sdwan-edge-discovery-31.txt | ||||||||||||||
| SD-WAN Edge and Underlay Tunnel Discovery Using BGP | ||||||||||||||
|
This document specifies BGP mechanisms for SD-WAN (Software-Defined Wide Area Network) edge node attribute discovery. These mechanisms comprise a new tunnel type and associated Sub-TLVs for the BGP Tunnel Encapsulation Attribute, and a new Subsequent Address Family Identifier (SAFI) carrying a typed NLRI for advertising SD-WAN underlay tunnel information. | |||||||||||||
| draft-ietf-idr-sr-p2mp-policy-01.txt | ||||||||||||||
| Advertising p2mp policies in BGP | ||||||||||||||
|
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. A P2MP policy consists of candidate paths (CPs) that connects the Root of the Tree to a set of Leaves. The P2MP policy is composed of replication segments [RFC9524]. A replication segment is a forwarding instruction for a candidate path which is downloaded to the Root, transit nodes and the leaves. This document specifies a new BGP SAFI with a new NLRI in order to advertise P2MP policy from a controller to a set of nodes. This document introduces three new route types within this NLRI, one for P2MP policy and its candidate paths that need to be programmed on the Root node, one for the replication segment incoming SID which uniquely will identify the replication state and another for each outgoing interface that the packets get replicated to. The last two route types are forwarding instructions that needs to be programmed on the Root, and optionally on Transit and Leaf nodes. It should be noted that this document does not specify how the Root and the Leaves are discovered on the controller, it only describes how the P2MP Policy and Replication Segments are programmed from the controller to the nodes. | |||||||||||||
| draft-ietf-idr-sr-policy-admin-flags-00.txt | ||||||||||||||
| BGP SR Policy Extensions for Administrative Flags | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines an extension to the BGP SR Policy that sets the administrative state of the candidate path or segment list, facilitating the operation and maintenance of the SR Policy. | |||||||||||||
| draft-ietf-idr-sr-policy-ifit-12.txt | ||||||||||||||
| BGP SR Policy Extensions to Enable IFIT | ||||||||||||||
|
Segment Routing (SR) policy is a set of candidate SR paths consisting of one or more segment lists and necessary path attributes. It enables instantiation of an ordered list of segments with a specific intent for traffic steering. In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular the most popular are In-situ OAM (IOAM) and Alternate Marking. This document defines extensions to BGP to distribute SR policies carrying IFIT information. So that IFIT methods can be enabled automatically when the SR policy is applied. | |||||||||||||
| draft-ietf-idr-sr-policy-metric-05.txt | ||||||||||||||
| BGP SR Policy Extensions for Metric | ||||||||||||||
|
An SR Policy consists of one or more Candidate Paths (CPs), each comprising one or more segment lists. BGP can be used to propogate SR Policy CPs to the SR Policy headend nodes in the network. After an SR Policy CP is installed on the headend node, packets can be steered into the SR Policy. For a particular BGP destination, if there are multiple BGP routes with different next-hops, BGP best path selection is performed and the IGP metric to the next-hop node may be used for tie-breaking to select the best path. When the path to the next-hop is resolved over an SR Policy, the IGP metric of the SR policy is needed for BGP path selection. This document defines the BGP extensions to carry the IGP metric of segment lists when BGP is used to propagate SR Policy CPs. | |||||||||||||
| draft-ietf-idr-sr-policy-nrp-13.txt | ||||||||||||||
| BGP SR Policy Extensions for Network Resource Partition | ||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. The header of a packet steered in an SR Policy is augmented with an ordered list of segments associated with that SR Policy. A Network Resource Partition (NRP) is a subset of network resources allocated in the underlay network which can be used to support one or a group of RFC 9543 network slice services. In networks where there are multiple NRPs, an SR Policy may be associated with a particular NRP. The association between SR Policy and NRP needs to be specified, so that for service traffic which is steered into the SR Policy, the header of the packets can be augmented with the information associated with the NRP. An SR Policy candidate path can be distributed using BGP SR Policy. This document defines the extensions to BGP SR Policy to specify the NRP which the SR Policy candidate path is associated with. | |||||||||||||
| draft-ietf-idr-sr-policy-path-mtu-15.txt | ||||||||||||||
| Segment Routing Path MTU in BGP | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR policy is a set of SR Policy candidate paths consisting of one or more segments with the appropriate SR path attributes. BGP distributes each SR Policy candidate path as combination of an prefix plus a the BGP Tunnel Encapsulation(Tunnel-Encaps) attribute containing an SR Policy Tunnel TLV with information on the SR Policy candidate path as a tunnel. However, the path maximum transmission unit (MTU) information for a segment list for SR path is not currently passed in the BGP Tunnel-Encaps attribute. . This document defines extensions to BGP to distribute path MTU information within SR policies. | |||||||||||||
| draft-ietf-idr-sr-policy-path-segment-16.txt | ||||||||||||||
| SR Policy Extensions for Path Segment and Bidirectional Path | ||||||||||||||
|
BGP SR Policy address-family is used for signaling of individual candidate paths of a Segment Routing Policy. This document specifies extensions for the signaling of a Path Segment Identifier associated with the Segment List(s) of a candidate path. It also specifies extensions for the signaling of the Segment List(s) in the reverse direction when Bidirectional SR Policies are used. | |||||||||||||
| draft-ietf-idr-sr-policy-seglist-id-14.txt | ||||||||||||||
| BGP SR Policy Extensions for Segment List Identifier | ||||||||||||||
|
Segment Routing (SR) is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. This document defines extensions to BGP SR Policy to specify the identifier of a segment list. | |||||||||||||
| draft-ietf-idr-sr-te-policy-attr-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-idr-ts-flowspec-srv6-policy-18.txt | ||||||||||||||
| Traffic Steering using BGP FlowSpec with SR Policy | ||||||||||||||
|
BGP Flow Specification (FlowSpec) provides mechanisms to distribute traffic filtering and steering rules across BGP networks. This document specifies BGP FlowSpec procedures to steer matching traffic flows into Segment Routing (SR) Policies. Specifically, it defines protocol mechanisms for combining FlowSpec NLRIs with specific BGP Extended Communities for transport policy steering (Mode 1) in SR- MPLS and SRv6 networks, and optionally with the BGP Prefix-SID Attribute when egress service action execution is required (Mode 2) in SRv6 networks. | |||||||||||||
| draft-ietf-idr-vpn-prefix-orf-45.txt | ||||||||||||||
| VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 | ||||||||||||||
|
This document defines an experimental specification for a new type of Outbound Route Filter (ORF), known as the Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwarding (VRF) instances are exchanged through a single shared Border Gateway Protocol (BGP) session. The purpose of the VPN Prefix ORF mechanism is to control the overload of VPN routes based on Route Distinguisher (RD), Route Target (RT) and other necessary routing information. This mechanism is applicable to intra-domain scenarios. | |||||||||||||
| draft-ietf-intarea-arp-yang-model-01.txt | ||||||||||||||
| A YANG Data Model for ARP Extensions | ||||||||||||||
|
This document defines a YANG data model for the management of the Address Resolution Protocol (ARP). It extends the basic ARP functionality contained in the ietf-ip YANG data model, defined in RFC 8344, to provide management of optional ARP features and statistics. | |||||||||||||
| draft-ietf-intarea-dhcp-rate-signaling-00.txt | ||||||||||||||
| DHCP Explicit Rate Signaling | ||||||||||||||
|
This document defines new Dynamic Host Configuration Protocol (DHCP) options for both DHCPv4 and DHCPv6 to explicitly signal available upstream and downstream data rates. In many broadband access networks, Customer Premises Equipment (CPE) and intermediate nodes lack visibility into the subscriber's provisioned service tier. By communicating these capacities natively via DHCP, clients, relay agents, and snooping switches can dynamically configure localized traffic shaping and queuing. This explicit signaling improves overall network performance by reducing the reliance on indiscriminate packet dropping and policing at the service edge. Additionally, it provides the necessary capacity awareness to enable effective Active Queue Management (AQM) and the Low Latency, Low Loss, and Scalable Throughput (L4S) architecture. | |||||||||||||
| draft-ietf-intarea-extended-icmp-nodeid-05.txt | ||||||||||||||
| ICMP Message Extension for Originating Node Identification | ||||||||||||||
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all next-hops are IPv6 next-hops, even for IPv4 routes). | |||||||||||||
| draft-ietf-intarea-ipv6-resolved-gateway-00.txt | ||||||||||||||
| IPv6-Resolved IPv4 Gateway | ||||||||||||||
|
This document specifies host behavior enabling IPv4 communication for dual-stack hosts on IPv6-only segments, without subnets, ARP, tunneling, or translation. Hosts that receive 192.0.0.11/32 as their IPv4 default gateway address resolve the next-hop link-layer address from the IPv6 neighbor cache rather than via ARP. IPv4 packets are forwarded natively, end-to-end. The mechanism is incrementally deployable alongside unmodified hosts with no changes to DHCPv4 infrastructure. This document requests the allocation of 192.0.0.11/32 in the IANA IPv4 Special-Purpose Address Registry to support this mechanism. | |||||||||||||
| draft-ietf-intarea-legacy-registries-00.txt | ||||||||||||||
| Updates to Legacy IANA Registries | ||||||||||||||
|
IANA maintains several registries that were created for IPv4. As the IPv4 core specification is no longer being extended and as some other registries do not have a defined IANA registration procedure, these registries need to be updated to indicate a registration procedure or to reflect the current practice that defining such extensions is not recommended. | |||||||||||||
| draft-ietf-intarea-multicast-application-port-08.txt | ||||||||||||||
| The Multicast Application Port | ||||||||||||||
|
This document discusses the drawbacks of the current practice of assigning a UDP port to each multicast application. Such assignments are redundant because the multicast address already uniquely identifies the data. The document assigns a UDP port specifically for use with multicast applications and lists requirements for using this port. This approach provides immediate compatibility with existing protocol stacks, while also requiring improvements to make the port easier to use. | |||||||||||||
| draft-ietf-intarea-proxy-config-14.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-intarea-reordering-00.txt | ||||||||||||||
| Proposal for Updates to Guidance on Packet Reordering | ||||||||||||||
|
Several link technology standards mandate that equipment guarantee in-order delivery of layer 2 frames, apparently due to a belief that this is required by higher layer protocols. To meet this requirement they implement a "resequencing" operation to restore the original packet order. This can introduce delays that result in net degradation of performance. Modern TCP and QUIC implementations support features that significantly improve their tolerance to out- of-order delivery. This draft is intended to provide new information for layer 2 technology standards regarding the need to assure in- order delivery to support IETF protocols. | |||||||||||||
| draft-ietf-intarea-rfc8335bis-06.txt | ||||||||||||||
| PROBE: A Utility for Probing Interfaces | ||||||||||||||
|
This document specifies a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. | |||||||||||||
| draft-ietf-intarea-v4-via-v6-08.txt | ||||||||||||||
| IPv4 routes with an IPv6 next hop | ||||||||||||||
|
V4-via-v6 routing is a technique that uses IPv6 next-hop addresses for routing IPv4 packets, and thus makes it possible to route IPv4 packets across a network where some routers have not been assigned IPv4 addresses. This document describes v4-via-v6 routing, and defines related operational procedures, notably the origination of ICMPv4 packets by nodes that might not have an IPv4 address. | |||||||||||||
| draft-ietf-iotops-7228bis-10.txt | ||||||||||||||
| Terminology for Constrained-Node Networks | ||||||||||||||
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. | |||||||||||||
| draft-ietf-iotops-iot-dns-guidelines-04.txt | ||||||||||||||
| IoT DNS Security and Privacy Guidelines | ||||||||||||||
|
This document outlines guidance for Internet of Things (IoT) manufacturers regarding the implementation of DNS stub resolver software on devices, and for the management zones used for purposes such as device configuration and software upgrades. It aims to mitigate security threats, enhance privacy, and to address operational security challenges. DNS resolution between devices and management zone servers depends upon DNS services within operator networks, and these services and operator networks can be impacted by device behavior. Hence this document also provides guidance to network operators that deploy IoT devices to mitigate the specific risks identified in this document and take advantage of improved DNS security mechanisms provided by manufacturers. | |||||||||||||
| draft-ietf-iotops-mud-acceptable-urls-02.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-ietf-iotops-mud-rats-03.txt | ||||||||||||||
| MUD-Based RATS Resources Discovery | ||||||||||||||
|
Manufacturer Usage Description (MUD) files and the MUD URIs that point to them are defined in RFC 8520. This document introduces a new type of MUD file to be delivered in conjunction with a MUD file signature and/or to be referenced via a MUD URI embedded in other documents or messages, such as an IEEE 802.1AR Secure Device Identifier (DevID) or a CBOR Web Token (CWT). These signed documents can be presented to other entities, e.g., a network management system or network path orchestrator. If this entity also takes on the role of a verifier as defined by the IETF Remote ATtestation procedureS (RATS) architecture, this verifier can use the references included in the MUD file specified in this document to discover, for example, appropriate reference value providers, endorsement documents or endorsement distribution APIs, trust anchor stores, remote verifier services (sometimes referred to as Attestation Verification Services), or transparency logs. All theses references in the MUD file pointing to resources and auxiliary RATS services can satisfy general RATS prerequisite by enabling discovery or improve discovery resilience of corresponding resources or services. | |||||||||||||
| draft-ietf-iotops-ol-03.txt | ||||||||||||||
| Ownership and licensing statements in YANG | ||||||||||||||
|
This memo provides for an extension to RFC 8520 (Manufacturer Usage Description Specification, MUD) that allows MUD file authors to specify ownership and licensing of MUD files themselves. This memo updates RFC 8520. However, it can also be used for purposes outside of MUD, and the grouping is structured as such. | |||||||||||||
| draft-ietf-ippm-alt-mark-deployment-09.txt | ||||||||||||||
| Alternate Marking Deployment Framework | ||||||||||||||
|
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. | |||||||||||||
| draft-ietf-ippm-alt-mark-yang-06.txt | ||||||||||||||
| A YANG Data Model for the Alternate-Marking Method | ||||||||||||||
|
Alternate-Marking Method is a technique used to perform packet loss, delay, and jitter measurements on in-flight packets. This document defines a YANG data model for the Alternate-Marking Method. | |||||||||||||
| draft-ietf-ippm-asymmetrical-pkts-14.txt | ||||||||||||||
| Performance Measurement with Asymmetrical Traffic Using Simple Two-Way Active Measurement Protocol (STAMP) | ||||||||||||||
|
This document defines an optional extension to the Simple Two-Way Active Measurement Protocol (STAMP) that enables a Session-Reflector to send asymmetrical packets, that is, response packets whose size or quantity differs from those sent by the Session-Sender. While standard STAMP exchanges are symmetrical, certain measurement scenarios benefit from reflected packets of different lengths or additional responses to better approximate application traffic conditions. The extension specifies the Reflected Test Packet Control TLV and associated procedures, analyzes challenges in active performance measurement (including in multicast environments), and describes STAMP behaviors to improve measurement efficiency and reduce network impact. | |||||||||||||
| draft-ietf-ippm-connectivity-monitoring-13.txt | ||||||||||||||
| An Experimental Connectivity Monitoring Metric for IPPM | ||||||||||||||
|
Within a Segment Routing (SR) domain, segment routed measurement packets can be sent along pre-determined paths. This enables new kinds of active measurements. Connectivity monitoring supervises the state and performance of a connection or a (sub)path from central monitoring systems. This document specifies an experimental Type-p connectivity monitoring metric to accomodate such operational needs. | |||||||||||||
| draft-ietf-ippm-encrypted-pdmv2-16.txt | ||||||||||||||
| IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option | ||||||||||||||
|
RFC 8250 defines an IPv6 Destination Option that carries Performance and Diagnostic Metrics (PDM) such as sequence numbers and timing information. While useful for measurement and troubleshooting, clear-text PDM data may expose operational characteristics of endpoints and networks. This document defines PDMv2, a revised version of PDM that introduces a registration-based security model. Instead of specifying cryptographic algorithms or inline key negotiation, PDMv2 relies on a prior registration process to authenticate entities, authorize participation, and establish shared secrets. These secrets are then used by endpoints and authorized analyzers to protect and interpret PDMv2 data according to local policy. This document specifies the PDMv2 semantics, header structure, and operational model. The selection of specific cryptographic algorithms and key derivation functions, and the definition of any cipher-negotiation mechanism, are outside the scope of this document. | |||||||||||||
| draft-ietf-ippm-hybrid-two-step-06.txt | ||||||||||||||
| Hybrid Two-Step Performance Measurement Method | ||||||||||||||
|
The development and advancements in network operation automation have brought new measurement methodology requirements. Among them is the ability to collect instant network operational state as the packet being processed by the networking elements along its path through the domain. That task can be solved using on-path telemetry, also called hybrid measurement. An on-path telemetry method allows the collection of essential information that reflects the operational state and network performance experienced by the packet. This document introduces a method complementary to on-path telemetry that causes the generation of network telemetry information. This method, referred to as Hybrid Two-Step (HTS), separates the act of measuring and/or calculating the performance metric from collecting and transporting network operational state. The HTS packet traverses the same set of nodes and links as the trigger packet, thus simplifying the correlation of informational elements originating on nodes traversed by the trigger packet. | |||||||||||||
| draft-ietf-ippm-ioam-data-integrity-20.txt | ||||||||||||||
| Integrity Protection of In Situ Operations,Administration,and Maintenance (IOAM) Data Fields | ||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) records operational (including telemetry) information in packets while they traverse a path in the network. RFC 9197 specifies data fields for IOAM (a.k.a IOAM-Data-Fields) and associated data types. This document specifies integrity protection of IOAM-Data-Fields for Intra-IOAM-Domain use cases. | |||||||||||||
| draft-ietf-ippm-ioam-integrity-yang-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-ippm-on-path-active-measurements-03.txt | ||||||||||||||
| On-Path Telemetry for Active Performance Measurements | ||||||||||||||
|
This document describes how to employ active test packets in combination with Hybrid Methods to perform On-path Active Performance Measurements. This procedure allows Hop-By-Hop measurements in addition to the Edge-To-Edge measurements. | |||||||||||||
| draft-ietf-ippm-on-path-telemetry-yang-06.txt | ||||||||||||||
| On-Path Telemetry YANG Data Model | ||||||||||||||
|
This document proposes a YANG data model for monitoring On-Path network performance information to be published in YANG notifications. The Alternate-Marking Method and In-situ Operations, Administration, and Maintenance (IOAM) are the On-Path hybrid measurement methods considered in this document. | |||||||||||||
| draft-ietf-ippm-qoo-11.txt | ||||||||||||||
| Quality of Outcome (QoO) | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-ippm-responsiveness-09.txt | ||||||||||||||
| Responsiveness under Working Conditions | ||||||||||||||
|
For many years, a lack of responsiveness, variously called lag, latency, or bufferbloat, has been recognized as an unfortunate, but common, symptom in today's networks. Even after a decade of work on standardizing technical solutions, it remains a common problem for the end users. Everyone "knows" that it is "normal" for a video conference to have problems when somebody else at home is watching a 4K movie or uploading photos from their phone. However, there is no technical reason for this to be the case. In fact, various queue management solutions have solved the problem. Our network connections continue to suffer from an unacceptable amount of delay, not for a lack of technical solutions, but rather a lack of awareness of the problem and deployment of its solutions. We believe that creating a tool that measures the problem and matches people's everyday experience will create the necessary awareness, and result in a demand for solutions. This document specifies the "Responsiveness Test" for measuring responsiveness. It uses common protocols and mechanisms to measure user experience specifically when the network is under working conditions. The measurement is expressed as "Round-trips Per Minute" (RPM) and should be included with goodput (up and down) and idle latency as critical indicators of network quality. | |||||||||||||
| draft-ietf-ippm-stamp-cos-ecn-01.txt | ||||||||||||||
| Update of the Simple Two-way Active Measurement Protocol Class-of-Service Extension - ECN | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) enables one- way and round-trip measurement of network metrics between IP hosts, and has a facility for defining optional extensions. This document updates the definition of the Class of Service TLV (originally defined in RFC 8972) to enable the measurement of manipulation of the value of the Explicit Congestion Notification (ECN) field of the IP header by middleboxes between two STAMP hosts, and to enable discovery and measurement of paths that provide differential treatment of packets depending on the value of their ECN field. | |||||||||||||
| draft-ietf-ippm-stamp-ext-hdr-13.txt | ||||||||||||||
| Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers | ||||||||||||||
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-by- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers as well as IPv6 extension headers for HBH and E2E active measurements, for example, using the IOAM data fields. This document specifies the requirements for IPv6 STAMP in unauthenticated mode using UDP zero-checksum, which deviates from the integrity requirement in RFC 6936. | |||||||||||||
| draft-ietf-ipsecme-child-pfs-info-00.txt | ||||||||||||||
| IKEv2 Support for Child SA PFS Policy Information | ||||||||||||||
|
This document defines an extension for the Internet Key Exchange Protocol Version 2 (IKEv2) to support negotiation at the time of initial Child Security Association (SA) establishing of Key Exchange (KE) method that could be used in subsequent rekeys of this SA. | |||||||||||||
| draft-ietf-ipsecme-diet-esp-11.txt | ||||||||||||||
| ESP Header Compression with Diet-ESP | ||||||||||||||
|
This document specifies Diet-ESP, a compression mechanism for control information in IPsec/ESP communications. The compression uses Static Context Header Compression rules. | |||||||||||||
| draft-ietf-ipsecme-eesp-04.txt | ||||||||||||||
| Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This document describes the Enhanced Encapsulating Security Payload (EESP) protocol, which builds on the existing IP Encapsulating Security Payload (ESP) protocol. It is designed to modernize and overcome limitations in the ESP protocol. EESP adds Session IDs (e.g., to support CPU pinning and QoS support based on the inner traffic flow), changes some previously mandatory fields to optional, and moves the ESP trailer into the EESP header. Additionally, EESP adds header options adapted from IPv6 to allow for future extension. New header options are defined which add a crypt- offset to allow for exposing inner flow information for middlebox use. | |||||||||||||
| draft-ietf-ipsecme-eesp-ikev2-03.txt | ||||||||||||||
| IKEv2 negotiation for Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This document specifies how to negotiate the use of the Enhanced Encapsulating Security Payload (EESP) protocol using the Internet Key Exchange protocol version 2 (IKEv2). The EESP protocol, which is defined in [I-D.ietf-ipsecme-eesp], provides the same security services as Encapsulating Security Payload (ESP), but has richer functionality and provides better performance in specific circumstances. This document specifies negotiation of version 0 of EESP. | |||||||||||||
| draft-ietf-ipsecme-encrypted-esp-ping-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-03.txt | ||||||||||||||
| Post-quantum Key Exchange in IKEv2 with FrodoKEM | ||||||||||||||
|
FrodoKEM is an unstructured lattice based Key Encapsulation Mechanism (KEM), standardized by ISO. Compared to ML-KEM, it is considered with more conservative security. This draft specifies how to use FrodoKEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options enable to negotiate IKE and Child SA keys that are safe against a Cryptographically Relevant Quantum Computer (CRQC). | |||||||||||||
| draft-ietf-ipsecme-ikev2-beet-mode-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-ipsecme-ikev2-diet-esp-extension-08.txt | ||||||||||||||
| Internet Key Exchange version 2 (IKEv2) extension for Header Compression Profile (HCP) | ||||||||||||||
|
This document describes an IKEv2 extension for Header Compression to agree on Attributes for Rule Derivation. This extension defines the necessary registries for the ESP Header Compression Profile (EHCP) Diet-ESP. | |||||||||||||
| draft-ietf-ipsecme-ikev2-downgrade-prevention-08.txt | ||||||||||||||
| Downgrade Prevention for the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document specifies an extension to the Internet Key Exchange protocol version 2 (IKEv2) in which the peers authenticate the full IKE_SA_INIT transcript. When both peers implement the extension and at least one relevant authentication credential is not compromised, this prevents certain downgrade attacks on IKEv2. This document updates RFC 7296. | |||||||||||||
| draft-ietf-ipsecme-ikev2-mlkem-09.txt | ||||||||||||||
| Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
US NIST standardized ML-KEM, a new key encapsulation mechanism, which can be used for quantum-resistant key establishment. This document specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options allow for negotiating IKE and Child SA keys which are resistant against cryptographically relevant quantum computers. | |||||||||||||
| draft-ietf-ipsecme-ikev2-pqc-auth-12.txt | ||||||||||||||
| Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC | ||||||||||||||
|
Signature-based authentication methods are utilized in the Internet Key Exchange Version 2 (IKEv2). The current version of the IKEv2 protocol, specified in RFC 7296, supports traditional digital signatures. This document specifies a generic mechanism for integrating post- quantum cryptographic (PQC) digital signature algorithms into the IKEv2 protocol. The approach allows for seamless inclusion of any PQC signature scheme within the existing authentication framework of IKEv2. Additionally, it outlines how Module-Lattice-Based Digital Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- DSA), can be employed as authentication methods within the IKEv2 protocol, as they have been standardized by US NIST. | |||||||||||||
| draft-ietf-ipsecme-ikev2-prf-plus-02.txt | ||||||||||||||
| Use of Variable-Length Output Pseudo-Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document specifies the use of variable-length output Pseudo- Random Functions (PRFs) in the Internet Key Exchange Protocol Version 2 (IKEv2). Current IKEv2 specification relies on traditional PRFs with fixed output length for key derivation and uses iterative application of a PRF (called "prf+") in cases when longer output is required. Appearance of PRFs that can output as much bits as requested allows to streamline the key derivation functions of IKEv2. This document updates RFC 7296 and RFC 7815 for the cases when variable-length output Pseudo-Random Functions are used in IKEv2 and its extensions. | |||||||||||||
| draft-ietf-ipsecme-ikev2-reliable-transport-07.txt | ||||||||||||||
| Separate Transports for IKE and ESP | ||||||||||||||
|
The Internet Key Exchange protocol version 2 (IKEv2) can operate either over unreliable (UDP) transport or over reliable (TCP) transport. If TCP is used, then IPsec tunnels created by IKEv2 also use TCP. This document specifies how to decouple IKEv2 and IPsec transports so that IKEv2 can operate over TCP, while IPsec tunnels use unreliable transport. This feature allows IKEv2 to effectively exchange large blobs of data (e.g., when post-quantum algorithms are employed) while avoiding performance problems that arise when IPsec uses TCP. | |||||||||||||
| draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-08.txt | ||||||||||||||
| Optimized Rekeys in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document describes a method for reducing the size of the Internet Key Exchange version 2 (IKEv2) CREATE_CHILD_SA exchanges used for rekeying of the IKE or Child SA by replacing the SA and TS payloads with a Notify Message payload. Reducing size and complexity of IKEv2 exchanges is especially useful for low power consumption battery powered devices. | |||||||||||||
| draft-ietf-ipsecme-sha3-02.txt | ||||||||||||||
| Use of KMAC and SHAKE in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec | ||||||||||||||
|
This document specifies the use of KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256 are also specified. | |||||||||||||
| draft-ietf-ivy-entitlement-inventory-04.txt | ||||||||||||||
| A YANG Module for Entitlement Inventory | ||||||||||||||
|
This document defines a YANG data model for managing software-based entitlements (licenses, authorization tokens, pay-as-you-go service credentials…) within a network inventory. The model represents the relationship between organizational entitlements, network element capabilities, and the constraints that entitlements impose on capability usage. This data model enables operators to determine what capabilities their network elements possess, which capabilities are currently entitled for use, and what restrictions apply. The model supports both centralized entitlement management and device-local entitlement tracking for physical and virtual network elements. | |||||||||||||
| draft-ietf-ivy-network-inventory-location-06.txt | ||||||||||||||
| A YANG Data Model for Network Inventory Location | ||||||||||||||
|
This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. | |||||||||||||
| draft-ietf-ivy-network-inventory-software-04.txt | ||||||||||||||
| A YANG Network Data Model of Network Inventory Software Extensions | ||||||||||||||
|
This document extends the base Network Inventory YANG model to support non-physical network elements (NEs), such as controllers, virtual routers, and virtual firewalls, as well as software components like platform operating systems and software modules. In addition to the software revisions and patches already defined in the base model, this extension introduces software status and time stamp information. | |||||||||||||
| draft-ietf-ivy-network-inventory-topology-11.txt | ||||||||||||||
| A YANG Network Data Model for Inventory Topology Mapping | ||||||||||||||
|
This document specifies a YANG data model that extends the network topology data model (RFC 8345) to map network topologies with inventories. The data model introduces the "inventory-topology" network type and augmentations for physical entity mappings and capabilities, which may be used by any overlay network topology for service provisioning validation, network maintenance, and capacity planning. | |||||||||||||
| draft-ietf-ivy-network-inventory-yang-19.txt | ||||||||||||||
| A Base YANG Data Model for Network Inventory | ||||||||||||||
|
This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. | |||||||||||||
| draft-ietf-ivy-passive-network-inventory-01.txt | ||||||||||||||
| A YANG Data Model for Passive Network Inventory | ||||||||||||||
|
This document presents a YANG data model for tracking and managing passive network inventory. The model augments the base network inventory model. | |||||||||||||
| draft-ietf-jmap-blobext-01.txt | ||||||||||||||
| JMAP Blob Management | ||||||||||||||
|
The JSON Meta Application Protocol (JMAP) base protocol ([JMAP-CORE]) provides the ability to upload and download arbitrary binary data via HTTP POST and GET on a defined endpoint. This binary data is called a "blob". This extension adds additional ways to create and access blobs by making inline method calls within a standard JMAP request. It also adds a reverse lookup mechanism to discover where blobs are referenced within other data types, support for large blobs via chunked construction with server-side optimisation, and server-side blob conversion operations including image format conversion, archive creation and extraction, compression and decompression, and delta/ patch operations. | |||||||||||||
| draft-ietf-jmap-calendars-29.txt | ||||||||||||||
| JSON Meta Application Protocol (JMAP) for Calendars | ||||||||||||||
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. | |||||||||||||
| draft-ietf-jmap-conditional-00.txt | ||||||||||||||
| JMAP Conditional Set | ||||||||||||||
|
The JMAP base protocol ([JMAP-CORE]) provides the Foo/set method for creating, updating, and destroying objects. It offers a single concurrency control, the "ifInState" argument, which guards an entire object type: if any object of that type has changed, the whole method is rejected. This extension adds a finer, per-object conditional mechanism. A client may require that an individual update or destroy proceed only if the target object still matches a set of expected property values, expressed using the JMAP PatchObject already defined for updates. This provides optimistic concurrency control scoped to a single object — the equivalent of an HTTP "If-Match" precondition — for any JMAP data type. This extension also defines an optional "atomic" argument that applies an entire Foo/set as a single unit: either every change it requests takes effect, or none does. Combined with the per-object precondition, this lets a client express a multi-object change that is safe only when applied together — such as an atomic rename that exchanges two names. | |||||||||||||
| draft-ietf-jmap-emailpush-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-jmap-filenode-14.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-jmap-mail-sharing-02.txt | ||||||||||||||
| JMAP Mail Sharing | ||||||||||||||
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) for Mail to enable sharing of mailboxes between users. Building upon the JMAP Sharing framework defined in [RFC9670], this specification extends the Mailbox data type defined in [RFC8621] with properties necessary to configure and manage access permissions for shared mailboxes. The extension introduces a new capability that indicates server support for mailbox sharing and defines the additional properties required to share mailboxes with other principals, including the ability to control which users may access a mailbox and what permissions they possess. | |||||||||||||
| draft-ietf-jmap-metadata-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-jmap-object-history-00.txt | ||||||||||||||
| JMAP Object History | ||||||||||||||
|
The JMAP base protocol (RFC8620) provides methods for synchronizing the current state of data objects between client and server. This extension adds the ability to retrieve historical versions of objects, including objects that have been destroyed, by extending the standard Foo/get method. | |||||||||||||
| draft-ietf-jmap-refplus-02.txt | ||||||||||||||
| JMAP Enhanced Result References | ||||||||||||||
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that enhances the result reference mechanism defined in [RFC8620]. The extension allows result references to be used in additional contexts beyond method call arguments, specifically within object properties during JMAP /set operations and within FilterCondition objects used in /query operations. Additionally, this specification extends result references to support JSON Path expressions ([RFC9535]) as an alternative to JSON Pointer ([RFC6901]), providing more expressive query capabilities for extracting values from previous method call results. These enhancements enable more efficient data reuse patterns across JMAP method calls, reducing the need for multiple round trips between client and server. | |||||||||||||
| draft-ietf-jose-deprecate-none-rsa15-05.txt | ||||||||||||||
| JOSE: Deprecate 'none' and 'RSA1_5' | ||||||||||||||
|
This document updates [RFC7518] to deprecate the JWS algorithm "none" and the JWE algorithm "RSA1_5". These algorithms have known security weaknesses. It also updates the Review Instructions for Designated Experts to establish baseline security requirements that future algorithm registrations are expected to meet. | |||||||||||||
| draft-ietf-jose-hpke-encrypt-22.txt | ||||||||||||||
| Use of Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE) | ||||||||||||||
|
This specification defines how to use Hybrid Public Key Encryption (HPKE) with JSON Web Encryption (JWE). HPKE enables public key encryption of arbitrary-sized plaintexts to a recipient's public key, and provides security against adaptive chosen ciphertext attacks. This specification chooses a specific subset of the HPKE features to use with JWE. This specification updates RFC 7516 (JWE) to enable use of Integrated Encryption as a Key Management Mode. | |||||||||||||
| draft-ietf-jose-hpke-pq-pqt-01.txt | ||||||||||||||
| JOSE HPKE PQ & PQ/T Algorithm Registrations | ||||||||||||||
|
This document registers Post-Quantum (PQ) and Post-Quantum/ Traditional (PQ/T) hybrid algorithm identifiers for use with JSON Object Signing and Encryption (JOSE), building on the Hybrid Public Key Encryption (HPKE) framework. | |||||||||||||
| draft-ietf-jose-json-proof-algorithms-14.txt | ||||||||||||||
| JSON Proof Algorithms | ||||||||||||||
|
The JSON Proof Algorithms (JPA) specification registers cryptographic algorithms and identifiers to be used with the JSON Web Proof, JSON Web Key (JWK), and COSE specifications. It defines IANA registries for these identifiers. | |||||||||||||
| draft-ietf-jose-json-proof-token-14.txt | ||||||||||||||
| JSON Proof Token and CBOR Proof Token | ||||||||||||||
|
JSON Proof Token (JPT) is a compact, URL-safe, privacy-preserving representation of claims to be transferred between three parties. The claims in a JPT are encoded as base64url-encoded JSON objects that are used as the payloads of a JSON Web Proof (JWP) structure, enabling them to be digitally signed and selectively disclosed. JPTs also support reusability and unlinkability when using Zero-Knowledge Proofs (ZKPs). A CBOR-based representation of JPTs is also defined, called a CBOR Proof Token (CPT). It has the same properties as JPTs, but uses the JSON Web Proof (JWP) CBOR Serialization, rather than the JSON-based JWP Compact Serialization. | |||||||||||||
| draft-ietf-jose-json-web-proof-14.txt | ||||||||||||||
| JSON Web Proof | ||||||||||||||
|
The JOSE set of standards established JSON-based container formats for Keys, Signatures, and Encryption. They also established IANA registries to enable the algorithms and representations used for them to be extended. Since those were created, newer cryptographic algorithms that support selective disclosure and unlinkability have matured and started seeing early market adoption. The COSE set of standards likewise does this for CBOR-based containers, focusing on the needs of environments which are better served using CBOR, such as constrained devices and networks. This document defines a new container format similar in purpose and design to JSON Web Signature (JWS) and COSE Signed Messages called a _JSON Web Proof (JWP)_. Unlike JWS, which integrity-protects only a single payload, JWP can integrity-protect multiple payloads in one message. It also specifies a new presentation form that supports selective disclosure of individual payloads, enables additional proof computation, and adds a Presentation Header to prevent replay. | |||||||||||||
| draft-ietf-jose-pq-composite-sigs-04.txt | ||||||||||||||
| PQ/T Hybrid Composite Signatures for JOSE and COSE | ||||||||||||||
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. | |||||||||||||
| draft-ietf-jose-pqc-kem-06.txt | ||||||||||||||
| Post-Quantum Key Encapsulation Mechanisms (PQ KEMs) for COSE | ||||||||||||||
|
This document describes conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and Encryption (COSE). | |||||||||||||
| draft-ietf-jsonschema-json-schema-03.txt | ||||||||||||||
| JSON Schema | ||||||||||||||
|
JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. A JSON Schema may assert constraints on a JSON value, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents. | |||||||||||||
| draft-ietf-keytrans-architecture-09.txt | ||||||||||||||
| Key Transparency Architecture | ||||||||||||||
|
This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. | |||||||||||||
| draft-ietf-keytrans-protocol-05.txt | ||||||||||||||
| Key Transparency Protocol | ||||||||||||||
|
While there are several established protocols for end-to-end encryption, relatively little attention has been given to securely distributing the end-user public keys for such encryption. As a result, these protocols are often still vulnerable to eavesdropping by active attackers. Key Transparency is a protocol for distributing sensitive cryptographic information, such as public keys, in a way that reliably either prevents interference or detects that it occurred in a timely manner. | |||||||||||||
| draft-ietf-kitten-password-storage-13.txt | ||||||||||||||
| Best practices for SASL password hashing and storage | ||||||||||||||
|
This document outlines best practices for handling user passwords and other secrets in client-server systems making use of SASL. | |||||||||||||
| draft-ietf-kitten-sasl-ht-02.txt | ||||||||||||||
| The Hashed Token SASL Mechanism | ||||||||||||||
|
This document specifies the family of Hashed Token SASL mechanisms, which enable a proof-of-possession-based authentication scheme and are meant to quickly re-authenticate a previous session. The Hashed Token SASL mechanism's authentication sequence consists of only one round-trip. The usage of short-lived, exclusively ephemeral hashed tokens is achieving the single round-trip property. The SASL mechanism specified herein further provides hash agility, mutual authentication, support for channel binding, and the capability to exchange authenticated key/value pairs. | |||||||||||||
| draft-ietf-kitten-scram-2fa-06.txt | ||||||||||||||
| Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication | ||||||||||||||
|
This specification describes an extension to family of Simple Authentication and Security Layer (SASL; RFC 4422) authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides support for 2 factor authentication. It also includes a separate extension for quick reauthentication. This specification also gives 2 examples of second factors: TOTP (RFC 6238) and FIDO CTAP1/U2F (Passkey). | |||||||||||||
| draft-ietf-lake-app-profiles-05.txt | ||||||||||||||
| Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, in order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. | |||||||||||||
| draft-ietf-lake-authkem-edhoc-00.txt | ||||||||||||||
| KEM-based Authentication for EDHOC | ||||||||||||||
|
This document specifies extensions to the Ephemeral Diffie-Hellman Over COSE (EDHOC) protocol to provide resistance against quantum computer adversaries by incorporating Post-Quantum Cryptography (PQC) Key Encapsulation Mechanisms (KEMs) for both key exchange and authentication. It defines a new signature-free KEM-based authentication method in which both parties authenticate using KEMs, enabling quantum-resistant authentication without relying on digital signatures when PQC KEMs, such as the NIST-standardized ML-KEM, are used. | |||||||||||||
| draft-ietf-lake-authz-08.txt | ||||||||||||||
| Lightweight Authorization using Ephemeral Diffie-Hellman Over COSE (ELA) | ||||||||||||||
|
Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. | |||||||||||||
| draft-ietf-lake-edhoc-grease-03.txt | ||||||||||||||
| Applying Generate Random Extensions And Sustain Extensibility (GREASE) to EDHOC Extensibility | ||||||||||||||
|
This document applies the extensibility mechanism GREASE (Generate Random Extensions And Sustain Extensibility), which was pioneered for TLS, to the ecosystem of Ephemeral Diffie-Hellman Over COSE (EDHOC). It reserves a set of External Authorization Data (EAD) labels and unusable cipher suites that may be included in messages to ensure peers correctly handle unknown values. | |||||||||||||
| draft-ietf-lake-edhoc-impl-cons-07.txt | ||||||||||||||
| Implementation Considerations for Ephemeral Diffie-Hellman Over COSE (EDHOC) | ||||||||||||||
|
This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). | |||||||||||||
| draft-ietf-lake-edhoc-psk-09.txt | ||||||||||||||
| EDHOC Authenticated with Pre-Shared Keys (PSK) | ||||||||||||||
|
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) Lightweight Authenticated Key Exchange (LAKE) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection, and quantum resistance while incurring lower computational costs than the public-key authentication methods specified for EDHOC. It is suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK message flow, key derivation changes, message formatting, processing, and security considerations. | |||||||||||||
| draft-ietf-lake-pqsuites-00.txt | ||||||||||||||
| Quantum-Resistant Cipher Suites for LAKE | ||||||||||||||
|
The Lightweight Authenticated Key Exchange (LAKE) protocol, also known as Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post- quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document specifies how the LAKE protocol operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. | |||||||||||||
| draft-ietf-lake-ra-06.txt | ||||||||||||||
| Remote attestation over EDHOC | ||||||||||||||
|
This document specifies how to perform remote attestation as part of the lightweight authenticated Diffie-Hellman key exchange protocol EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote ATtestation procedureS (RATS) architecture. | |||||||||||||
| draft-ietf-lamps-attestation-freshness-08.txt | ||||||||||||||
| Requesting a Freshness Nonce for Attestation Evidence in Certificate Signing Requests | ||||||||||||||
|
When an end entity includes attestation statements in a Certificate Signing Request (CSR), the freshness of the conveyed Evidence often needs to be established. A common mechanism is a nonce that is obtained from a Relying Party or Verifier and included by the Attester in the Evidence. This document specifies how an end entity requests such an attestation freshness nonce from an RA/CA when using certificate lifecycle management protocols. It defines message formats and protocol bindings for the conveyance of nonce request and response messages in the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC), including optional type-specific information needed to produce fresh Evidence for inclusion in a CSR. | |||||||||||||
| draft-ietf-lamps-certdiscovery-03.txt | ||||||||||||||
| A Mechanism for X.509 Certificate Discovery | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-lamps-cms-composite-kem-01.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-ietf-lamps-cms-composite-sigs-05.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-ietf-lamps-cms-euf-cma-signeddata-03.txt | ||||||||||||||
| Best Practices for Signed Attributes in CMS SignedData | ||||||||||||||
|
The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists mitigations and best practices to avoid it. This document updates RFC 5652 by prohibiting the use of the id-data content type for new uses of the CMS SignedData type. | |||||||||||||
| draft-ietf-lamps-cms-fn-dsa-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-lamps-csr-attestation-29.txt | ||||||||||||||
| Use of Remote Attestation with Certification Signing Requests | ||||||||||||||
|
Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. | |||||||||||||
| draft-ietf-lamps-fn-dsa-certificates-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-lamps-one-signature-certs-02.txt | ||||||||||||||
| One Signature Certificates | ||||||||||||||
|
This document defines the signedDocumentBinding certificate extension, which binds a certificate to the signed content of a digital signature produced by a single signing operation. Each certificate is created at the time of signing and the associated signing key is generated, used to produce a single digital signature, and then immediately destroyed. Certificates carrying this extension are intended to be issued without a revocation mechanism and with no expiration, which simplifies long-term validation. | |||||||||||||
| draft-ietf-lamps-pq-composite-kem-21.txt | ||||||||||||||
| Composite ML-KEM for use in X.509 Public Key Infrastructure | ||||||||||||||
|
This document defines combinations of US NIST ML-KEM in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. | |||||||||||||
| draft-ietf-lamps-pq-composite-sigs-19.txt | ||||||||||||||
| Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure | ||||||||||||||
|
This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. | |||||||||||||
| draft-ietf-lamps-rfc6211-update-03.txt | ||||||||||||||
| Update to the Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute | ||||||||||||||
|
This document updates RFC 6211. It corrects errors in the definition of the id-aa-CMSAlgorithmProtect ASN.1 object identifier. The IANA registry entry has always been correct. | |||||||||||||
| draft-ietf-lamps-rfc8550bis-00.txt | ||||||||||||||
| Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling | ||||||||||||||
|
This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/ MIME agents validate certificates as described in RFC 5280 ("Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"). S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. | |||||||||||||
| draft-ietf-lamps-rfc8551bis-00.txt | ||||||||||||||
| Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification | ||||||||||||||
|
This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. | |||||||||||||
| draft-ietf-lisp-ecdsa-auth-17.txt | ||||||||||||||
| LISP Control-Plane ECDSA Authentication and Authorization | ||||||||||||||
|
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required. | |||||||||||||
| draft-ietf-lisp-eid-mobility-18.txt | ||||||||||||||
| LISP L2/L3 EID Mobility Using a Unified Control Plane | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-lisp-group-mapping-04.txt | ||||||||||||||
| LISP Multicast Overlay Group to Underlay RLOC Mappings | ||||||||||||||
|
This draft augments LISP [RFC9300] multicast functionality described in [I-D.farinacci-lisp-rfc6831bis] and [I-D.farinacci-lisp-rfc8378bis] to support the mapping of overlay group addresses to underlay RLOC addresses. This draft defines a many-to-1, 1-to-many, and many-to-many relationship between multicast EIDs and the Replication List Entries (RLEs) RLOC records they map to. The mechanisms in this draft allow a multicast LISP overlay to run over a mixed underlay of unicast and/or multicast packet forwarding functionality. | |||||||||||||
| draft-ietf-lisp-map-server-reliable-transport-08.txt | ||||||||||||||
| LISP Map Server Reliable Transport | ||||||||||||||
|
The communication between LISP ETRs and Map-Servers is based on unreliable UDP message exchange coupled with periodic message transmission in order to maintain soft state. The drawback of periodic messaging is the constant load imposed on both the ETR and the Map-Server. New LISP use cases increase the amount of state that needs to be communicated and challenge the scalability of the system when using the UDP exchange. This document introduces the use of a reliable transport for ETR to Map-Server communications in order to eliminate the periodic messaging overhead, while providing reliability, flow-control and endpoint liveness detection. | |||||||||||||
| draft-ietf-lisp-multicast-deploy-00.txt | ||||||||||||||
| LISP Multicast Deployment Experience | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-lisp-nat-traversal-02.txt | ||||||||||||||
| NAT traversal for LISP | ||||||||||||||
|
This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a Network Address Translator (NAT) device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT. | |||||||||||||
| draft-ietf-lisp-rfc6831bis-08.txt | ||||||||||||||
| The Locator/ID Separation Protocol (LISP) for Multicast Environments | ||||||||||||||
|
This document specifies the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. This document when approved obsoletes RFC6831 | |||||||||||||
| draft-ietf-lisp-rfc8060bis-05.txt | ||||||||||||||
| LISP Canonical Address Format (LCAF) | ||||||||||||||
|
This document defines a canonical address format encoding used in Locator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. This document obsoletes RFC 8060 and RFC 9306. | |||||||||||||
| draft-ietf-lisp-rfc8378bis-09.txt | ||||||||||||||
| Signal-Free Locator/ID Separation Protocol (LISP) Multicast | ||||||||||||||
|
This document describes the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP). The document specifies how LISP multicast overlays operate over a unicast underlay. When multicast sources and receivers are active at Locator/ID Separation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism within here uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. This document when approved obsoletes RFC 8378. | |||||||||||||
| draft-ietf-lisp-site-external-connectivity-04.txt | ||||||||||||||
| LISP Site External Connectivity | ||||||||||||||
|
This draft defines how to register/retrieve pETR mapping information in LISP when the destination is not registered/known to the local site and its mapping system (e.g. the destination is an internet/ external site destination or scale-out end point in backend data center networks of AI Infrastructure). | |||||||||||||
| draft-ietf-lisp-te-25.txt | ||||||||||||||
| LISP Traffic Engineering | ||||||||||||||
|
This document describes how Locator/Identifier Separation Protocol (LISP) re-encapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes and specify how existing Routing Locator encodings are used to construct Explicit Locator Paths for traffic engineering purposes. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or a combination of both. | |||||||||||||
| draft-ietf-lisp-vpn-14.txt | ||||||||||||||
| LISP Virtual Private Networks (VPNs) | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-lisp-yang-25.txt | ||||||||||||||
| LISP YANG Model | ||||||||||||||
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). This model can be used to configure and monitor the different control plane and data plane elements that enable a LISP network. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. | |||||||||||||
| draft-ietf-lsr-distoptflood-14.txt | ||||||||||||||
| IS-IS Distributed Flooding Reduction | ||||||||||||||
|
In dense topologies (such as data center fabrics based on the Clos and butterfly though not limited to those; in fact any large topology or one with relatively high degree of connectivity qualifies here) IGP flooding mechanisms designed originally for rather sparse topologies can "overflood", or in other words generate too many identical copies of same information arriving at a given node from other devices. This normally results in longer convergence times and higher resource utilization to process and discard the superfluous copies. Flooding algorithm extensions that restrict the amount of flooding performed can be constructed and can reduce resource utilization significantly, while improving convergence performance. One such flooding modification (based on previous art) optimized for operational considerations, described further in Section 2, is described in this document. | |||||||||||||
| draft-ietf-lsr-dynamic-flooding-algorithm-05.txt | ||||||||||||||
| An Algorithm for Computing Dynamic Flooding Topologies | ||||||||||||||
|
Link-state routing protocols suffer from excessive flooding in dense network topologies. Dynamic flooding alleviates the problem by decoupling the flooding topology from the base topology. Link-state protocol updates are flooded only on the sparse flooding topology while data traffic is still forwarded on the base topology. This document describes an algorithm to obtain a sparse subgraph from a dense graph. The resulting subgraph has certain desirable properties and can be used by a centralized Area Leader to compute a flooding topology for dynamic flooding. This document discloses the algorithm that the authors have developed in order to make it easier for other developers to implement similar algorithms. The authors do not claim that our algorithm is optimal, rather, it is a pragmatic effort and the authors expect that further research and refinement can improve the results. The authors are not currently proposing that this algorithm be standardized, nor that the working group use this as a basis for further standardization work; however, the authors have no objections if the working group chooses to do so. This document is published as an Experimental RFC to gain operational and implementation experience with the specified dynamic flooding algorithm. The intent is to assess the suitability of this algorithm for advancement to the Standards Track as a Proposed Standard, pending sufficient deployment experience and feedback from the community. | |||||||||||||
| draft-ietf-lsr-flex-algo-link-loss-00.txt | ||||||||||||||
| IGP Flexible Algorithm with Link Packet Loss | ||||||||||||||
|
This document proposes extensions to the IGP Flexible Algorithm. It introduces a mechanism to exclude links exceeding a specified packet loss rate threshold during path computation. The solution leverages existing link packet loss advertisement via IS-IS and OSPF, and defines new constraints for Flex-Algorithm path calculation. | |||||||||||||
| draft-ietf-lsr-flex-soft-dataplane-01.txt | ||||||||||||||
| IGP Flex Soft Dataplane | ||||||||||||||
|
Advertisement of IGP Flex-Algo participation requires a dataplane context. This document defines a "soft dataplane" usable in cases where existing defined dataplanes are not suitable. | |||||||||||||
| draft-ietf-lsr-flood-reduction-arch-03.txt | ||||||||||||||
| IGP Flooding Reduction Algorithm Framework | ||||||||||||||
|
This document introduces a framework making it possible to deploy multiple flood reduction algorithms within the same IGP domain in an interoperable fashion. | |||||||||||||
| draft-ietf-lsr-igp-reverse-spf-algo-03.txt | ||||||||||||||
| IGP Reverse SPF Algorithm | ||||||||||||||
|
IANA has set up a subregistry called "IGP Algorithm Type" under the "Interior Gateway Protocol (IGP) Parameters" registry. This draft introduces a new algorithm type which utilizes the cost in the reverse direction on each link. This document also discusses using this new algorithm type in combination with IGP Flexible Algorithm to compute constraint-based paths. | |||||||||||||
| draft-ietf-lsr-isis-flex-algo-yang-21.txt | ||||||||||||||
| A YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support IS-IS Application- Specific Link Attributes and Flexible Algorithm. | |||||||||||||
| draft-ietf-lsr-isis-pics-l2member-attr-yang-03.txt | ||||||||||||||
| YANG Data Model for IS-IS L2 Bundle Member Link Attributes PICS | ||||||||||||||
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of advertising Layer 2 Bundle Member Link Attributes. | |||||||||||||
| draft-ietf-lsr-isis-pics-srmpls-yang-03.txt | ||||||||||||||
| YANG Data Model for IS-IS Segment Routing MPLS PICS | ||||||||||||||
|
The YANG model in this document is to query an IS-IS Protocol Implementation Conformance Statement (PICS) of Segment Routing on MPLS data plane. | |||||||||||||
| draft-ietf-lsr-isis-pics-yang-03.txt | ||||||||||||||
| YANG Model for IS-IS Protocol Implementation Conformance Statement (PICS) | ||||||||||||||
|
The YANG model in this document is to be used to query an IS-IS Protocol Implementation Conformance Statement (PICS). | |||||||||||||
| draft-ietf-lsr-isis-sr-vtn-mt-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-lsr-isis-srv6-yang-10.txt | ||||||||||||||
| YANG Data Model for IS-IS SRv6 | ||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing over the IPv6 Data Plane. | |||||||||||||
| draft-ietf-lsr-isis-yang-augmentation-v1-12.txt | ||||||||||||||
| IS-IS YANG Model Augmentations for Additional Features - Release 1 | ||||||||||||||
|
This document defines YANG data modules augmenting the IETF IS-IS YANG model to provide support for IS-IS Minimum Remaining Lifetime as defined in RFC 7987, and Signaling Maximum SID Depth Using IS-IS as defined in RFC 8491. | |||||||||||||
| draft-ietf-lsr-l2-bundle-member-remote-id-06.txt | ||||||||||||||
| Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members | ||||||||||||||
|
In networks where Layer 2 (L2) interface bundles (such as a Link Aggregation Group (LAG) as defined in IEEE 802.1AX) are deployed, a controller may need to collect the connectivity relationships between bundle members for traffic engineering (TE) purposes. For example, when performing topology management and bidirectional path computation for TE, it is essential to know the connectivity relationships among bundle members. This document describes how OSPF and IS-IS would advertise the remote interface identifiers for Layer 2 bundle members. The corresponding extension of BGP Link State (BGP-LS) is also specified. | |||||||||||||
| draft-ietf-lsr-ospf-flex-algo-yang-16.txt | ||||||||||||||
| A YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm | ||||||||||||||
|
This document defines a YANG data model to support OSPF Application- Specific Link Attributes and Flexible Algorithm. It also creates the initial version of IANA-maintained YANG modules for IGP Algorithm Types, IGP Metric-Types, and IGP Link Attribute Applications. This document updates RFCs 8665, 9350, and 9843. | |||||||||||||
| draft-ietf-lsr-ospf-ls-link-infinity-25.txt | ||||||||||||||
| Advertising Unreachable Links in OSPF | ||||||||||||||
|
OSPF Router Link State Advertisements (LSAs) use fixed-format encodings that always include advertised links in the default SPF (Shortest Path First) computation. For non-default SPF computations, e.g., flexible algorithms as described in RFC 9350, advertised OSPF links are used in the default SPF computation even if this is not intended. In order to advertise these links and not use them in the base SPF calculation, the metric LSLinkInfinity (0xffff) is used to specify that the link is unreachable. If all OSPF routers in an OSPF area support this functionality and have advertised the capability via an area-scoped OSPF Router-Information LSA, then links advertised with a metric of LSLinkInfinity are considered unreachable. MaxReachableLinkMetric (0xfffe) is defined to provide backward compatible reachability in specifications that previously specified advertisement of MaxLinkMetric (0xffff). This document updates RFC 5443, RFC 6987, RFC 8379, and RFC 8770 with respect to the advertisement of MaxReachableLinkMetric (0xfffe) rather than MaxLinkMetric (0xffff). | |||||||||||||
| draft-ietf-lsr-ospf-srv6-yang-10.txt | ||||||||||||||
| YANG Data Model for OSPF SRv6 | ||||||||||||||
|
This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. | |||||||||||||
| draft-ietf-lsr-ospf-transport-instance-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-lsr-ospf-yang-augmentation-v1-19.txt | ||||||||||||||
| OSPF YANG Model Augmentations for Additional Features - Release 1 | ||||||||||||||
|
This document defines YANG data modules that augment the IETF OSPF YANG model to support various OSPF extensions and features, including Traffic Engineering Extensions to OSPF Version 3 as defined in RFC 5329, OSPF Two-Part Metric as defined in RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379, OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement as defined in RFC 8510, OSPF MSD as defined in RFC 8476, OSPF Application-Specific Link Attributes as defined in RFC 9492, and OSPF Flexible Algorithm as defined in RFC 9350. | |||||||||||||
| draft-ietf-lsr-srv6-mirror-sid-igp-encoding-00.txt | ||||||||||||||
| IGP Encoding for SRv6 Mirror SID in Egress Protection | ||||||||||||||
|
This document specifies the IGP protocol extensions required to support SRv6 path egress protection using the Mirror SID (End.M) mechanism. It reuses the existing SRv6 End SID sub-TLV defined in [RFC9352] (IS-IS, Section 7.2) and [RFC9513] (OSPFv3, Section 8) with the End.M endpoint behavior (74) to advertise the Mirror SID and the set of protected locators, and defines a new Protected Locators sub-(sub-)TLV, enabling a backup egress node (protector) to signal its capability to protect a primary egress node within a single link- state IGP area. This document is a companion to [I-D.ietf-rtgwg-srv6-egress-protection], which specifies the overall SRv6 path egress protection mechanism and the End.M behavior. The IGP encoding defined herein provides the signaling substrate for that mechanism. | |||||||||||||
| draft-ietf-lsvr-bgp-ls-yang-04.txt | ||||||||||||||
| A YANG Model for BGP-LS,BGP-LS-VPN,and BGP-LS-SPF | ||||||||||||||
|
This document defines a YANG data model for configuration and management of BGP-LS, BGP-LS-VPN, and BGP-LS-SPF. | |||||||||||||
| draft-ietf-mailmaint-autoconfig-06.txt | ||||||||||||||
| Mail Autoconfig | ||||||||||||||
|
A protocol that allows email applications to set up mail accounts and related accounts with only the email address and password. It defines how service providers can publish the account configuration, so that email applications can automatically find a working configuration. It reduces setup friction for their users, and calls to the support for the service provider. Although the discovery process starts with an email address, the protocol is not limited setting up email accounts, but can also set up calendar, contact and file sync, video conference accounts and other accounts that are connected to the same user account. This protocol uses a well-known address and DNS lookups, based on the email address domain, to find the XML configuration file for the service provider. | |||||||||||||
| draft-ietf-mailmaint-expires-06.txt | ||||||||||||||
| Updated Use of the Expires Message Header Field | ||||||||||||||
|
This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message expires, while recipients would use this information to handle an expired message differently. | |||||||||||||
| draft-ietf-mailmaint-imap-extensions-suggestions-02.txt | ||||||||||||||
| IMAP Extensions Suggestions | ||||||||||||||
|
This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations. | |||||||||||||
| draft-ietf-mailmaint-imap-objectid-bis-06.txt | ||||||||||||||
| IMAP Extension for Object Identifiers | ||||||||||||||
|
This document defines the OBJECTID+ extension for IMAP, which obsoletes [RFC8474]. OBJECTID+ introduces a compound OBJECTID response format that bundles object identifiers into key-value pairs, an ACCOUNTID identifier for account-level context, OBJECTID response codes for the RENAME command, and identifier-based mailbox selection via SELECT and EXAMINE. The OBJECTID+ extension is activated implicitly when a client uses any OBJECTID+-specific feature, ensuring backward compatibility with clients that only support [RFC8474]. This document also updates [RFC9698]: when JMAPACCESS is advertised alongside OBJECTID+, ACCOUNTID values MUST correspond to JMAP accountIds. | |||||||||||||
| draft-ietf-mailmaint-oauth-public-06.txt | ||||||||||||||
| OAuth Profile for Open Public Clients | ||||||||||||||
|
This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. The profile is restricted to native clients, that is, applications installed and run on the end user's device. It deliberately does not support web-based clients, which cannot complete the flow as specified. | |||||||||||||
| draft-ietf-mailmaint-pacc-03.txt | ||||||||||||||
| Automatic Configuration of Email,Calendar,and Contact Server Settings | ||||||||||||||
|
This document specifies an automatic configuration mechanism for email, calendar, and contact user agent applications. Service providers publish standardized configuration information that user agent applications retrieve and use to simplify server setup procedures. | |||||||||||||
| draft-ietf-mailmaint-pdparchive-02.txt | ||||||||||||||
| Personal Data Portability Archive | ||||||||||||||
|
This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data. | |||||||||||||
| draft-ietf-mailmaint-smtputf8-syntax-05.txt | ||||||||||||||
| SMTPUTF8 Email Addresses | ||||||||||||||
|
RFC 6532 extends the internet email format to allow UTF8 in many contexts. This document restricts the set of allowed addresses in header fields slightly, and thereby simplifies use of these addresses. This is one of a pair of documents. This one is simple to implement and contains only globally viable rules. Its companion has more complex rules, takes regional usage into account, and describes addresses that can be read by some community and cut-and-pasted in some locale. | |||||||||||||
| draft-ietf-mailmaint-unobtrusive-signatures-02.txt | ||||||||||||||
| Unobtrusive End-to-End Email Signatures | ||||||||||||||
|
This document deals with end-to-end cryptographically signed email. It introduces a structure for signed email that is designed to avoid creating any disturbance in legacy email clients. This "unobtrusive" signature structure removes disincentives for signing email. | |||||||||||||
| draft-ietf-manet-dlep-channel-utilization-04.txt | ||||||||||||||
| DLEP Radio Channel Utilization Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel. | |||||||||||||
| draft-ietf-manet-dlep-radio-band-04.txt | ||||||||||||||
| DLEP Radio Band Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide information about frequency bands used by the radio. | |||||||||||||
| draft-ietf-manet-dlep-radio-quality-04.txt | ||||||||||||||
| DLEP Radio Quality Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the quality of incoming radio signals. | |||||||||||||
| draft-ietf-manet-inet-gap-analysis-10.txt | ||||||||||||||
| MANET Internetworking: Problem Statement and Gap Analysis | ||||||||||||||
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. | |||||||||||||
| draft-ietf-manet-olsrv2-responsive-01.txt | ||||||||||||||
| Responsive Use of the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 | ||||||||||||||
|
This specification describes an optional Topology Control (TC) message that can be sent by an OLSRv2 router. This is permitted, but not suggested, by the existing protocol, but is here recommended for use in some networks. The original motivation for this message came from considering the circumstances of a mostly stable network, in the most extreme case updated only by messages responding to the arrival and departure of routers, in which case the additional TC message would be not just recommended but required. While this extreme case is highly unlikely to be ever used, consideration of this additional message indicates that it could be useful in reducing the routing convergence time in any network in which messages are sent at lengthy intervals. Sending such a message is, although not previously suggested, permitted by OLSRv2 and thus implementations of OLSRv2 that do and do not send such messages are fully compatible. This specification updates RFC 7181 "The Optimized Link State Routing Protocol version 2 (OLSRv2)". | |||||||||||||
| draft-ietf-masque-connect-ethernet-14.txt | ||||||||||||||
| Proxying Ethernet Frames in HTTP | ||||||||||||||
|
This document describes how to proxy Ethernet frames in HTTP. This protocol is similar to IP proxying in HTTP, but for Layer 2 instead of Layer 3. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel to exchange Layer 2 Ethernet frames through an HTTP server with an attached physical or virtual Ethernet segment. | |||||||||||||
| draft-ietf-masque-connect-ip-dns-06.txt | ||||||||||||||
| DNS and PREF64 Configuration for Proxying IP in HTTP | ||||||||||||||
|
Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism lacks a way to communicate network configuration details such as DNS information or IPv6 NAT64 prefixes (PREF64). In contrast, most existing VPN protocols provide mechanisms to exchange such configuration information. This document defines extensions that convey DNS and PREF64 configuration using HTTP capsules. This mechanism supports encrypted DNS transports and can be used to inform peers about network translation prefixes for IPv6/IPv4 synthesis. | |||||||||||||
| draft-ietf-masque-connect-udp-ecn-dscp-02.txt | ||||||||||||||
| ECN and DSCP support for HTTPS's Connect-UDP | ||||||||||||||
|
HTTP's Extended Connect's Connect-UDP protocol enables a client to proxy a UDP flow from the HTTP server towards a specified target IP address and UDP port. QUIC and Real-time transport protocol (RTP) are examples of transport protocols that use UDP and support Explicit Congestion Notification (ECN) and provide the necessary feedback. This document specifies how ECN and DSCP can be supported through an extension to the Connect-UDP protocol for HTTP without per-packet byte overhead, solely using Context IDs. | |||||||||||||
| draft-ietf-masque-connect-udp-listen-16.txt | ||||||||||||||
| Proxying Bound UDP in HTTP | ||||||||||||||
|
The mechanism defined in "Proxying UDP in HTTP" (RFC 9298) only allows each UDP proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document defines an extension to that mechanism that enables such use cases. | |||||||||||||
| draft-ietf-masque-http-datagram-compression-01.txt | ||||||||||||||
| Extensions to Compress and Derive Fields in HTTP Datagrams | ||||||||||||||
|
This document defines extensions for HTTP Datagram-based protocols that improve transmission efficiency by introducing templates for compressing or deriving datagram fields. These templates allow endpoints to define parts of datagrams that are static and can be removed, and other parts that can be derived (such as packet lengths and checksum values). Additionally, this document defines a checksum offload procedure enabling receivers to complete Internet checksums using sender- provided partial values. These optimisations reduce per-packet overhead, processing cost, and increase the effective maximum transmission unit (MTU) when datagrams are encapsulated in QUIC DATAGRAM frames. | |||||||||||||
| draft-ietf-masque-quic-proxy-09.txt | ||||||||||||||
| QUIC-Aware Proxying Using HTTP | ||||||||||||||
|
This document extends UDP Proxying over HTTP to add optimizations for proxied QUIC connections. Specifically, it allows a proxy to reuse UDP 4-tuples for multiple proxied connections, and adds a mode of proxying in which QUIC short header packets can be forwarded and transformed through a HTTP/3 proxy rather than being fully re- encapsulated and re-encrypted. | |||||||||||||
| draft-ietf-mboned-amt-yang-09.txt | ||||||||||||||
| A YANG Data Model for Automatic Multicast Tunneling (AMT) | ||||||||||||||
|
This document defines a YANG data model for the management of Automatic Multicast Tunneling (AMT) protocol operations. | |||||||||||||
| draft-ietf-mboned-multicast-security-01.txt | ||||||||||||||
| Security and Privacy Considerations for Multicast Transports | ||||||||||||||
|
Interdomain multicast has unique potential to solve delivery scalability for popular content, but it carries a set of security and privacy issues that differ from those in unicast delivery. This document analyzes the security threats unique to multicast-based delivery for Internet and Web traffic under the Internet and Web threat models. 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/squarooticus/draft-krose-multicast-security. | |||||||||||||
| draft-ietf-mboned-multicast-yang-model-18.txt | ||||||||||||||
| A YANG Data Model for Multicast Services | ||||||||||||||
|
This document provides a generic multicast YANG data model that shows the relevant technologies or protocols used by multicast flows. It provides a management view for network administrators to obtain information about multicast services. | |||||||||||||
| draft-ietf-mboned-non-source-routed-sr-mcast-06.txt | ||||||||||||||
| Non-source-routed Multicast in SR Networks | ||||||||||||||
|
With Segment Routing (SR) architecture, a unicast flow can be source- routed through an SR network following an explicit path specified in the packet, without the need for per-flow state in the network. As a result, the protocols that would be otherwise needed to signal the per-flow unicast state are not needed either. In the case of multicast, traffic can be either source-routed or non-source-routed, and this document summarizes options for non-source-routed multicast in an SR network, including pre-SR tree-based multicast technologies, BIER, and various SR specific solutions. The pros and cons of each solution are listed for considerations by operators and vendors, with regard to the principle and characteristic of SR as mentioned above. | |||||||||||||
| draft-ietf-mboned-redundant-ingress-failover-10.txt | ||||||||||||||
| Multicast Redundant Ingress Router Failover | ||||||||||||||
|
This document is intended to serve as a guide for multicast network operators of various replication technologies to evaluate the options and tradeoffs in deploying redundant ingress router failover. Section 5 of RFC9026 details the hot root standby solution for MVPN networks. Here we attempt to extend the discussion to cover additional multicast deployment solutions beyond MVPNs. This document compares cold, warm, and hot standby modes, listing their advantages, limitations and deployment considerations to help identify the appropriate solution for any network. | |||||||||||||
| draft-ietf-mediaman-6838bis-10.txt | ||||||||||||||
| Media Type Specifications and Registration Procedures | ||||||||||||||
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. It obsoletes [RFC6838] and [RFC9694]. Note that [RFC4289] is also part of BCP 13, and addresses registration of MIME External Body Access Types and Transfer Encodings. | |||||||||||||
| draft-ietf-mimi-arch-03.txt | ||||||||||||||
| An Architecture for More Instant Messaging Interoperability (MIMI) | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) working group is defining a suite of protocols that allow messaging providers to interoperate with one another. This document lays out an overall architecture enumerating the MIMI protocols and how they work together to enable an overall messaging experience. | |||||||||||||
| draft-ietf-mimi-content-09.txt | ||||||||||||||
| More Instant Messaging Interoperability (MIMI) message content | ||||||||||||||
|
This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol. | |||||||||||||
| draft-ietf-mimi-protocol-06.txt | ||||||||||||||
| More Instant Messaging Interoperability (MIMI) using HTTPS and MLS | ||||||||||||||
|
This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. | |||||||||||||
| draft-ietf-mimi-room-policy-04.txt | ||||||||||||||
| Room Policy for the More Instant Messaging Interoperability (MIMI) Protocol | ||||||||||||||
|
This document describes a set of concrete room policies for the More Instant Messaging Interoperability (MIMI) Working Group. It describes several independent properties and policy attributes which can be combined to model a wide range of chat and multimedia conference types. | |||||||||||||
| draft-ietf-mlcodec-opus-dred-07.txt | ||||||||||||||
| Deep Audio Redundancy (DRED) Extension for the Opus Codec | ||||||||||||||
|
This document proposes a mechanism for embedding very low bitrate deep audio redundancy (DRED) within the Opus codec (RFC6716) bitstream. | |||||||||||||
| draft-ietf-mlcodec-opus-extension-06.txt | ||||||||||||||
| Extension Formatting for the Opus Codec | ||||||||||||||
|
This document updates RFC6716 to extend the Opus codec (RFC6716) in a way that maintains interoperability, while adding optional functionality. | |||||||||||||
| draft-ietf-mlcodec-opus-scalable-quality-extension-02.txt | ||||||||||||||
| Scalable Quality Extension for the Opus Codec (Opus HD) | ||||||||||||||
|
This document updates [RFC6716] to add support for a scalable quality layer. | |||||||||||||
| draft-ietf-mlcodec-opus-speech-coding-enhancement-04.txt | ||||||||||||||
| Integration of Speech Codec Enhancement Algorithms into the Opus Codec | ||||||||||||||
|
This document proposes a set of requirements for integrating a speech codec enhancement algorithm into the Opus codec [RFC6716]. | |||||||||||||
| draft-ietf-mlcodec-test-battery-00.txt | ||||||||||||||
| Test Battery for Opus ML Codec Extensions | ||||||||||||||
|
This document proposes methodology and data for evaluation of machine learning (ML) codec extensions, such as the deep audio redundancy (DRED), within the Opus codec (RFC6716). | |||||||||||||
| draft-ietf-mls-extensions-10.txt | ||||||||||||||
| The Messaging Layer Security (MLS) Extensions | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol is an asynchronous group authenticated key exchange protocol. MLS provides a number of capabilities to applications, as well as several extension points internal to the protocol. This document provides a consolidated application API, guidance for how the protocol's extension points should be used, and a few concrete examples of both core protocol extensions and uses of the application API. | |||||||||||||
| draft-ietf-mls-partial-02.txt | ||||||||||||||
| Partial 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. | |||||||||||||
| draft-ietf-mls-pq-ciphersuites-06.txt | ||||||||||||||
| ML-KEM and Hybrid Cipher Suites for Messaging Layer Security | ||||||||||||||
|
This document registers new cipher suites for Messaging Layer Security (MLS) based on "post-quantum" algorithms, which are intended to be resilient to attack by quantum computers. These cipher suites are constructed using the new Module-Lattice Key Encapsulation Mechanism (ML-KEM), optionally in combination with traditional elliptic curve KEMs, together with appropriate authenticated encryption, hash, and signature algorithms. | |||||||||||||
| draft-ietf-mls-ratchet-tree-options-01.txt | ||||||||||||||
| Ways to convey the Ratchet Tree in Messaging Layer Security | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol needs to share its ratchet_tree object to welcome new clients into a group and in external joins. While the protocol only defines a mechanism for sharing the entire tree, most implementations use various optimizations to avoid sending this structure repeatedly in large groups. This document describes a way to convey these improvements in a standardized way and to convey the parts of a GroupInfo object that are not visible to an intermediary server. | |||||||||||||
| draft-ietf-mls-targeted-messages-01.txt | ||||||||||||||
| Messaging Layer Security (MLS) Targeted Messages | ||||||||||||||
|
This document defines targeted messages for the Messaging Layer Security (MLS) protocol. A targeted message allows a member of an MLS group to send an encrypted and authenticated message to another member of the same group without creating a new group. The mechanism reuses Hybrid Public Key Encryption (HPKE) and the MLS key schedule to provide confidentiality, authentication, and binding to the group state. | |||||||||||||
| draft-ietf-mls-virtual-clients-01.txt | ||||||||||||||
| MLS Virtual Clients | ||||||||||||||
|
This document describes a method that allows multiple MLS clients to emulate a virtual MLS client. A virtual client allows multiple emulator clients to jointly participate in an MLS group under a single leaf. Depending on the design of the application, virtual clients can help hide metadata and improve performance. | |||||||||||||
| draft-ietf-mops-network-overlay-impacts-04.txt | ||||||||||||||
| Network Overlay Impacts to Streaming Video | ||||||||||||||
|
This document examines the operational impacts on streaming video applications resulting from network policy changes introduced by network overlays. Such overlays may alter IP address assignment, transport protocols, routing behavior, or DNS resolution. These changes can, in turn, affect critical aspects of content delivery, including latency, CDN cache selection, delivery path optimization, traffic classification, and content access controls. | |||||||||||||
| draft-ietf-moq-c4m-01.txt | ||||||||||||||
| Authorization scheme for MOQT using Common Access Tokens | ||||||||||||||
|
A token-based authorization scheme for use with Media Over QUIC Transport. | |||||||||||||
| draft-ietf-moq-cmsf-01.txt | ||||||||||||||
| CMSF- a CMAF compliant implementation of MOQT Streaming Format | ||||||||||||||
|
This document updates MOQT Streaming Format by defining optional syntax and semantics for carrying CMAF-packaged media. | |||||||||||||
| draft-ietf-moq-loc-04.txt | ||||||||||||||
| Low Overhead Media Container | ||||||||||||||
|
This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It may be used in the MOQT Streaming Format (MSF) specification, which defines a catalog format for publishers to declare and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT. | |||||||||||||
| draft-ietf-moq-msf-01.txt | ||||||||||||||
| MOQT Streaming Format | ||||||||||||||
|
This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. | |||||||||||||
| draft-ietf-moq-privacy-pass-auth-03.txt | ||||||||||||||
| Privacy Pass Authentication for Media over QUIC (MoQ) | ||||||||||||||
|
This document specifies the use of Privacy Pass architecture and issuance protocols for authorization in Media over QUIC (MoQ) transport protocol. It defines how Privacy Pass tokens can be integrated with MoQ's authorization framework to provide privacy- preserving authentication for subscriptions, fetches, publications, and relay operations while supporting fine-grained access control through prefix-based track namespace and track name matching rules. | |||||||||||||
| draft-ietf-moq-secure-objects-01.txt | ||||||||||||||
| End-to-End Secure Objects for Media over QUIC Transport | ||||||||||||||
|
This document specifies an end-to-end authenticated encryption scheme for application objects transmitted via Media over QUIC (MoQ) Transport. The scheme enables original publishers that share a symmetric key with end subscribers, to ensuring that MoQ relays are unable to decrypt object contents. Additionally, subscribers can verify the integrity and authenticity of received objects, confirming that the content has not been modified in transit. Additionally it allows MoQ parameters to be protected so the publisher can select if they are readable and/or modifiable by relays. | |||||||||||||
| draft-ietf-moq-transport-21.txt | ||||||||||||||
| Media over QUIC Transport | ||||||||||||||
|
This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. | |||||||||||||
| draft-ietf-mpls-frr-ext-00.txt | ||||||||||||||
| Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels | ||||||||||||||
|
This document introduces RSVP-TE signaling procedures that enable the head-end Label Switched Router (LSR) of a local-protection-desiring Label Switched Path (LSP) to influence the optimization objective and bounded metric constraints used for the path computation of a backup LSP tunnel at a Point of Local Repair (PLR). | |||||||||||||
| draft-ietf-mpls-lsp-ping-ioam-conf-state-02.txt | ||||||||||||||
| LSP Ping/Traceroute for Enabled In-situ OAM Capabilities | ||||||||||||||
|
This document describes the application of the mechanism of discovering In-situ OAM (IOAM) capabilities, described in RFC 9359 "Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities", in MPLS networks. The MPLS Node IOAM Information Query functionality uses the MPLS echo request/reply messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. | |||||||||||||
| draft-ietf-mpls-mldp-yang-16.txt | ||||||||||||||
| YANG Data Model for MPLS mLDP | ||||||||||||||
|
This document describes a YANG data model for the Multiprotocol Label Switching (MPLS) Multipoint Label Distribution Protocol (mLDP). The mLDP YANG data model augments the MPLS LDP YANG data model. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-mpls-mna-detnet-01.txt | ||||||||||||||
| MPLS Network Action for Deterministic Networking | ||||||||||||||
|
This document specifies formats and mechanisms for using MPLS Network Actions (MNA) to support Deterministic Networking (DetNet) services, including bounded latency, low loss and in-order delivery. It defines MPLS In-Stack and Post-Stack MNA for carrying DetNet-specific information, such as flow identification, sequence number, and latency information, which are forwarded over an MPLS technology- based network domain. | |||||||||||||
| draft-ietf-mpls-mna-ioam-14.txt | ||||||||||||||
| MPLS Network Actions for In Situ Operations,Administration,and Maintenance | ||||||||||||||
|
In situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, collects operational and telemetry information in the packet using IOAM-Data-Fields while the packet traverses a path between two points in the network. Several IOAM Option-Types are available, for example, Pre-allocated Trace, Proof of Transit (POT), Edge-to-Edge (E2E), and Incremental Trace, that can be used to collect information for calculating various performance metrics. RFC 9326 defines the IOAM Direct Export (IOAM-DEX) Option-Type, which is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. MPLS Network Action (MNA) mechanisms indicate actions to be performed on any combination of Label Switched Paths, MPLS packets, and the node itself, and to transport data needed for these actions. This document defines MNAs to collect and transport the operational state and telemetry information using IOAM-Data-Fields as well as IOAM-DEX. | |||||||||||||
| draft-ietf-mpls-mna-nrp-selector-07.txt | ||||||||||||||
| MPLS Network Actions for Network Resource Partition Selector | ||||||||||||||
|
An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provide the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry markings in the packet's network layer header to identify this association and each is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provides the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document specifies options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets. | |||||||||||||
| draft-ietf-mpls-mna-ps-hdr-19.txt | ||||||||||||||
| MPLS Network Action (MNA) Post-Stack Header Specification | ||||||||||||||
|
This document specifies the MPLS Network Action (MNA) Post-Stack Header encoding and procedures for carrying Network Action encodings and Ancillary Data after the MPLS label stack, based on the MNA Sub- Stack including In-Stack Network Actions and Data specified in RFC 9994. MPLS Network Actions can be used to influence packet forwarding decisions, carry additional Operations, Administration, and Maintenance information in the MPLS packet, or perform user- defined operations. This document follows the framework specified in RFC 9789. This document updates RFC 9994: the "Network Action Opcodes" registry fields, the Post-Stack MNA applicability of the opcodes, MNA scope, and Unknown action handling. This document updates RFC 9789: the definition of Readable Label Depth (RLD). | |||||||||||||
| draft-ietf-mpls-on-path-telemetry-flag-04.txt | ||||||||||||||
| MPLS On-Path Telemetry Network Action Flag for OAM | ||||||||||||||
|
This document describes postcard-based on-path telemetry with packet marking (PBT-M) using an MPLS Network Actions (MNA) flag to support Operations, Administration, and Maintenance (OAM) in MPLS networks. The scheme uses a single flag bit carried in a Flag-Based Network Action Indicator (Opcode 1) of the MNA Sub-Stack as defined in RFC 9994. In addition to addressing the protocol requirements for applying PBT-M, this document provides comprehensive operational, manageability, and security considerations. | |||||||||||||
| draft-ietf-mpls-stamp-01.txt | ||||||||||||||
| Simple Two-way Active Measurement Protocol (STAMP) for MPLS Label Switched Paths (LSPs) | ||||||||||||||
|
Simple Two-way Active Measurement Protocol (STAMP), defined in RFC 8762 and RFC 8972, is expected to be able to monitor the performance of paths between systems that use a wide variety of encapsulations. This document defines encapsulation and bootstrapping of a STAMP test session over an MPLS Label Switched Path. | |||||||||||||
| draft-ietf-mpls-stamp-pw-21.txt | ||||||||||||||
| Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and Pseudowires in MPLS Networks | ||||||||||||||
|
This document specifies encapsulations for the Simple Two-Way Active Measurement Protocol (STAMP), defined in RFC 8762, and its optional extensions, defined in RFC 8972, in MPLS networks. It specifies the encapsulation of STAMP test packets for point-to-point Label Switched Paths (LSPs) and point-to-point single-segment Pseudowires (PWs), with or without an IP/UDP header, so that the test packets experience the same forwarding and Equal-Cost Multi-Path (ECMP) behavior as the data traffic being measured. In addition, two new MPLS Generic Associated Channel (G-ACh) types are defined. The procedures specified in this document are intended for deployment in a single network administrative domain. This document updates RFC 8762 and RFC 8972 to allow STAMP to operate without an IP/UDP header when STAMP test packets are carried over MPLS LSPs and PWs, and specifies the resulting changes to the processing of the STAMP session identifier, the IPv4 TTL and IPv6 Hop Limit, and the STAMP TLV extensions. | |||||||||||||
| draft-ietf-netconf-adaptive-subscription-18.txt | ||||||||||||||
| Adaptive Subscription to YANG Notifications | ||||||||||||||
|
This document defines an experimental mechanism and its companion YANG data model to enable adaptive subscriptions to YANG notifications. The publisher can dynamically adjust the periodic update interval based on the evaluation of pre-configured conditions (e.g., thresholds or expressions). This allows for finer-grained telemetry by increasing update frequency when certain criteria are met, and reducing it otherwise. | |||||||||||||
| draft-ietf-netconf-distributed-notif-21.txt | ||||||||||||||
| Subscription to Notifications in a Distributed Architecture | ||||||||||||||
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system of a network node. | |||||||||||||
| draft-ietf-netconf-http-client-server-33.txt | ||||||||||||||
| YANG Groupings for HTTP Clients and HTTP Servers | ||||||||||||||
|
This document presents three YANG 1.1 modules as follows. The "iana- http-versions" module defines a YANG "typedef" for HTTP protocol versions. The "ietf-http-client" module defines a YANG "grouping" for configuring an HTTP client's ability to communicate with an HTTP service endpoint. The "ietf-http-server" module defines a "grouping" for configuring an HTTP server's service endpoints. | |||||||||||||
| draft-ietf-netconf-https-notif-16.txt | ||||||||||||||
| An HTTPS-based Transport for YANG Notifications | ||||||||||||||
|
This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. | |||||||||||||
| draft-ietf-netconf-https-notif-cbor-01.txt | ||||||||||||||
| CBOR Encoding for HTTPS-based YANG Notifications Transport | ||||||||||||||
|
This document extends [I-D.draft-ietf-netconf-https-notif] by introducing CBOR encoding for YANG notifications over HTTPS transport in addition to the existing JSON and XML encoding schemes. | |||||||||||||
| draft-ietf-netconf-list-pagination-13.txt | ||||||||||||||
| List Pagination for YANG-driven Protocols | ||||||||||||||
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. | |||||||||||||
| draft-ietf-netconf-list-pagination-nc-12.txt | ||||||||||||||
| NETCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the | |||||||||||||
| draft-ietf-netconf-list-pagination-rc-11.txt | ||||||||||||||
| RESTCONF Extensions to Support List Pagination | ||||||||||||||
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET operation, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. | |||||||||||||
| draft-ietf-netconf-netconf-client-server-41.txt | ||||||||||||||
| A YANG Data Model for NETCONF Clients and Servers | ||||||||||||||
|
This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. These modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. | |||||||||||||
| draft-ietf-netconf-notif-envelope-06.txt | ||||||||||||||
| Extensible YANG Model for YANG-Push Notifications | ||||||||||||||
|
This document defines a new extensible Notification structure, defined in YANG, for use in YANG-Push Notification messages, both for NETCONF and RESTCONF, enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the data was observed. | |||||||||||||
| draft-ietf-netconf-over-quic-11.txt | ||||||||||||||
| NETCONF over QUIC | ||||||||||||||
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. NETCONF over QUIC allows to take advantage of QUIC streams, for example, to eliminate some TCP head-of-line blocking issues. NETCONF over QUIC provides security properties similar to NETCONF over TLS. This document also defines a YANG module which augments the ietf- netconf-client and ietf-netconf-server YANG modules. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server | |||||||||||||
| draft-ietf-netconf-privcand-10.txt | ||||||||||||||
| NETCONF and RESTCONF Private Candidate Datastores | ||||||||||||||
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. | |||||||||||||
| draft-ietf-netconf-quic-call-home-01.txt | ||||||||||||||
| NETCONF Call Home and RESTCONF Call Home Using QUIC | ||||||||||||||
|
This RFC extends NETCONF Call Home and RESTCONF Call Home [RFC 8071] to support the QUIC protocol [RFC 9000]. | |||||||||||||
| draft-ietf-netconf-quic-client-server-08.txt | ||||||||||||||
| YANG Groupings for QUIC clients and QUIC servers | ||||||||||||||
|
This document defines five YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers as well as initial modules for the IANA registries "QUIC Versions" and "QUIC Transport Parameters". | |||||||||||||
| draft-ietf-netconf-restconf-client-server-45.txt | ||||||||||||||
| A YANG Data Model for RESTCONF Clients and Servers | ||||||||||||||
|
This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. These modules support both standard and RESTCONF Call Home connections. | |||||||||||||
| draft-ietf-netconf-restconf-trace-ctx-headers-11.txt | ||||||||||||||
| RESTCONF Extension to Support Trace Context Headers | ||||||||||||||
|
This document defines an extension to the RESTCONF protocol to support Trace Context propagation as defined by the W3C. | |||||||||||||
| draft-ietf-netconf-trace-ctx-extension-09.txt | ||||||||||||||
| NETCONF Extension to support Trace Context propagation | ||||||||||||||
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), enabling distributed tracing scenarios. It is an adaptation of the HTTP-based W3C specification and defines three YANG modules. | |||||||||||||
| draft-ietf-netconf-udp-notif-26.txt | ||||||||||||||
| UDP-based Transport for Configured Subscriptions | ||||||||||||||
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes within a controlled environment. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enables higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. | |||||||||||||
| draft-ietf-netconf-yang-notifications-versioning-16.txt | ||||||||||||||
| Support of Versioning in YANG Notifications Subscription | ||||||||||||||
|
This document defines a YANG module which extends the YANG-Push Subscription mechanism to enforce that particular revisions or semantic versions are used when configuring or establishing a Subscription. It also extends the YANG-Push Subscription state change Notifications to include additional context about the YANG schema associated with the Subscription. | |||||||||||||
| draft-ietf-netconf-yang-push-2-00.txt | ||||||||||||||
| YANG Datastore Telemetry (YANG Push version 2) | ||||||||||||||
|
YANG Push version 2 is a YANG datastore telemetry solution, as an alternative lightweight specification to the Subscribed Notifications and YANG Push solution, specifically optimized for the efficient observability of operational data. | |||||||||||||
| draft-ietf-netconf-yp-transport-capabilities-07.txt | ||||||||||||||
| YANG Notification Transport Capabilities | ||||||||||||||
|
This document specifies a YANG module for discovering transport capabilities for YANG notifications. The module augments the YANG notifications capabilities model with capabilities for the notification transport protocol, transport encoding, and transport encryption. The capabilities enable a client to determine the notification transport options supported by a NETCONF or RESTCONF server at runtime or at implementation time using the YANG instance data file format. | |||||||||||||
| draft-ietf-netmod-iana-yang-guidance-03.txt | ||||||||||||||
| Guidance for Managing YANG Modules in RFCs and IANA Registries | ||||||||||||||
|
This document provides guidance to the RFC Editor and IANA on managing YANG modules in RFCs and IANA registries, ensuring consistent application of YANG Semantic Versioning rules. | |||||||||||||
| draft-ietf-netmod-immutable-flag-14.txt | ||||||||||||||
| YANG Metadata Annotation for Immutable Flag | ||||||||||||||
|
This document defines a mechanism to formally document an existing behavior, implemented by servers of YANG-driven network management protocols (e.g., NETCONF and RESTCONF), on the immutability of some system-provided nodes, using a YANG metadata annotation called "immutable" to flag which nodes are immutable. Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error. The immutable flag is descriptive, documenting an existing behavior, not prescriptive, dictating server behaviors. This document updates RFC 8040 and RFC 8526. | |||||||||||||
| draft-ietf-netmod-intf-ext-yang-19.txt | ||||||||||||||
| Common Interface Extension YANG Data Models | ||||||||||||||
|
This document defines two YANG modules that augment the Interfaces data model defined in the "YANG Data Model for Interface Management" with additional configuration and operational data nodes to support common lower layer interface properties. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | |||||||||||||
| draft-ietf-netmod-sub-intf-vlan-model-18.txt | ||||||||||||||
| Sub-interface VLAN YANG Data Models | ||||||||||||||
|
This document defines YANG modules to add support for classifying traffic received on interfaces as Ethernet/VLAN framed packets to sub-interfaces based on the fields available in the Ethernet/VLAN frame headers. These modules allow configuration of Layer 3 (L3) and Layer 2 (L2) sub-interfaces (e.g., L2VPN attachment circuits) that can interoperate with IETF based forwarding protocols, such as IP and L3VPN services, or L2VPN services like Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), and EVPN. The sub- interfaces also interoperate with VLAN tagged traffic originating from an IEEE 802.1Q compliant bridge. The model differs from an IEEE 802.1Q bridge model in that the configuration is interface/sub-interface based as opposed to being based on membership of an 802.1Q VLAN bridge. The YANG data models in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. | |||||||||||||
| draft-ietf-netmod-yang-module-filename-15.txt | ||||||||||||||
| YANG Module File Name Convention | ||||||||||||||
|
This document defines the YANG module file name convention. The convention extends the YANG module file name using revision-date, with the YANG semantic version extension. The YANG semantic version extension allows for an informative version to be associated with a particular YANG module revision. This document updates RFCs 6020, 7950, and 9907. | |||||||||||||
| draft-ietf-netmod-yang-module-versioning-17.txt | ||||||||||||||
| Updated YANG Module Revision Handling | ||||||||||||||
|
This document refines the RFC 7950 module update rules. It specifies a new YANG module update procedure that can document when non- backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with a suggestion for a minimum revision. This helps document inter-module dependencies. It provides guidelines for managing the lifecycle of YANG modules and individual schema nodes. This document updates RFC 7950, RFC 6020, RFC 8525, and RFC 9907. | |||||||||||||
| draft-ietf-netmod-yang-next-agreement-00.txt | ||||||||||||||
| YANG Next Agreement | ||||||||||||||
|
The purpose of this document is to discuss and hopefully find agreement on the scope and shape of the next version of YANG. | |||||||||||||
| draft-ietf-netmod-yang-packages-09.txt | ||||||||||||||
| YANG Packages | ||||||||||||||
|
This document defines YANG packages: versioned organizational structures used to manage the schema and conformance of a set of YANG modules as a cohesive unit. | |||||||||||||
| draft-ietf-netmod-yang-schema-comparison-09.txt | ||||||||||||||
| YANG Schema Comparison | ||||||||||||||
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes and produce a list of the changes between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the possible output of this algorithm. | |||||||||||||
| draft-ietf-netmod-yang-semver-28.txt | ||||||||||||||
| YANG Semantic Versioning | ||||||||||||||
|
This document specifies a YANG extension along with guidelines for applying an extended set of semantic versioning rules to revisions of YANG artifacts (e.g., modules and packages). Additionally, this document defines a YANG extension for controlling module imports based on these modified semantic versioning rules. This document updates RFCs 7950, 9907, and 8525. | |||||||||||||
| draft-ietf-netmod-yang-versioning-reqs-14.txt | ||||||||||||||
| YANG Module Versioning Requirements | ||||||||||||||
|
This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. | |||||||||||||
| draft-ietf-netmod-yang-xml-00.txt | ||||||||||||||
| XML Encoding of Data Modeled with YANG | ||||||||||||||
|
This document defines encoding rules for representing YANG modeled configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using XML. | |||||||||||||
| draft-ietf-netmod-yang2-00.txt | ||||||||||||||
| The YANG 2.0 Data Modeling Language | ||||||||||||||
|
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 2.0 of the YANG language. YANG version 2.0 is a major release of the YANG language, addressing issues found in the original specification. | |||||||||||||
| draft-ietf-nfsv4-acls-update-05.txt | ||||||||||||||
| ACLs within the NFSv4 Protocols | ||||||||||||||
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc8881bis respecification effort for NFSv4.1. It describes the structure and function of NFSv4 Access Control Lists within NFSv4.0 and NFSv4.1. These minor versions and forthcoming ones define ACLs using an ACL structure derived from Windows ACLs. Support for other ACL approaches such as draft-POSIX ACLs remains an option that could be taken advantage of in later minor versions such as NFSv4.2. This document describes the structure of these Windows-derived NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of these ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality based on ACLs is covered as well. Because of the failure of previous specifications to provide a satisfactory description of the authorization semantics of NFSv4 ACLs, this document takes a different approach to many matters while maintaining compatibility with implementations based on previous specifications. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. | |||||||||||||
| draft-ietf-nfsv4-internationalization-17.txt | ||||||||||||||
| Internationalization for the NFSv4 Protocols | ||||||||||||||
|
This document describes the handling of internationalization for all NFSv4 protocols, including NFSv4.0, NFSv4.1, NFSv4.2 and extensions thereof, and future minor versions. It updates RFC7530 and RFC8881. | |||||||||||||
| draft-ietf-nfsv4-nfs-acl-05.txt | ||||||||||||||
| The Network File System Access Control List Protocol | ||||||||||||||
|
This Informational document describes the NFS_ACL protocol. NFS_ACL is a legacy member of the Network File System family of protocols that NFS clients use to view and update Access Control Lists stored on an NFS version 2 or version 3 server. | |||||||||||||
| draft-ietf-nfsv4-posix-acls-02.txt | ||||||||||||||
| POSIX Draft ACL support for Network File System Version 4,Minor Version 2 | ||||||||||||||
|
This document proposes four new optional file attributes for NFSv4.2 to support POSIX ACLs conforming to the withdrawn POSIX 1003.1e draft 17. Although never ratified, POSIX ACLs are implemented in widely deployed operating systems. Existing attempts to map between NFSv4 and POSIX ACL models have been unsuccessful due to semantic incompatibilities. These new attributes allow servers to expose POSIX ACLs directly, avoiding lossy mapping. | |||||||||||||
| draft-ietf-nfsv4-rfc8881bis-10.txt | ||||||||||||||
| Network File System (NFS) Version 4 Minor Version 1 Protocol | ||||||||||||||
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made and part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. | |||||||||||||
| draft-ietf-nfsv4-uncacheable-directories-11.txt | ||||||||||||||
| Adding an Uncacheable Dirent Metadata Attribute to NFSv4.2 | ||||||||||||||
|
Network File System version 4.2 (NFSv4.2) clients may cache the file attributes returned by READDIR alongside each directory entry. Such a cache is not invalidated by the directory's change attribute, which reflects changes to the directory and its entries but not writes to the files those entries name, so it can become stale when another client changes one of those files. In some deployments this produces incorrect size and timestamp values often enough to be a problem. This document introduces an uncacheable dirent metadata attribute for NFSv4.2 that allows a server to identify a directory for which an honoring client goes to the server for each enumeration, and does not report an entry's attributes from a value it held before that READDIR. | |||||||||||||
| draft-ietf-nfsv4-uncacheable-files-16.txt | ||||||||||||||
| Adding an Uncacheable File Data Attribute to NFSv4.2 | ||||||||||||||
|
Network File System version 4.2 (NFSv4.2) clients commonly perform client-side caching of file data in order to improve performance. On some systems, applications may influence client data caching behavior, but there is no standardized mechanism for a server or administrator to indicate that particular file data should not be cached by clients for reasons of performance or correctness. This document introduces a new file data caching attribute for NFSv4.2. Files marked with this attribute are intended to be accessed with client-side caching of file data suppressed, in order to support workloads that require predictable data visibility. This document extends NFSv4.2. | |||||||||||||
| draft-ietf-nmop-message-broker-telemetry-message-05.txt | ||||||||||||||
| Extensible YANG Model for Network Telemetry Messages | ||||||||||||||
|
This document defines an extensible message schema in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. The extensible message schema enables data collectors to add metadata for the provenance of the operational network data. | |||||||||||||
| draft-ietf-nmop-network-anomaly-architecture-08.txt | ||||||||||||||
| A Framework for a Network Anomaly Detection Architecture | ||||||||||||||
|
This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. | |||||||||||||
| draft-ietf-nmop-network-anomaly-lifecycle-07.txt | ||||||||||||||
| An Experiment: Network Anomaly Detection Lifecycle | ||||||||||||||
|
This document defines a structured, iterative lifecycle for network anomaly detection systems to enable "human-in-the-loop" refinements. Key contributions include defining three lifecycle stages, a state machine for anomaly annotations, and YANG data models for standardized labeling and exchange. | |||||||||||||
| draft-ietf-nmop-network-anomaly-semantics-06.txt | ||||||||||||||
| Semantic Metadata Annotation for Network Anomaly Detection | ||||||||||||||
|
The document proposes a unified symptoms vocabulary for network anomaly metadata to improve data sharing and analysis among human network operators, network analytics implementers, and AI systems to improve accuracy of Service Disruption Detection. | |||||||||||||
| draft-ietf-nmop-network-incident-yang-14.txt | ||||||||||||||
| A YANG Data Model for Network Incident Management | ||||||||||||||
|
This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable root cause analysis. | |||||||||||||
| draft-ietf-nmop-rfc3535-20years-later-04.txt | ||||||||||||||
| An Update of Operators Requirements on Network Management Protocols and Modelling | ||||||||||||||
|
This document identifies a list of operators requirements for network management operations. These requirements reflect advances in this field since the publication of "IAB Network Management Workshop" (RFC 3535), which was instrumental for developing many key technologies that are widely deployed. 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/boucadair/rfc3535-20years-later. | |||||||||||||
| draft-ietf-nmop-simap-concept-13.txt | ||||||||||||||
| SIMAP: Concept,Requirements,and Use Cases | ||||||||||||||
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. SIMAP evolves the earlier 'Digital Map' concept by making explicit the ties between service and infrastructure layers, clarifying expected outcomes for operations and automation, and addressing ambiguity associated with the term 'digital.' The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. | |||||||||||||
| draft-ietf-nmop-yang-message-broker-integration-13.txt | ||||||||||||||
| An Architecture for YANG-Push to Message Broker Integration | ||||||||||||||
|
This document describes the motivation and architecture of a native YANG-Push notifications and YANG Schema integration into a Message Broker and YANG Schema Registry. | |||||||||||||
| draft-ietf-nmop-yang-message-broker-message-key-02.txt | ||||||||||||||
| YANG Message Keys for Message Broker Integration | ||||||||||||||
|
This document specifies a mechanism to define a unique Message key for a YANG to Message Broker integration and a topic addressing scheme based on YANG-Push subscription type and YANG Schema Node Identifier. This enables YANG data consumption of a subset of subscribed YANG data, either per specific YANG data node, identifier or telemetry message type, by indexing and organizing in Message Broker topics. It helps to index the information by using data taxonomy and organizes data in partitions and shards of Message Brokers and time series databases. | |||||||||||||
| draft-ietf-ntp-ntpv5-09.txt | ||||||||||||||
| Network Time Protocol Version 5 | ||||||||||||||
|
The Network Time Protocol (NTP) is a widely deployed protocol that allows hosts to obtain the current time of day from time servers. This document specifies version 5 of the protocol (NTPv5), which adopts a client-server model as its sole mode of operation. Legacy operational modes supported in earlier versions have been removed to improve protocol robustness and clarity. While this specification defines the protocol used for time distribution, it does not define the algorithms or heuristics employed by clients to determine or adjust their local time. | |||||||||||||
| draft-ietf-ntp-nts-for-ptp-04.txt | ||||||||||||||
| NTS4PTP - Network Time Security for the Precision Time Protocol | ||||||||||||||
|
This document specifies an automatic key management service for the integrated security mechanism (prong A) of IEEE Std 1588™-2019 (PTPv2.1) described there in Annex P. This key management follows the immediate security processing approach of prong A and extends the NTS Key Establishment protocol defined in IETF RFC 8915 for securing NTPv4. The resulting NTS for PTP (NTS4PTP) protocol provides a security solution for all PTP modes and operates completely independent of NTPv4. | |||||||||||||
| draft-ietf-ntp-nts-keyexchange-pool-01.txt | ||||||||||||||
| NTS extensions for enabling pools | ||||||||||||||
|
The aim of this document is to describe a system for NTS pools that are able to be used by clients without any knowledge beyond plain NTS. The work here focuses purely on creating an intermediate NTS Key Exchange server that can be configured with the addresses of multiple servers and distribute load between them. The parts of pool operation dealing with managing the list of servers are left out of scope for this work. | |||||||||||||
| draft-ietf-ntp-roughtime-19.txt | ||||||||||||||
| Roughtime | ||||||||||||||
|
This document describes Roughtime, an experimental protocol that aims to achieve two things: secure rough time synchronization even for clients without any idea of what time it is, and give clients a format for reporting any inconsistencies they observe between timeservers. This document specifies the on-wire protocol required for these goals, and discusses aspects of the ecosystem needed for it to work. | |||||||||||||
| draft-ietf-nvo3-rfc7348bis-10.txt | ||||||||||||||
| Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks | ||||||||||||||
|
This document specifies Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This document obsoletes RFC 7348, which documented the deployed VXLAN protocol for the benefit of the Internet community, and moves the VXLAN specification to the IETF document stream, allowing for the creation of extensions to VXLAN that require additions to the VXLAN header and their registration with IANA. The format and processing described here are fully compatible with those in RFC 7348. | |||||||||||||
| draft-ietf-oauth-attestation-based-client-auth-11.txt | ||||||||||||||
| OAuth 2.0 Attestation-Based Client Authentication | ||||||||||||||
|
This specification defines an extension to the OAuth 2.0 protocol (RFC 6749) that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity verified by a client attester without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0. | |||||||||||||
| draft-ietf-oauth-client-id-metadata-document-02.txt | ||||||||||||||
| OAuth Client ID Metadata Document | ||||||||||||||
|
This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. | |||||||||||||
| draft-ietf-oauth-deferred-token-response-00.txt | ||||||||||||||
| Deferred Token Response | ||||||||||||||
|
This document defines the Deferred Token Response (DTR) extension for OAuth 2.1. In existing OAuth grants, the token endpoint either issues an access token or returns an error. DTR establishes a generic asynchronous token request mechanism that any OAuth grant may plug into. In DTR-aware flows, the authorization server returns a deferral_code and a polling interval, indicating that the final token response will be available at a later time. The client retrieves the eventual response by polling the token endpoint, or by receiving a callback from the authorization server when one is configured. | |||||||||||||
| draft-ietf-oauth-first-party-apps-04.txt | ||||||||||||||
| OAuth 2.0 for First-Party Applications | ||||||||||||||
|
This document defines the Authorization Challenge Endpoint, which supports clients that want to control the process of obtaining authorization from the user using a native experience. In many cases, this can provide an entirely browserless OAuth 2.0 experience suited for native applications, only delegating to the browser in unexpected, high-risk, or error conditions. | |||||||||||||
| draft-ietf-oauth-identity-assertion-authz-grant-04.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-ietf-oauth-identity-chaining-17.txt | ||||||||||||||
| OAuth Identity and Authorization Chaining Across Domains | ||||||||||||||
|
This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. | |||||||||||||
| draft-ietf-oauth-rar-metadata-remediation-00.txt | ||||||||||||||
| OAuth 2.0 RAR Metadata and Error Remediation | ||||||||||||||
|
OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] standardizes the exchange and processing of authorization details but does not define metadata for describing authorization details types. In addition, no interoperable guidance is offered to clients, to remediate failures by resource servers due to insufficient authorization details. This document addresses this interoperability challenge, allowing clients to dynamically discover metadata instead of relying on out- of-band agreements, as well as standardizes failure signaling including interoperable remediation when insufficient authorization details are the cause of failure. | |||||||||||||
| draft-ietf-oauth-refresh-token-expiration-03.txt | ||||||||||||||
| OAuth 2.0 Refresh Token and Authorization Expiration | ||||||||||||||
|
This specification extends OAuth 2.0 [RFC6749] by adding new token endpoint response parameters to specify refresh token expiration and user authorization expiration. | |||||||||||||
| draft-ietf-oauth-rfc7523bis-11.txt | ||||||||||||||
| Updates to OAuth 2.0 JSON Web Token (JWT) Client Authentication and Assertion-Based Authorization Grants | ||||||||||||||
|
This document updates RFC7521, RFC7522, RFC7523 and RFC9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications. | |||||||||||||
| draft-ietf-oauth-rfc8725bis-10.txt | ||||||||||||||
| JSON Web Token Best Current Practices | ||||||||||||||
|
JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices (BCP) specification updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. This BCP specification furthermore obsoletes RFC 8725 to provide additional actionable guidance covering threats and attacks that have been discovered since RFC 8725 was published. | |||||||||||||
| draft-ietf-oauth-sd-jwt-vc-19.txt | ||||||||||||||
| SD-JWT-based Verifiable Digital Credentials (SD-JWT VC) | ||||||||||||||
|
This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. | |||||||||||||
| draft-ietf-oauth-security-topics-update-03.txt | ||||||||||||||
| Updates to OAuth 2.0 Security Best Current Practice | ||||||||||||||
|
This document updates the set of best current security practices for OAuth 2.0 by extending the security advice given in RFC 6749, RFC 6750, and RFC 9700, to cover new threats that have been discovered since the former documents have been published. | |||||||||||||
| draft-ietf-oauth-spiffe-client-auth-02.txt | ||||||||||||||
| OAuth SPIFFE Client Authentication | ||||||||||||||
|
This specification profiles the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants [RFC7521], the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants [RFC7523], and OAuth 2.0 Attestation-Based Client Authentication [I-D.draft-ietf-oauth-attestation-based-client-auth] to enable the use of SPIFFE Verifiable Identity Documents (SVIDs) as client credentials in OAuth 2.0. It defines how OAuth clients with SPIFFE credentials can authenticate to OAuth authorization servers using their JWT-SVIDs, WIT-SVIDs, or X.509-SVIDs without the need for client secrets. This approach enhances security by enabling seamless integration between SPIFFE-enabled workloads and OAuth authorization servers while eliminating the need to distribute and manage shared secrets such as static client secrets. | |||||||||||||
| draft-ietf-oauth-status-list-21.txt | ||||||||||||||
| Token Status List (TSL) | ||||||||||||||
|
This specification defines a status mechanism called Token Status List (TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT, CBOR Web Token, and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. | |||||||||||||
| draft-ietf-oauth-transaction-tokens-11.txt | ||||||||||||||
| Transaction Tokens | ||||||||||||||
|
Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. | |||||||||||||
| draft-ietf-oauth-v2-1-16.txt | ||||||||||||||
| The OAuth 2.1 Authorization Framework | ||||||||||||||
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. | |||||||||||||
| draft-ietf-ocm-integration-protocol-00.txt | ||||||||||||||
| Open Cloud Mesh Integration Protocol | ||||||||||||||
|
The Open Cloud Mesh Integration Protocol (OCM-IP) defines how an Open Cloud Mesh (OCM) Server can integrate supporting servers, such as SSH/SFTP servers, web application platforms, or stand-alone WebDAV servers, to perform protocol-specific work on its behalf. OCM-IP makes it possible for existing OCM Servers to offload protocol specific interactions to stand-alone servers, or even implement OCM as a lightweight server that handles only the OCM parts of a deployment: discovery, share creation, token issuance and signing. Anything protocol-specific, such as serving files over WebDAV, providing SSH access, or running an interactive web application, can be handed off to one or more Protocol Servers running elsewhere, possibly operated with different software and on different infrastructure. OCM-IP defines three integration modes: a provisioned mode, in which the OCM Server pushes Share information to the Protocol Server over a signed back channel; a self-contained mode, in which the Share information is embedded in the signed access token itself, so that the Protocol Server needs no per-share state and no inbound API at all; and an introspected mode, in which the Protocol Server validates presented credentials through a token introspection endpoint, restoring compatibility with Receiving Servers that do not support token exchange. OCM-IP is a protocol between the Sending OCM Server and its Protocol Servers only. The Receiving Server is not involved in, and does not need to be aware of, this protocol: everything it observes is indistinguishable from the Sending Server serving the access protocols itself. For this reason, an OCM Sending Server MAY adopt a different strategy to interoperate with Protocol Servers, including e.g. establishing trust via shared keys, without compromising compliance with the OCM protocol. | |||||||||||||
| draft-ietf-ocm-mls-federated-groups-00.txt | ||||||||||||||
| Federated Groups in Open Cloud Mesh using Messaging Layer Security | ||||||||||||||
|
This document defines an extension to the Open Cloud Mesh (OCM) protocol to support federated groups as Receiving Parties of shares. This is achieved using the Messaging Layer Security (MLS) protocol (RFC 9420) as a group management layer. MLS is used for establishing and rotating a shared group key across federated group members, as well as for maintaining group state. This gives not only a way of federating group membership, but also a standardized way of distributing encryption keys in a cryptographically secure way, so that files shared with a group can optionally be encrypted and decrypted. MLS usage in OCM acts as a vehicle for group management that gives users optional encryption capabilities for resources shared with federated groups. | |||||||||||||
| draft-ietf-ocm-open-cloud-mesh-07.txt | ||||||||||||||
| Open Cloud Mesh | ||||||||||||||
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. | |||||||||||||
| draft-ietf-ohai-chunked-ohttp-08.txt | ||||||||||||||
| Chunked Oblivious HTTP Messages | ||||||||||||||
|
This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. | |||||||||||||
| draft-ietf-openpgp-hkp-01.txt | ||||||||||||||
| OpenPGP HTTP Keyserver Protocol | ||||||||||||||
|
This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. | |||||||||||||
| draft-ietf-openpgp-nist-bp-comp-04.txt | ||||||||||||||
| PQ/T Composite Schemes for OpenPGP using NIST and Brainpool Elliptic Curve Domain Parameters | ||||||||||||||
|
This document defines PQ/T ("post-quantum/traditional") composite schemes based on ML-KEM and ML-DSA combined with ECDH and ECDSA algorithms using the NIST and Brainpool domain parameters for the OpenPGP protocol [RFC9580], and as such extends [RFC9980]. | |||||||||||||
| draft-ietf-openpgp-persistent-symmetric-keys-04.txt | ||||||||||||||
| Persistent Symmetric Keys in OpenPGP | ||||||||||||||
|
This document defines a new packet and algorithm for the OpenPGP standard (RFC 9580) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for message authentication using AEAD authentication tags. This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. | |||||||||||||
| draft-ietf-openpgp-replacementkey-08.txt | ||||||||||||||
| OpenPGP Key Replacement | ||||||||||||||
|
This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. | |||||||||||||
| draft-ietf-opsawg-collected-data-manifest-15.txt | ||||||||||||||
| A Data Manifest for Contextualized Telemetry Data | ||||||||||||||
|
Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. | |||||||||||||
| draft-ietf-opsawg-discardmodel-16.txt | ||||||||||||||
| Information and Data Models for Packet Discard Reporting | ||||||||||||||
|
This document defines an Information Model and specifies a corresponding YANG data model for packet discard reporting. The Information Model provides an implementation-independent framework for classifying packet loss by its cause (e.g., errors, congestion, or policy). This classification enables operators to determine which losses are expected or intended and which are unintended, and to select appropriate mitigation actions, including automated mitigation of unintended packet loss. The YANG data model specifies an implementation of this Information Model for network elements with a focus on interface, device, and control-plane discards. | |||||||||||||
| draft-ietf-opsawg-ipfix-alt-mark-08.txt | ||||||||||||||
| IP Flow Information Export (IPFIX) Alternate-Marking Information Elements | ||||||||||||||
|
This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data. | |||||||||||||
| draft-ietf-opsawg-ipfix-gpon-gem-03.txt | ||||||||||||||
| Export of Gigabit Passive Optical Network Encapsulation Mode in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of G-PON Encapsulation Method entities in the Passive Optical Transport of the Optical Distribution Network. | |||||||||||||
| draft-ietf-opsawg-ipfix-gtpu-18.txt | ||||||||||||||
| Export of GTP-U Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol (GTP) User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. | |||||||||||||
| draft-ietf-opsawg-ipfix-path-segment-06.txt | ||||||||||||||
| Export of Segment Routing Path Segment Identifier (PSID) Information in IPFIX | ||||||||||||||
|
This document introduces new IPFIX Information Elements to identify the Segment Routing (SR) Path Segment Identifier (PSID) for SR-MPLS and SRv6 paths identification. | |||||||||||||
| draft-ietf-opsawg-ipfix-quic-header-00.txt | ||||||||||||||
| Export of QUIC Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information, which contained in QUIC Header, QUIC Frame and Stream that traffic is being forwarded along with. | |||||||||||||
| draft-ietf-opsawg-pcap-08.txt | ||||||||||||||
| PCAP Capture File Format | ||||||||||||||
|
This document describes the format used by the libpcap library to record captured packets to a file. Programs using the libpcap library to read and write those files, and thus reading and writing files in that format, include tcpdump. | |||||||||||||
| draft-ietf-opsawg-pcaplinktype-18.txt | ||||||||||||||
| Link-Layer Types for PCAP-related Capture File Formats | ||||||||||||||
|
This document describes a set of Packet CAPture (PCAP)-related LinkType values and creates an IANA registry for those values. These values are used by the PCAP and PCAP-Now-Generic specifications. | |||||||||||||
| draft-ietf-opsawg-rfc5706bis-07.txt | ||||||||||||||
| Guidelines for Considering Operations and Management in IETF Specifications | ||||||||||||||
|
New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that document a specification for New Protocols or Protocol Extensions or describe their use. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. | |||||||||||||
| draft-ietf-opsawg-scheduling-oam-tests-09.txt | ||||||||||||||
| A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests | ||||||||||||||
|
This document defines two YANG data models to support scheduled network diagnosis using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam- test-sequence' YANG modules to manage the lifecycle of network diagnosis procedures, intended for use by external management and orchestration systems (including SDN controllers and network orchestrators), rather than by individual network nodes. | |||||||||||||
| draft-ietf-opsawg-ucl-acl-15.txt | ||||||||||||||
| A YANG Data Model and RADIUS Extension for Policy-Based Network Access Control | ||||||||||||||
|
This document defines a YANG data model for policy-based network access control, which provides enforcement of network access control policies based on group identity. This YANG data model extends Access Control Lists (ACLs) with date and time parameters to support schedule-aware policy enforcement. Specifically in scenarios where network access is triggered by user authentication, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of packet header fields to enforce policy-based network access control. Moreover, the document defines a Remote Authentication Dial-in User Service (RADIUS) attribute that is used to communicate the user group identifier as part of identification and authorization information. | |||||||||||||
| draft-ietf-opsawg-veloce-yang-00.txt | ||||||||||||||
| YANG deVELpment PrOCEss and maintenance (VELOCE) | ||||||||||||||
|
This document describes a YANG deVELpment PrOCEss and maintenance (VELOCE) that is more suitable for the development of YANG modules or YANG modules update within the IETF. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mjethanandani/veloce. | |||||||||||||
| draft-ietf-opsawg-yang-provenance-07.txt | ||||||||||||||
| Applying COSE Signatures for YANG Data Provenance | ||||||||||||||
|
This document defines a mechanism based on CBOR Object Signing and Encryption (COSE) signatures to provide and verify the provenance of YANG data, so it is possible to verify the origin and integrity of a dataset, even when those data are going to be processed and/or applied in workflows where a crypto-enabled data transport directly from the original data source is not available. As the application of evidence-based OAM automation and the use of tools such as AI/ML grow, provenance validation becomes more relevant in all scenarios, in support of the assuring the origin and integrity of data. The use of compact signatures facilitates the inclusion of provenance strings in any YANG schema requiring them. | |||||||||||||
| draft-ietf-pce-circuit-style-pcep-extensions-16.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) extensions for Circuit Style Policies | ||||||||||||||
|
Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy can consist of one or a set of candidate paths, where each candidate path is represented by a segment list or a set of segment lists, which are essentially instructions that define a source-routed path. This document specifies a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path modification and the option to request a strict hop-by-hop path, being also applicable for generic SR policy use cases where controlling path modification or deterministic and persistent path requirements are applicable. | |||||||||||||
| draft-ietf-pce-controlled-id-space-05.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) extension to advertise the PCE Controlled Identifier Space | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC provisioning or Binding Segment Identifier (SID) for Segment Routing (SR) allocation, there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE to be aware of various identifier spaces from where to make allocations on behalf of a PCC. This document defines a generic mechanism by which a PCC can inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other identifier that can be allocated and managed by the PCE. | |||||||||||||
| draft-ietf-pce-entropy-label-position-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-pce-flexible-grid-19.txt | ||||||||||||||
| PCEP Extension for Flexible Grid Networks | ||||||||||||||
|
This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. | |||||||||||||
| draft-ietf-pce-multipath-29.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information | ||||||||||||||
|
This document defines Path Computation Element Communication Protocol (PCEP) extensions to signal multipath information, associating multiple forwarding paths with a single PCEP Label Switched Path (LSP) to allow load-balancing and redundancy across diverse paths. The extensions are generic and applicable to both stateless and stateful PCEP, and are designed to be reusable for future path types. Their primary application is Segment Routing (SR) Policy, where a Candidate Path can contain multiple Segment Lists: current PCEP extensions for SR Policy only allow signaling of a single Segment List per Candidate Path. These extensions enable multipath capabilities such as weighted or equal-cost load-balancing across paths. | |||||||||||||
| draft-ietf-pce-operational-03.txt | ||||||||||||||
| PCEP Operational Clarification | ||||||||||||||
|
This document clarifies certain operational behavior aspects of the Path Computation Element Communication Protocol (PCEP). The content of this document has been compiled based on several interop exercises. This document does not make any updates or revisions to any PCEP specifications, instead it provides additional information to aid in the interpretation of those documents. | |||||||||||||
| draft-ietf-pce-pcep-extension-pce-controller-sr-14.txt | ||||||||||||||
| PCE Communication Protocol (PCEP) Extensions for Using PCE as a Central Controller (PCECC) for Segment Routing (SR) MPLS Segment Identifier (SID) Allocation and Distribution | ||||||||||||||
|
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. A PCE-based Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the Label Switched Path (LSP) can be calculated/set up/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCE Communication Protocol (PCEP) extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a segment routing (SR) network and telling the edge routers what instructions to attach to packets as they enter the network. PCECC as defined in RFC 9050 is further enhanced for SR-MPLS SID (Segment Identifier) allocation and distribution. | |||||||||||||
| draft-ietf-pce-pcep-ifit-09.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions to Enable IFIT | ||||||||||||||
|
In-situ Flow Information Telemetry (IFIT) refers to network OAM data plane on-path telemetry techniques, in particular In-situ OAM (IOAM) and Alternate Marking. This document defines PCEP extensions to allow a Path Computation Client (PCC) to indicate which IFIT features it supports, and a Path Computation Element (PCE) to configure IFIT behavior at a PCC for a specific path in the stateful PCE model. The application to Segment Routing (SR) is reported. However, the PCEP extensions described in this document can be generalized for all path types, but that is out of scope of this document. | |||||||||||||
| draft-ietf-pce-pcep-l2-flowspec-10.txt | ||||||||||||||
| PCEP Extension for Layer 2 (L2) Flow Specification | ||||||||||||||
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path. Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. This document updates RFC 9168 by updating the assignment policies for a range of Flow Specification TLV Type Indicators. The extensions defined in this document extend the support for Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with Layer 3 (L3) flowspecs. | |||||||||||||
| draft-ietf-pce-pcep-ls-07.txt | ||||||||||||||
| PCEP extensions for Distribution of Link-State and TE Information | ||||||||||||||
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link state (LS) routing protocol supporting the traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information as an experimental extension to allow gathering more deployment and implementation feedback on the use of PCEP in this way. | |||||||||||||
| draft-ietf-pce-pcep-ls-optical-00.txt | ||||||||||||||
| PCEP Extensions for Distribution of Link-State and TE Information for Optical Networks | ||||||||||||||
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions. Link-State (LS) and Traffic Engineering (TE) information can also be carried in the Path Computation Element Communication Protocol (PCEP) using experimental exensions to PCEP known as Link-State PCEP (PCEP- LS). This document provides further experimental extensions to collect Link-State and TE information for optical networks. | |||||||||||||
| draft-ietf-pce-pcep-nrp-01.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Network Resource Partition (NRP) | ||||||||||||||
|
This document specifies the extensions to Path Computation Element Communication Protocol (PCEP) to carry Network Resource Partition (NRP) related information in the PCEP messages. The extensions in this document can be used to indicate the NRP-specific constraints and information needed in path computation, path status report and path initialization. | |||||||||||||
| draft-ietf-pce-pcep-pmtu-10.txt | ||||||||||||||
| Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. | |||||||||||||
| draft-ietf-pce-pcep-srv6-yang-09.txt | ||||||||||||||
| A YANG Data Model for Segment Routing (SR) Policy and SR in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP) | ||||||||||||||
|
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). | |||||||||||||
| draft-ietf-pce-sr-bidir-path-25.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs | ||||||||||||||
|
Segment Routing (SR) steers packets through a network using the IPv6 or MPLS data planes via source routing. Stateful Path Computation Element Communication Protocol (PCEP) extensions are defined for SR Traffic Engineering (TE) LSPs. PCEP supports grouping two RSVP-TE signaled, unidirectional MPLS-TE Label-Switched Paths (LSPs) with one in each direction in a network into an associated bidirectional LSP. This document extends PCEP support to group two unidirectional SR LSPs into an associated bidirectional SR LSP. The mechanisms defined in this document apply to both stateless and stateful PCEs for PCE-initiated and PCC- initiated LSPs. | |||||||||||||
| draft-ietf-pce-sr-p2mp-policy-21.txt | ||||||||||||||
| PCEP extensions for SR P2MP Policy | ||||||||||||||
|
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable an architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths for SR-MPLS from a Root to a set of Leaf nodes. | |||||||||||||
| draft-ietf-pce-sr-path-segment-15.txt | ||||||||||||||
| Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) | ||||||||||||||
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. | |||||||||||||
| draft-ietf-pce-state-sync-15.txt | ||||||||||||||
| Procedures for Communication between Stateful Path Computation Elements | ||||||||||||||
|
The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions toward multiple PCEs. In some use cases, inter-PCE stateful communication can bring additional resiliency in the design, for instance, when some PCC-PCE session fails. This document describes the procedures to allow stateful communication between PCEs for various use cases, and also the procedures to prevent computational loops. | |||||||||||||
| draft-ietf-pce-stateful-pce-autobw-update-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-pce-topology-filter-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-pim-evpn-multicast-yang-06.txt | ||||||||||||||
| Yang Data Model for EVPN multicast | ||||||||||||||
|
This document describes a YANG data model for EVPN multicast services. The model is agnostic of the underlay as well as RFC 9251. This document mainly focuses on EVPN instance framework. | |||||||||||||
| draft-ietf-pim-flex-algo-01.txt | ||||||||||||||
| Multi-Topology in PIM | ||||||||||||||
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. | |||||||||||||
| draft-ietf-pim-gaap-24.txt | ||||||||||||||
| Group Address Allocation Protocol (GAAP) | ||||||||||||||
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). GAAP requires no centralized service or coordination for the address-allocation protocol itself, though it depends on ASM-capable multicast routing already being provisioned in the deployment domain, and deployments using encryption or administrative scoping may require additional configuration. The protocol runs among group participants which need a unique group address to send and receive multicast packets. Tailored for IPv4 and IPv6 networks, this design offers a simple, lightweight option rather than extending an existing protocol. This document is Experimental, see Section 8 for the rationale and the criteria for concluding the experiment. | |||||||||||||
| draft-ietf-pim-igmp-mld-snooping-yang-l2vpn-ext-09.txt | ||||||||||||||
| IGMP and MLD Snooping Yang Module Extension for L2VPN | ||||||||||||||
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. | |||||||||||||
| draft-ietf-pim-ipv6-zeroconf-assignment-11.txt | ||||||||||||||
| Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS | ||||||||||||||
|
This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new "eth-addr.arpa" domain. This protocol satisfies all of the criteria listed in RFC 10019. | |||||||||||||
| draft-ietf-pim-multicast-lessons-learned-09.txt | ||||||||||||||
| Multicast Lessons Learned from Decades of Deployment Experience | ||||||||||||||
|
This document gives a historical perspective about the design and deployment of multicast routing protocols. The document describes the technical challenges discovered from building these protocols. Even though multicast has enjoyed success of deployment in special use-cases, this draft discusses what were, and are, the obstacles for mass deployment across the Internet. Individuals who are working on new multicast related protocols will benefit by knowing why certain older protocols are no longer in use today. | |||||||||||||
| draft-ietf-pim-multipath-igmpmldproxy-04.txt | ||||||||||||||
| Multipath Support for IGMP/MLD Proxy | ||||||||||||||
|
This document specifies the framework to support multipath reception in Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD) proxy devices. The proposed mechanism allows IGMP/ MLD proxy devices to receive multicast sessions/channels through different upstream interfaces. It defines static configuration methods for associating upstream interfaces with channel identifiers and interface priority values. A mechanism for upstream interface takeover that enables switching from an inactive to active upstream interface is also described. | |||||||||||||
| draft-ietf-pim-pfm-forwarding-enhancements-08.txt | ||||||||||||||
| PIM Flooding Mechanism and Source Discovery Enhancements | ||||||||||||||
|
The Protocol Independent Multicast (PIM) Flooding Mechanism (PFM) is an experimental extension that provides a generic hop-by-hop message exchange framework for distributing multicast information among PIM routers. Existing PFM procedures enable efficient source discovery without reliance on Rendezvous Points, shared trees, or initial data registers. This document specifies further experimental enhancements to PFM forwarding behavior to improve efficiency and scalability. In particular, it introduces mechanisms to reduce redundant message transmission over multiple parallel links and extends the encoding of multicast information through additional Type-Length-Value (TLV) structures and sub-TLVs to convey richer flow-related data. These enhancements optimize control-plane overhead while preserving interoperability with existing PFM procedures, enabling more efficient dissemination of multicast state in PIM networks. | |||||||||||||
| draft-ietf-pim-rfc1112bis-09.txt | ||||||||||||||
| Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service | ||||||||||||||
|
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support IP multicast with the IP service interface "Any Source Multicast" (ASM). This specification applies to both versions 4 and 6 of the Internet Protocol. Distribution of this memo is unlimited. This document replaces RFC1112 for everything but its specification of the IGMP version 1 protocol. | |||||||||||||
| draft-ietf-pim-rfc8059-9798bis-02.txt | ||||||||||||||
| PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments | ||||||||||||||
|
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport, to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router) and to signal the underlay multicast group to the control plane of the root ITR. This document updates RFC 8059 and RFC 9798. | |||||||||||||
| draft-ietf-plants-merkle-tree-certs-05.txt | ||||||||||||||
| Merkle Tree Certificates | ||||||||||||||
|
This document describes Merkle Tree certificates, a new form of X.509 certificates which integrate public logging of the certificate, in the style of Certificate Transparency. The integrated design reduces logging overhead in the face of both shorter-lived certificates and large post-quantum signature algorithms, while still achieving comparable security properties to existing X.509 constructions and Certificate Transparency. Merkle Tree certificates additionally admit an optional size optimization that avoids signatures altogether, at the cost of only applying to up-to-date relying parties and older certificates. | |||||||||||||
| draft-ietf-ppm-dap-19.txt | ||||||||||||||
| Distributed Aggregation Protocol for Privacy Preserving Measurement | ||||||||||||||
|
There are many situations in which it is desirable to take measurements of data which people consider sensitive. In these cases, the entity taking the measurement is usually not interested in people's individual responses but rather in aggregated data. Conventional methods require collecting individual responses and then aggregating them on some server, thus representing a threat to user privacy and rendering many such measurements difficult and impractical. This document describes a multi-party Distributed Aggregation Protocol (DAP) for privacy preserving measurement which can be used to collect aggregate data without revealing any individual contributor's data. | |||||||||||||
| draft-ietf-ppm-l1-bound-sum-02.txt | ||||||||||||||
| A Prio Instantiation for Vector Sums with an L1 Norm Bound on Contributions | ||||||||||||||
|
A Prio Verifiable Distributed Aggregation Function is defined that supports vector or histogram addition, where the sum of the values in the contribution is less than a chosen value. | |||||||||||||
| draft-ietf-pquip-pqc-hsm-constrained-06.txt | ||||||||||||||
| Adapting Constrained Devices for Post-Quantum Cryptography | ||||||||||||||
|
This document provides guidance on integrating Post-Quantum Cryptography (PQC) into resource-constrained devices, such as IoT nodes and lightweight Hardware Security Modules (HSMs). These systems often operate with strict limitations on processing power, RAM, and flash memory, and may even be battery-powered. The document emphasizes the role of hardware security as the basis for secure operations, supporting features such as seed-based key generation to minimize persistent storage, efficient handling of ephemeral keys, and the offloading of cryptographic tasks in low-resource environments. It also explores the implications of PQC on firmware update mechanisms in such constrained systems. | |||||||||||||
| draft-ietf-privacypass-auth-scheme-extensions-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-privacypass-batched-tokens-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-privacypass-expiration-extension-00.txt | ||||||||||||||
| Privacy Pass Token Expiration Extension | ||||||||||||||
|
This document describes an extension for Privacy Pass that allows tokens to encode expiration information. | |||||||||||||
| draft-ietf-privacypass-public-metadata-issuance-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-procon-2026bis-11.txt | ||||||||||||||
| The Internet Standards Process | ||||||||||||||
|
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages, and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. | |||||||||||||
| draft-ietf-procon-2418bis-04.txt | ||||||||||||||
| IETF Working Group Guidelines and Procedures | ||||||||||||||
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [_2026bis], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. | |||||||||||||
| draft-ietf-quic-address-discovery-01.txt | ||||||||||||||
| QUIC Address Discovery | ||||||||||||||
|
Unless they have out-of-band knowledge, QUIC endpoints have no information about their network situation. They neither know their external IP address and port, nor do they know if they are directly connected to the internet or if they are behind a NAT. This QUIC extension allows nodes to determine their reflexive IP address and port for any QUIC path. | |||||||||||||
| draft-ietf-quic-extended-key-update-03.txt | ||||||||||||||
| Extended Key Update for QUIC | ||||||||||||||
|
This document specifies an Extended Key Update mechanism for the QUIC protocol, building on the foundation of the TLS Extended Key Update. The TLS Extended Key Update specification enhances the TLS protocol by introducing key updates with forward secrecy, eliminating the need to perform a full handshake. This feature is particularly beneficial for maintaining security in scenarios involving long-lived connections. This specification replaces the QUIC Key Update mechanism described in the "Using TLS to Secure QUIC" specification. | |||||||||||||
| draft-ietf-quic-multipath-21.txt | ||||||||||||||
| Managing multiple paths for a QUIC connection | ||||||||||||||
|
This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. It introduces explicit path identifiers to create, delete, and manage multiple paths. This document does not specify address discovery or management, nor how applications using QUIC schedule traffic over multiple paths. | |||||||||||||
| draft-ietf-quic-qlog-h3-events-13.txt | ||||||||||||||
| HTTP/3 qlog event definitions | ||||||||||||||
|
This document defines qlog event schemas containing concrete events for the core HTTP/3 protocol and selected extensions. It also defines an http namespace for the Capsule Protocol. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| draft-ietf-quic-qlog-main-schema-14.txt | ||||||||||||||
| qlog: Structured Logging for Network Protocols | ||||||||||||||
|
qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| draft-ietf-quic-qlog-quic-events-13.txt | ||||||||||||||
| QUIC event definitions for qlog | ||||||||||||||
|
This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. | |||||||||||||
| draft-ietf-quic-qmux-02.txt | ||||||||||||||
| QMux | ||||||||||||||
|
This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/qmux. | |||||||||||||
| draft-ietf-quic-receive-ts-03.txt | ||||||||||||||
| QUIC Extended Acknowledgement for Reporting Packet Receive Timestamps | ||||||||||||||
|
This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps for post- handshake packets. | |||||||||||||
| draft-ietf-quic-reliable-stream-reset-11.txt | ||||||||||||||
| QUIC Stream Resets with Partial Delivery | ||||||||||||||
|
QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. | |||||||||||||
| draft-ietf-radext-deprecating-radius-10.txt | ||||||||||||||
| Deprecating Insecure Practices in RADIUS | ||||||||||||||
|
RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks, and have recently been standardized in [I-D.ietf-radext-radiusdtls-bis]. TLS has proven to be a useful replacment for UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. Related security issues with RADIUS are discussed, and recommendations are made for practices which increase both security and privacy. | |||||||||||||
| draft-ietf-radext-radiusdtls-bis-17.txt | ||||||||||||||
| RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) | ||||||||||||||
|
This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS. | |||||||||||||
| draft-ietf-radext-reverse-coa-08.txt | ||||||||||||||
| Reverse Change-of-Authorization (CoA) in RADIUS/(D)TLS | ||||||||||||||
|
This document defines a "reverse Change-of-Authorization (CoA)" path for RADIUS packets. A TLS connection is normally used to forward request packets from a client to a server and to send responses from the server to the client. This specification allows a server to send CoA request packets to the client in "reverse" down that connection, and for the client to send responses to the server. Without this capability, it is in general impossible for a server to send CoA packets to a Network Access Server (NAS) that is located behind a firewall or NAT. This reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled. This document updates RFC8559. | |||||||||||||
| draft-ietf-radext-review-radius-02.txt | ||||||||||||||
| A Review of RADIUS Security and Privacy | ||||||||||||||
|
This document provides a comprehensive review of security issues related to the RADIUS Protocol. This review motivates the changes to RADIUS security which are made in [I-D.ietf-radext-deprecating-radius]. | |||||||||||||
| draft-ietf-rats-ar4si-10.txt | ||||||||||||||
| Attestation Results for Secure Interactions | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-rats-concise-ta-stores-03.txt | ||||||||||||||
| Concise TA Stores (CoTS) | ||||||||||||||
|
Trust anchor (TA) stores may be used for several purposes in the Remote Attestation Procedures (RATS) architecture including verifying endorsements, reference values, digital letters of approval, attestations, or public key certificates. This document describes a Concise Reference Integrity Manifest (CoRIM) extension that may be used to convey optionally constrained trust anchor stores containing optionally constrained trust anchors in support of these purposes. | |||||||||||||
| draft-ietf-rats-corim-11.txt | ||||||||||||||
| Concise Reference Integrity Manifest | ||||||||||||||
|
Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. | |||||||||||||
| draft-ietf-rats-coserv-07.txt | ||||||||||||||
| Concise Selector for Endorsements and Reference Values | ||||||||||||||
|
In the Remote Attestation Procedures (RATS) architecture, Verifiers require Endorsements and Reference Values to assess the trustworthiness of Attesters. This document specifies the Concise Selector for Endorsements and Reference Values (CoSERV), a structured query/result format designed to facilitate the discovery and retrieval of these artifacts from various providers. CoSERV defines a query language and corresponding result structure using CDDL, which can be serialized in CBOR format, enabling efficient interoperability across diverse systems. | |||||||||||||
| draft-ietf-rats-ear-04.txt | ||||||||||||||
| EAT Attestation Results | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-rats-endorsements-10.txt | ||||||||||||||
| RATS Endorsements | ||||||||||||||
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and uses Appraisal Policy for Evidence, typically with additional input from Endorsements and Reference Values, to generate Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. | |||||||||||||
| draft-ietf-rats-epoch-markers-05.txt | ||||||||||||||
| Epoch Markers | ||||||||||||||
|
This document defines Epoch Markers as a means to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. | |||||||||||||
| draft-ietf-rats-multi-verifier-00.txt | ||||||||||||||
| Remote Attestation with Multiple Verifiers | ||||||||||||||
|
IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. | |||||||||||||
| draft-ietf-rats-network-device-subscription-13.txt | ||||||||||||||
| Attestation Event Stream Subscription | ||||||||||||||
|
This document defines how to subscribe to YANG Event Streams for Remote Attestation Procedures (RATS). Specifically, this document defines a YANG module that augments the YANG module for Trusted Platform Module (TPM)-based Challenge-Response Remote Attestation (CHARRA), enabling subscription to RATS Conceptual Messages of the Evidence type and auxiliary Event Logs as part of that Evidence. The module defined requires at least one Trusted Platform Module (TPM) 1.2 or TPM 2.0 (or equivalent hardware implementation providing the same protected capabilities as a TPM) must be available on the Attester on which the YANG server is running. | |||||||||||||
| draft-ietf-rats-pkix-key-attestation-07.txt | ||||||||||||||
| Evidence Encoding for Hardware Security Modules | ||||||||||||||
|
This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce Evidence tailored for expected use. | |||||||||||||
| draft-ietf-rats-posture-assessment-04.txt | ||||||||||||||
| Remote Posture Assessment for Systems,Containers,and Applications at Scale | ||||||||||||||
|
This document establishes an architectural pattern whereby Attestation Results could be produced for a complete set of benchmarks or controls that are defined and grouped by an external entity, eliminating the need to convey individual Evidence items for each item within a benchmark or control framework. This document establishes a pattern to list sets of benchmarks and controls within CWT and JWT formats for use as an Entity Attestation Token (EAT). While the discussion below pertains mostly to TPM, other Roots of Trust such as TCG DICE and non-TCG defined components will also be included. | |||||||||||||
| draft-ietf-rats-reference-interaction-models-18.txt | ||||||||||||||
| Reference Interaction Models for Remote Attestation Procedures | ||||||||||||||
|
This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. | |||||||||||||
| draft-ietf-regext-balance-02.txt | ||||||||||||||
| Balance Mapping for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for retrieving the client balance and other financial information. | |||||||||||||
| draft-ietf-regext-epp-https-05.txt | ||||||||||||||
| Extensible Provisioning Protocol (EPP) Transport over HTTPS | ||||||||||||||
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto the Hypertext Transfer Protocol (HTTP). EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). | |||||||||||||
| draft-ietf-regext-epp-quic-12.txt | ||||||||||||||
| Extensible Provisioning Protocol (EPP) Transport over QUIC | ||||||||||||||
|
This document specifies how an Extensible Provisioning Protocol (EPP) session is mapped onto a QUIC connection. EPP over QUIC (EoQ) leverages features of the QUIC protocol. | |||||||||||||
| draft-ietf-regext-epp-same-entity-01.txt | ||||||||||||||
| Same Entity Set Support for EPP | ||||||||||||||
|
This document defines an EPP extension allowing clients to learn about and manipulate a set of objects in a shared central repository that are necessarily tied to the same entity (typically domain objects whose names are equivalent in a registry-defined way and are tied to a single registrant). The extension supports multiple registries with a shared definition of equivalence using a shared central repository. | |||||||||||||
| draft-ietf-regext-ext-registry-epp-10.txt | ||||||||||||||
| Extension Registry for the Extensible Provisioning Protocol | ||||||||||||||
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are maintained. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. If approved, this document obsoletes RFC 7451. | |||||||||||||
| draft-ietf-regext-rdap-extensions-15.txt | ||||||||||||||
| RDAP Extensions | ||||||||||||||
|
This document describes and clarifies the usage of extensions in RDAP. | |||||||||||||
| draft-ietf-regext-rdap-jscontact-26.txt | ||||||||||||||
| Using JSContact in Registration Data Access Protocol (RDAP) JSON Responses | ||||||||||||||
|
This document describes an RDAP extension which represents entity contact information in JSON responses using JSContact. | |||||||||||||
| draft-ietf-regext-rdap-referrals-04.txt | ||||||||||||||
| Explicit RDAP Redirects | ||||||||||||||
|
This document describes an RDAP extension that allows RDAP clients to request to be redirected to a related RDAP record for a resource. | |||||||||||||
| draft-ietf-regext-rdap-rpki-04.txt | ||||||||||||||
| Registration Data Access Protocol (RDAP) Extension for Resource Public Key Infrastructure (RPKI) Registration Data | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) is used to secure inter-domain routing on the internet. This document defines a new Registration Data Access Protocol (RDAP) extension with identifier "rpki1", for accessing the RPKI registration data in the Internet Number Registry System (INRS) for the Route Origin Authorization (ROA), Autonomous System Provider Authorization (ASPA), and X.509 Resource Certificate RPKI profiles through RDAP. The INRS is composed of Regional Internet Registries (RIRs), National Internet Registries (NIRs), and Local Internet Registries (LIRs). | |||||||||||||
| draft-ietf-regext-rdap-versioning-07.txt | ||||||||||||||
| Versioning in the Registration Data Access Protocol (RDAP) | ||||||||||||||
|
This document describes an RDAP extension for an extensible set of versioning types with the features of identifying the RDAP extension versions supported by the server, the RDAP extension versions included in an RDAP response, and enabling a client to specify the desired RDAP extension versions to include in the RDAP query and RDAP response. In addition, this document defines a mechanism for communicating versioning and deprecation information that facilitates coordinated transitions between successive extension versions while minimizing the impact of breaking changes on deployed clients. | |||||||||||||
| draft-ietf-regext-rdap-x-media-type-06.txt | ||||||||||||||
| The "exts_list" Parameter for the RDAP Media Type | ||||||||||||||
|
This document defines a new parameter for the RDAP media type that can be used to describe RDAP content with RDAP extensions. Additionally, this document describes the usage of this parameter with RDAP for the purposes of signalling RDAP extensions during content negotiation. | |||||||||||||
| draft-ietf-regext-rfc3915bis-00.txt | ||||||||||||||
| Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) [RFC5730] extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies. Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. This mapping extends the EPP domain name mapping [RFC5731] to provide additional features required for grace period processing. This document replaces the extension mapping for grace periods described in [RFC3915], rendering that document obsolete. | |||||||||||||
| draft-ietf-rift-auto-evpn-07.txt | ||||||||||||||
| RIFT Auto-EVPN | ||||||||||||||
|
This document specifies procedures that allow an EVPN overlay to be fully and automatically provisioned when using RIFT as underlay by leveraging RIFT's no-touch ZTP architecture. | |||||||||||||
| draft-ietf-rift-sr-03.txt | ||||||||||||||
| SRIFT: Segment Routing in Fat Trees | ||||||||||||||
|
This document specifies signaling procedures for Segment Routing in RIFT. Each node's loopback address, Segment Routing Global Block (SRGB) and Node Segment Identifier (Node-SID), which are typically assigned by a configuration management system and distibuted by routing protocols, are distributed southbound from the Top Of Fabric (TOF) nodes via RIFT's Key-Value distribution mechanism, so that each node can compute how to reach a segment represented by the active SID in a packet. An SR controller signals SR policies to ingress nodes so that they can send packets with a desired segment list to steer traffic. | |||||||||||||
| draft-ietf-roll-dis-modifications-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-roll-enrollment-priority-18.txt | ||||||||||||||
| Controlling Network Enrollment in RPL networks | ||||||||||||||
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) manages the routing topology but lacks a mechanism to globally regulate how many new nodes, known as Pledges, can join a node in a 6TiSCH network at any given time. Currently, Join Proxies (6LowPAN Routers) make local decisions about whether to facilitate a Pledge's enrollment based only on their immediate resources. This document introduces RPL extensions to ensure that enrollment remains orderly, prevents localized congestion at specific Join Proxies, and allows the network to stay within its operational capacity limits. | |||||||||||||
| draft-ietf-roll-nsa-extension-14.txt | ||||||||||||||
| Common Ancestor Objective Function and Parent Set DAG Metric Container Extension | ||||||||||||||
|
High reliability and low jitter can be achieved by being able to send data packets through multiple paths, via different parents, in a network. This document details how to exchange the necessary information within RPL control packets to let a node better select the different parents that will be used to forward a packet over different paths. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. | |||||||||||||
| draft-ietf-rpp-core-00.txt | ||||||||||||||
| RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes the endpoints for the RESTful Provisioning Protocol, used for the provisioning and management of objects in a shared database. | |||||||||||||
| draft-ietf-rpp-data-objects-01.txt | ||||||||||||||
| RESTful Provisioning Protocol (RPP) Data Objects | ||||||||||||||
|
This document defines data objects for the RESTful Provisioning Protocol (RPP) and sets up the IANA RPP Data Object Registry to describe and catalogue them. Specifically, it details the logical structure, constraints, and protocol operations (including their inputs, outputs, and business logic) for foundational resources: domain names, contacts, and hosts. In accordance with the RPP architecture [I-D.kowalik-rpp-architecture], these definitions focus entirely on the semantics, remaining independent of any specific data representation or media type (e.g., JSON or XML). | |||||||||||||
| draft-ietf-rpp-json-00.txt | ||||||||||||||
| JSON for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document defines the rules for representing the RESTful Provisioning Protocol (RPP) data objects, as defined in [I-D.ietf-rpp-data-objects], using the JavaScript Object Notation (JSON) Data Interchange Format [RFC8259]. It specifies how RPP primitive types, common data types, component objects, resource objects, and associations are mapped to JSON and JSON Schema, and provides normative JSON Schema definitions and worked examples for domain name, contact, and host data objects. | |||||||||||||
| draft-ietf-rpp-requirements-04.txt | ||||||||||||||
| RESTful Provisioning Protocol (RPP) - Requirements | ||||||||||||||
|
This document describes the requirements for the development of the RESTful Provisioning Protocol (RPP). | |||||||||||||
| draft-ietf-rtgwg-atn-bgp-33.txt | ||||||||||||||
| A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network | ||||||||||||||
|
The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually augment existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on the industry-standard Border Gateway Protocol (BGP) and Domain Name System (DNS) to address the ATN/IPS requirements. | |||||||||||||
| draft-ietf-rtgwg-dst-src-routing-revive-06.txt | ||||||||||||||
| Destination/Source Routing | ||||||||||||||
|
This document specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. The proposed mechanism applies to IPv6 [RFC8200] in general with specific considerations for routing protocols. | |||||||||||||
| draft-ietf-rtgwg-multisegment-sdwan-16.txt | ||||||||||||||
| Multi-segment SD-WAN via Cloud Backbone | ||||||||||||||
|
This document describes a method for seamlessly interconnecting geographically separated SD-WAN segments via a Cloud Backbone without requiring Cloud Gateways (GWs) to decrypt and re-encrypt traffic. By encapsulating IPsec- encrypted payloads within GENEVE headers (RFC 8926), the approach enables Cloud GWs to forward encrypted traffic directly between distant Customer Premises Equipment (CPEs). This reduces processing overhead, improves scalability, and preserves the confidentiality of enterprise data while ensuring secure and efficient multi-segment SD-WAN connectivity. | |||||||||||||
| draft-ietf-rtgwg-net-notif-ps-02.txt | ||||||||||||||
| Fast Network Notifications Problem Statement | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-rtgwg-srv6-egress-protection-25.txt | ||||||||||||||
| SRv6 Path Egress Protection | ||||||||||||||
|
This document describes the mechanism and operational guidelines for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. Topology Independent Loop-Free Alternate (TI-LFA) specifies fast protections for transit nodes and links of an SR path, but does not present protections for the egress node. The solution uses a Mirror SID (End.M) behavior to steer traffic to a protector egress upon failure of the primary egress. The Interior Gateway Protocol (IGP) (IS-IS/OSPFv3) extensions used to advertise the Mirror SID and protected locators are specified in [I-D.he-lsr-srv6-mirror-sid-igp-encoding]; they build on the IS-IS and OSPFv3 SRv6 extensions defined in [RFC9352] and [RFC9513]. | |||||||||||||
| draft-ietf-rtgwg-vrrp-bfd-p2p-05.txt | ||||||||||||||
| Fast failure detection in VRRP with Point to Point BFD | ||||||||||||||
|
This document describes how Point to Point Bidirectional Forwarding Detection (BFD) can be used to support sub-second detection of a Active Router failure in the Virtual Router Redundancy Protocol (VRRP). | |||||||||||||
| draft-ietf-rtgwg-vrrp-p2mp-bfd-15.txt | ||||||||||||||
| Applicability of Bidirectional Forwarding Detection (BFD) for Multi-point Networks in Virtual Router Redundancy Protocol (VRRP) | ||||||||||||||
|
This document specifies the applicability of Bidirectional Forwarding Detection in multipoint networks to support sub-second failure detection for Virtual Router Redundancy Protocol Router Role election. The mechanism enables faster determination of the Active Router without requiring any modification to the protocol behavior or message formats defined in RFC 9568. | |||||||||||||
| draft-ietf-rtgwg-vrrp-rfc8347bis-23.txt | ||||||||||||||
| A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) | ||||||||||||||
|
This document specifies a YANG data model for the Virtual Router Redundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. The VRRP terminology has been updated to conform to inclusive language guidelines for IETF technologies. This document obsoletes RFC 8347. | |||||||||||||
| draft-ietf-satp-architecture-10.txt | ||||||||||||||
| Secure Asset Transfer (SAT) Interoperability Architecture | ||||||||||||||
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. | |||||||||||||
| draft-ietf-satp-core-16.txt | ||||||||||||||
| Secure Asset Transfer Protocol (SATP) Core | ||||||||||||||
|
This memo describes the Secure Asset Transfer Protocol (SATP) for digital assets. SATP is a protocol operating between two gateways that conducts the transfer of a digital asset from one gateway to another, each representing their corresponding digital asset networks. The protocol establishes a secure channel between the endpoints and implements a 2-phase commit (2PC) to ensure the properties of transfer atomicity, consistency, isolation and durability. | |||||||||||||
| draft-ietf-satp-usecases-10.txt | ||||||||||||||
| Secure Asset Transfer (SAT) Use Cases | ||||||||||||||
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. | |||||||||||||
| draft-ietf-savnet-general-sav-capabilities-03.txt | ||||||||||||||
| General Source Address Validation Capabilities | ||||||||||||||
|
The SAV rules of existing source address validation (SAV) mechanisms are derived from other core data structures (e.g., FIB-based uRPF) that are not dedicatedly designed for source filtering. Consequently, these mechanisms have limitations in deployable scenarios and traffic handling policies. To overcome these limitations, this document introduces general SAV capabilities from a data plane perspective. How to implement the capabilities and how to generate SAV rules are not in the scope of this document. | |||||||||||||
| draft-ietf-savnet-inter-domain-problem-statement-21.txt | ||||||||||||||
| Problem Statement,Gap Analysis,and Requirements for Inter-Domain Source Address Validation | ||||||||||||||
|
This document analyzes the problem space and provides a gap analysis of existing inter-domain source address validation (SAV) mechanisms. Based on these findings, it outlines the technical requirements for future improvements. | |||||||||||||
| draft-ietf-savnet-intra-domain-architecture-04.txt | ||||||||||||||
| Intra-domain Source Address Validation Architecture | ||||||||||||||
|
This document describes a generic architecture for intra-domain Source Address Validation (SAV). It provides a common framework for developing new intra-domain SAV mechanisms and describes the conditions under which such mechanisms can improve SAV accuracy with respect to existing intra-domain SAV mechanisms. | |||||||||||||
| draft-ietf-savnet-intra-domain-problem-statement-26.txt | ||||||||||||||
| Problem Statement,Gap Analysis,and Requirements for Intra-domain Source Address Validation | ||||||||||||||
|
Source address validation (SAV) is an important means to mitigate IP source address spoofing [RFC2827]. This document analyzes the gaps in current operational mechanisms for intra-domain SAV. It also identifies the properties that new intra-domain SAV mechanisms are expected to provide. | |||||||||||||
| draft-ietf-schc-8824-update-10.txt | ||||||||||||||
| Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) | ||||||||||||||
|
This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for constrained devices, and it uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework and its application for IPv6 and UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from that of IPv6 and UDP headers, since CoAP uses a flexible header with a variable number of options that are in turn of variable length. The CoAP message format is asymmetric, i.e., request messages have a header format different from that of response messages. This specification gives guidance on applying SCHC to flexible headers and on leveraging the message format asymmetry for defining more efficient compression Rules. This document replaces and obsoletes RFC 8824. | |||||||||||||
| draft-ietf-schc-architecture-06.txt | ||||||||||||||
| Static Context Header Compression (SCHC) Architecture | ||||||||||||||
|
The Static Context Header Compression and fragmentation (SCHC) framework provides both a header compression mechanism and an optional fragmentation mechanism. This document defines a minimal architecture for SCHC deployments, providing guidance for implementers and operators on the essential components and their interactions required for effective SCHC operation. The architecture defines the components of a SCHC deployment - Endpoints, Instances, Contexts, Sessions, and Domains - their management, the framing of SCHC Datagrams, and considerations for technology-specific profiles. | |||||||||||||
| draft-ietf-schc-compress-payload-00.txt | ||||||||||||||
| SCHC Payload Compression for Structured Formats | ||||||||||||||
|
This document describes techniques to adapt the SCHC framework (RFC8724), used for header compression, to also compress and decompress payload of specific protocols. To this end, this document defines a new matching operator, equal-template, to check equality of field values with respect to a user-defined template, and a payload keyword to be used as Field IDentifier (FID) to signal the presence of payload to be compressed or decompressed. Additionally, this document defines a set of template functions and variables to optimize user-defined templates, which can be extended through the IANA registry defined herein. | |||||||||||||
| draft-ietf-schc-over-networks-prone-to-disruptions-05.txt | ||||||||||||||
| Static Context Header Compression and Fragmentation over networks prone to disruptions | ||||||||||||||
|
This document describes the use of SCHC over different network topologies and devices regardless of their capabilities and configurations. The use of SCHC will bring connectivity to devices with disruptive connections caused by restrained use of battery and connectionless setups with long delays and latency. | |||||||||||||
| draft-ietf-scitt-receipts-ccf-profile-04.txt | ||||||||||||||
| CCF Profile for COSE Receipts | ||||||||||||||
|
This document defines a new verifiable data structure (VDS) type for COSE Receipts and inclusion proofs specifically designed for append- only logs produced by the Confidential Consortium Framework (CCF) to provide stronger tamper-evidence guarantees. | |||||||||||||
| draft-ietf-scitt-scrapi-11.txt | ||||||||||||||
| Supply Chain Integrity,Transparency,and Trust (SCITT) Reference APIs | ||||||||||||||
|
This document specifies a REST API with the HTTP resources, request and response messages, and error handling needed for an interoperable implementation of a SCITT Transparency Service, as defined by the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. | |||||||||||||
| draft-ietf-scone-applicability-manageability-02.txt | ||||||||||||||
| Applicability & Manageability Considerations for SCONE | ||||||||||||||
|
This document describes the Applicability and Manageability considerations for providing throughput guidance to application endpoints. This guidance is specifically addressed within the context of telecommunications service provider networks utilizing the Standard Communication with Network Elements (SCONE) protocol. | |||||||||||||
| draft-ietf-scone-protocol-08.txt | ||||||||||||||
| Standard Communication with Network Elements (SCONE) Protocol | ||||||||||||||
|
This document describes a protocol where on-path network elements can communicate their perspective on the maximum sustainable throughput for QUIC flows to endpoints. This throughput advice suggests an upper bound on long-term average throughput, independent of and complementary to real-time congestion control signals. | |||||||||||||
| draft-ietf-seat-use-cases-01.txt | ||||||||||||||
| Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols | ||||||||||||||
|
This document outlines desirable security goals and use cases for integrating remote attestation (RA) capabilities with secure channel establishment protocols (e.g., TLS and DTLS). Peer authentication in such protocols establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about the current state of the Target Environment. This document specifies a set of essential security goals the protocol solution must have, including cryptographic binding to the secure connection, evidence freshness, and flexibility to support different attestation models. It then explores relevant use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. | |||||||||||||
| draft-ietf-sfc-nsh-ecn-support-18.txt | ||||||||||||||
| Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX | ||||||||||||||
|
Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol. | |||||||||||||
| draft-ietf-sidrops-8210bis-27.txt | ||||||||||||||
| The Resource Public Key Infrastructure (RPKI) to Router Protocol,Version 2 | ||||||||||||||
|
In order to validate the origin Autonomous Systems (ASes) and Autonomous System relationships behind BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC6480) prefix origin data, Router Keys, and ASPA data from a trusted cache. This document describes a protocol to deliver them. This document describes version 2 of the RPKI-Router protocol. [RFC6810] describes version 0, and [RFC8210] describes version 1. This document is compatible with both. | |||||||||||||
| draft-ietf-sidrops-aspa-notation-05.txt | ||||||||||||||
| Human Readable ASPA Notation | ||||||||||||||
|
This document defines a human readable notation for Validated ASPA Payloads (VAP, see ID-aspa-profile) for use with RPKI tooling based on ABNF (RFC 5234). | |||||||||||||
| draft-ietf-sidrops-aspa-profile-29.txt | ||||||||||||||
| A Profile for Autonomous System Provider Authorization | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its transit providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. | |||||||||||||
| draft-ietf-sidrops-aspa-verification-28.txt | ||||||||||||||
| BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects | ||||||||||||||
|
This document describes procedures that make use of Autonomous System Provider Authorization (ASPA) objects in the Resource Public Key Infrastructure (RPKI) to verify the Border Gateway Protocol (BGP) AS_PATH attribute of advertised routes. This AS_PATH verification enhances routing security by adding means to detect and mitigate route leaks and AS_PATH manipulations. | |||||||||||||
| draft-ietf-sidrops-avoid-rpki-state-in-bgp-12.txt | ||||||||||||||
| Guidance to Avoid Carrying RPKI Validation States in BGP Path Attributes | ||||||||||||||
|
This document provides guidance to avoid carrying Resource Public Key Infrastructure (RPKI) derived validation states in Border Gateway Protocol (BGP) Path Attributes whose change triggers a BGP UPDATE being sent across external BGP (EBGP) sessions. Annotating routes with BGP Path Attributes carried across EBGP sessions signaling validation states may cause needless flooding of BGP UPDATE messages through the global Internet routing system, for example when Route Origin Authorizations (ROAs) are issued, or are revoked, or when RPKI-To-Router sessions are terminated. Operators should ensure RPKI-derived validation states are not signaled in BGP Path Attributes whose change triggers a BGP UPDATE being sent across EBGP sessions. Specifically, operators should not associate Prefix Origin Validation state with BGP routes using any form of BGP Communities carried across EBGP session. | |||||||||||||
| draft-ietf-sidrops-bar-sav-10.txt | ||||||||||||||
| Source Address Validation Using BGP UPDATEs,ASPA,and ROA (BAR-SAV) | ||||||||||||||
|
Designing an efficient source address validation (SAV) filter requires minimizing false positives (i.e., avoiding blocking legitimate traffic) while maintaining directionality (see RFC8704). This document advances the technology for SAV filter design through a method that makes use of BGP UPDATE messages, Autonomous System Provider Authorization (ASPA), and Route Origin Authorization (ROA). The proposed method's name is abbreviated as BAR-SAV. BAR-SAV can be used by network operators to derive more robust SAV filters and thus improve network resilience. This document updates RFC8704. | |||||||||||||
| draft-ietf-sidrops-constraining-rpki-trust-anchors-02.txt | ||||||||||||||
| Constraining RPKI Trust Anchors | ||||||||||||||
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations. | |||||||||||||
| draft-ietf-sidrops-moa-profile-04.txt | ||||||||||||||
| A Profile for Mapping Origin Authorizations (MOAs) | ||||||||||||||
|
This document proposes a new approach by leveraging Resource Public Key Infrastructure (RPKI) architecture to verify the authenticity of the mapping origin of an IPv4 address block. MOA is a newly defined cryptographically signed object that provides a means for the address holder can authorize an IPv6 mapping prefix to originate mapping for one or more IPv4 prefixes. When receiving the MOA objects from the relying parties, PE devices can verify and discard invalid address mapping announcements from unauthorized IPv6 mapping prefixes to prevent IPv4 prefix hijacking. | |||||||||||||
| draft-ietf-sidrops-publication-server-bcp-11.txt | ||||||||||||||
| Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services | ||||||||||||||
|
This document describes best current practices for operating an RFC 8181 (A Publication Protocol for the Resource Public Key Infrastructure (RPKI)) publication engine and its associated publicly accessible rsync (RFC 5781) and RPKI Repository Delta Protocol (RRDP) (RFC 8182) repositories. | |||||||||||||
| draft-ietf-sidrops-rpki-ccr-11.txt | ||||||||||||||
| A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR) | ||||||||||||||
|
This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a Distinguished Encoding Rules (DER) encoded data interchange format which can be used to represent various aspects of the state of a validated RPKI cache at a particular point in time. The CCR profile is a compact and versatile format, well-suited for a variety of applications, for example, audit trails, analytics pipelines, and validated payload dissemination. | |||||||||||||
| draft-ietf-sidrops-rpki-erik-protocol-07.txt | ||||||||||||||
| The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI) | ||||||||||||||
|
This document specifies the Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI). Erik Synchronization can be characterized as a data replication system using Merkle trees, a content-addressable naming scheme, concurrency control using monotonically increasing sequence numbers, and HTTP transport. The protocol is used to interact with Erik Relays, a new intermediary layer in the RPKI supply chain that exists between the Repository Publication Point and Relying Parties, enabling better scalability. Relying Parties can combine information retrieved via Erik Synchronization with other RPKI transport protocols. The protocol's design is intended to be efficient, fast, easy to implement, and robust in the face of partitions or faults in the network. | |||||||||||||
| draft-ietf-sidrops-rpki-ta-tiebreaker-06.txt | ||||||||||||||
| Tiebreaking Resource Public Key Infrastructure (RPKI) Trust Anchors | ||||||||||||||
|
A Trust Anchor (TA) in the Resource Public Key Infrastructure (RPKI) is represented by a self-signed X.509 Certification Authority (CA) certificate. Over time, Relying Parties (RP) may have acquired multiple different issuances of valid TA certificates from the same TA operator. This document specifies a tiebreaking scheme to be used by RPs to select one TA certificate for certification path validation. This document updates RFC 8630. | |||||||||||||
| draft-ietf-sidrops-rtr-yang-09.txt | ||||||||||||||
| YANG Data Model for RPKI to Router Protocol | ||||||||||||||
|
This document defines YANG data models for managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). | |||||||||||||
| draft-ietf-sidrops-spl-verification-04.txt | ||||||||||||||
| Signed Prefix List (SPL) Based Route Origin Verification and Operational Considerations | ||||||||||||||
|
The Signed Prefix List (SPL) is an RPKI object that attests to the complete list of prefixes which an Autonomous System (AS) may originate in the Border Gateway Protocol (BGP). This document specifies an SPL-based Route Origin Verification (SPL-ROV) methodology and combines it with the ROA-based ROV (ROA-ROV) to facilitate an integrated mitigation strategy for prefix hijacks and AS forgery. The document also explains the various BGP security threats that SPL can help address and provides operational considerations associated with SPL-ROV deployment. | |||||||||||||
| draft-ietf-sidrops-vrp-notation-05.txt | ||||||||||||||
| Human Readable Validate ROA Payload Notation | ||||||||||||||
|
This document defines a human readable notation for Validated ROA Payloads (VRP, RFC 6811) based on ABNF (RFC 5234) for use with RPKI tooling and documentation. | |||||||||||||
| draft-ietf-sipcore-retransmission-allowed-fixes-05.txt | ||||||||||||||
| Comprehensive Errata for the 'retransmission-allowed' XML Element | ||||||||||||||
|
This document fixes use of the 'retransmission-allowed' element of PIDF-LO in six published RFCs. All text and examples should show 'true' or 'false' to match the XML schema definitions, but some RFCs incorrectly use 'yes' or 'no'. This document updates RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262. | |||||||||||||
| draft-ietf-sml-structured-email-06.txt | ||||||||||||||
| Structured Email | ||||||||||||||
|
This document specifies how a machine-readable variant of its content can be added to email messages. | |||||||||||||
| draft-ietf-sml-structured-quoted-content-00.txt | ||||||||||||||
| Structured Quoted Content | ||||||||||||||
|
This document describes a machine-readable format for conveying quoted content in email messages. This can be used when replying to or forwarding an email message. Structured quoted content is expected to be used in conjunction with conventional, human-readable quote formatting. They are based on the forthcoming "structured email" specification defined in [I-D.ietf- sml-structured-email-03] and related drafts. | |||||||||||||
| draft-ietf-sml-trust-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-snac-simple-12.txt | ||||||||||||||
| Automatically Connecting Stub Networks to Unmanaged Infrastructure | ||||||||||||||
|
This document specifies a set of practices for using IPv6 networking to automatically connect stub networks to adjacent infrastructure networks, even if they do not otherwise use IPv6. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network). | |||||||||||||
| draft-ietf-spice-glue-id-10.txt | ||||||||||||||
| GLobal Unique Enterprise (GLUE) Identifiers | ||||||||||||||
|
This specification establishes a URI scheme for GLobal Unique Enterprise (GLUE) Identifiers. This enables URI identifiers to be used for businesses and organizations. It enables organizational identities from existing authorities to be represented within this URI scheme. | |||||||||||||
| draft-ietf-spice-oidc-cwt-06.txt | ||||||||||||||
| OpenID Connect Standard Claims Registration for CBOR Web Tokens | ||||||||||||||
|
This document registers OpenID Connect standard claims already used in JSON Web Tokens for use in CBOR Web Tokens. | |||||||||||||
| draft-ietf-spice-sd-cwt-08.txt | ||||||||||||||
| Selective Disclosure CBOR Web Tokens (SD-CWT) | ||||||||||||||
|
This specification describes a data minimization technique for use with CBOR Web Tokens (CWTs). The approach is inspired by the Selective Disclosure JSON Web Token (SD-JWT), with changes to align with CBOR Object Signing and Encryption (COSE) and CWTs. | |||||||||||||
| draft-ietf-spice-vdcarch-01.txt | ||||||||||||||
| A reference architecture for direct presentation credential flows | ||||||||||||||
|
This document defines a reference architecture for direct presentation flows of digital credentials. The architecture introduces the concept of a presentation mediator as the active component responsible for managing, presenting, and selectively disclosing credentials while preserving a set of security and privacy promises that will also be defined. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/leifj/wallet-refarch. | |||||||||||||
| draft-ietf-spring-cs-sr-policy-17.txt | ||||||||||||||
| Circuit Style Segment Routing Policy | ||||||||||||||
|
This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. The association of two co- routed unidirectional SR Policies satisfying these requirements is called "Circuit Style" SR Policy (CS-SR Policy). | |||||||||||||
| draft-ietf-spring-resource-aware-segments-19.txt | ||||||||||||||
| Introducing Resource Awareness to SR Segments | ||||||||||||||
|
This document describes a mechanism to allocate network resources to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are referred to as resource-aware SIDs. The resource-aware SIDs retain their original forwarding semantics, with the additional semantics to identify the set of network resources available for the packet processing and forwarding action. This mechanism is applicable to both segment routing with MPLS data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). | |||||||||||||
| draft-ietf-spring-sid-as-source-address-00.txt | ||||||||||||||
| SID as source address in SRv6 | ||||||||||||||
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. Both the carrier market and the enterprise market are adopting SRv6 for end-to-end service delivery. However, if a firewall exists along an SRv6 path, not only legitimate SRv6 traffic but also ICMP packets generated on SRv6 transit node will be dropped. This proposal addresses this issue by using SID as source address in SRv6 packets. | |||||||||||||
| draft-ietf-spring-sr-for-enhanced-vpn-11.txt | ||||||||||||||
| Segment Routing based Network Resource Partition (NRP) for Enhanced VPN | ||||||||||||||
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on 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. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment is referred to by its Segment Identifier (SID). SIDs can represent topological or service based instructions. SIDs can further be associated with a set of network resources used for executing the instruction. Such SIDs are called resource-aware SIDs. A group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. | |||||||||||||
| draft-ietf-spring-sr-policy-cp-validity-00.txt | ||||||||||||||
| Validity of SR Policy Candidate Path | ||||||||||||||
|
An SR Policy comprises one or more candidate paths of which at a given time one and only one may be active (i.e., installed in forwarding plane and usable for steering of traffic). Each candidate path, in turn, may have one or more segment lists of which one or more may be active. When multiple segment lists are active, traffic is load balanced over them. Currently, a candidate path is valid as long as at least one of its segment lists is active. However, this default validity criterion does not meet the requirements of some scenarios. This document defines the new candidate path validity criterion. | |||||||||||||
| draft-ietf-spring-sr-policy-eligibility-01.txt | ||||||||||||||
| Eligibility Concept in Segment Routing Policies | ||||||||||||||
|
Segment Routing (SR) introduces new challenges for pinning candidate paths on their intended paths (the path the PCE computed based on provided intent and may have made bandwidth reservations on). The actual path through a network can change or no longer meet the required constraints if a SID list of an SR Policy candidate path is not fully expressed as a list of adjacency SIDs or when a change in the topology does happen. The introduction of the new candidate path eligibility concept permits a path to be signaled and established as operationally up, but controls whether the path is eligible to carry traffic, thus influencing its active state. The eligibility concept allows a system (operator, pce, headend, etc.) to set eligibility as false when path deviations may have occurred, or path constraints are no longer met for one or more SID lists of a candidate path and clear it when candidate path deviations are removed or constraints are met again. | |||||||||||||
| draft-ietf-spring-sr-policy-flexible-cp-selection-01.txt | ||||||||||||||
| Flexible Candidate Path Selection of SR Policy | ||||||||||||||
|
This document describes a flexible method for selecting candidate Segment Routing (SR) policy paths. Based on the real-time resource usage and forwarding quality of candidate paths, the head node can perform dynamic path switching among multiple candidate paths in the SR policy. | |||||||||||||
| draft-ietf-spring-sr-policy-group-01.txt | ||||||||||||||
| SR Policy Group | ||||||||||||||
|
Segment Routing is a source routing paradigm that explicitly indicates the forwarding path for packets at the ingress node. An SR Policy is associated with one or more candidate paths, and each candidate path is either dynamic, explicit, or composite. This document describes SR Policy Group in MPLS and IPv6 environments and illustrates some use cases for parent SR Policy and SR Policy Group to provide best practice cases for operators. | |||||||||||||
| draft-ietf-spring-sr-policy-nrp-02.txt | ||||||||||||||
| Segment Routing Policy Extension for Network Resource Partition | ||||||||||||||
|
Segment Routing (SR) Policy is a set of candidate paths, each consisting of one or more segment lists and the associated information. A Network Resource Partition (NRP), is a subset of the resources and associated policies in the underlay network. In SR networks with multiple NRPs, an SR Policy can be associated with a particular NRP. In that case, SR Policy can be used for steering and forwarding traffic which is mapped to the NRP, so that the packets can be processed with the subset of network resources and policy of the NRP for guaranteed performance. Thus the association between SR Policy and NRP needs to be specified. This document defines extensions to the SR Policy Architecture to allow the association of the SR Policy candidate paths with NRPs. | |||||||||||||
| draft-ietf-spring-sr-policy-yang-08.txt | ||||||||||||||
| YANG Data Model for Segment Routing Policy | ||||||||||||||
|
This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. | |||||||||||||
| draft-ietf-spring-sr-redundancy-protection-09.txt | ||||||||||||||
| SRv6 for Redundancy Protection | ||||||||||||||
|
Redundancy Protection is a generalized protection mechanism to achieve high reliability for services provided in Segment Routing networks. The mechanism uses the "Live-Live" methodology, i.e., multiple copies of the data packets are sent on different paths to provide protection. This document introduces one new SRv6 Segment Endpoint Behavior, the associated Headend Encapsulation Behaviors and the associated Redundancy Policy to provide replication and elimination functions on specific network nodes by leveraging SRv6 Network Programming capabilities. | |||||||||||||
| draft-ietf-spring-srv6-inter-layer-programming-03.txt | ||||||||||||||
| SRv6 for Inter-Layer Network Programming | ||||||||||||||
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. | |||||||||||||
| draft-ietf-spring-srv6-mpls-interworking-03.txt | ||||||||||||||
| SRv6 and MPLS interworking | ||||||||||||||
|
This document describes interworking between SRv6 and MPLS domains to provide end to end path. Interworking problem is generalized into various interworking scenarios. These scenarios are stitched either by transport interworking or service interworking. New SRv6 SID endpoint behaviors are defined for the purpose. These new SRv6 SID behaviors and MPLS labels stitch end to end path across different data plane. | |||||||||||||
| draft-ietf-spring-srv6-security-16.txt | ||||||||||||||
| Segment Routing IPv6 Security Considerations | ||||||||||||||
|
SRv6 is a traffic engineering, encapsulation and steering mechanism utilizing IPv6 addresses to identify segments in a pre-defined policy. This document discusses security considerations in SRv6 networks, including the potential threats and the possible mitigation methods. The document does not define any new security protocols or extensions to existing protocols. | |||||||||||||
| draft-ietf-spring-srv6-service-programming-00.txt | ||||||||||||||
| SRv6 Service Programming | ||||||||||||||
|
This document defines data plane functionality required to implement service segments and achieve service programming in SRv6 networks. | |||||||||||||
| draft-ietf-spring-srv6-yang-base-02.txt | ||||||||||||||
| YANG Data Model for SRv6 Base | ||||||||||||||
|
This document describes a YANG data model for Segment Routing IPv6 (SRv6) base. The model serves as a base framework for configuring and managing an SRv6 subsystem and expected to be augmented by other SRv6 models accordingly. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). | |||||||||||||
| draft-ietf-spring-stamp-srpm-mpls-07.txt | ||||||||||||||
| Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane | ||||||||||||||
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for performance measurement in SR-MPLS networks using the Simple Two- Way Active Measurement Protocol (STAMP), as specified in RFC 8762, along with its optional extensions specified in RFC 8972 and further augmented in RFC 9503. The described procedures are used for SR-MPLS paths (including Segment Lists of SR-MPLS Policies, SR-MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm (Flex-Algo) paths), as well as Layer-3 and Layer-2 services carried over the SR-MPLS paths. | |||||||||||||
| draft-ietf-spring-stamp-srpm-srv6-04.txt | ||||||||||||||
| Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over IPv6 (SRv6) Data Plane | ||||||||||||||
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for performance measurement in SRv6 networks using the Simple Two-Way Active Measurement Protocol (STAMP), as specified in RFC 8762, along with its optional extensions specified in RFC 8972 and further augmented in RFC 9503. The procedures described in this document are used for links and SRv6 paths (including Segment Lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm (Flex- Algo) paths), as well as Layer-3 and Layer-2 services carried over the SRv6 paths. | |||||||||||||
| draft-ietf-srv6ops-problem-summary-02.txt | ||||||||||||||
| SRv6 Deployment and Operation Problem Summary | ||||||||||||||
|
This document aims to provide a concise overview of the common problems encountered during SRv6 deployment and operation, which provides foundations for further work, including for example of potential solutions and best practices to navigate deployment. | |||||||||||||
| draft-ietf-srv6ops-srv6-deployment-03.txt | ||||||||||||||
| SRv6 Deployment Options | ||||||||||||||
|
When deciding to migrate a network from existing data-plane technologies (e.g. MPLS, SR-MPLS or overlay encapsulations such as VXLAN) to SRv6, common questions involve how to perform the migration, how to minimize impact to the existing network and what techniques are available to support a smooth transition. This document presents various deployment and migration options for networks evolving toward SRv6 from prior transport or overlay technologies. | |||||||||||||
| draft-ietf-srv6ops-srv6addressing-00.txt | ||||||||||||||
| Addressing Recommendations for SRv6 | ||||||||||||||
|
This document provides recommendations for addressing SRv6 locators format. It introduces concepts of Blocks, Sets, and Node IDs, and explains how summarization boundaries and flexible algorithm support can be implemented for both small and large networks. | |||||||||||||
| draft-ietf-sshm-cert-01.txt | ||||||||||||||
| SSH Certificate Format | ||||||||||||||
|
This document presents a lightweight certificate format that may be used in the context of the Secure Shell (SSH) protocol for user and host authentication. | |||||||||||||
| draft-ietf-sshm-chacha20-poly1305-04.txt | ||||||||||||||
| Secure Shell (SSH) authenticated encryption cipher: chacha20-poly1305 | ||||||||||||||
|
This document describes the Secure Shell (SSH) chacha20-poly1305 authenticated encryption cipher. | |||||||||||||
| draft-ietf-sshm-composite-sigs-00.txt | ||||||||||||||
| Post-Quantum Composite Signatures in SSH | ||||||||||||||
|
This document specifies the integration of two composite post-quantum signature schemes into the Secure Shell (SSH) protocol. These schemes combine the post-quantum Module-Lattice Digital Signature Algorithm (ML-DSA) with Elliptic Curve signature algorithms (Ed25519 and ECDSA, respectively) to provide security against both quantum and classical adversaries. | |||||||||||||
| draft-ietf-sshm-hostkey-update-00.txt | ||||||||||||||
| Host key update mechanism for SSH | ||||||||||||||
|
This document describes an extension to allow a Secure Shell (SSH) server to inform a client of the full set of host keys it supports. This may be used for graceful host key rotation and to provide keys for additional signature algorithms to the client, supporting algorithm agility. | |||||||||||||
| draft-ietf-sshm-strict-kex-02.txt | ||||||||||||||
| SSH Strict KEX extension | ||||||||||||||
|
This document describes a small set of modifications to the Secure Shell (SSH) protocol to fix the so-called Terrapin Attack on the initial key exchange. | |||||||||||||
| draft-ietf-stir-8588bis-02.txt | ||||||||||||||
| Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) | ||||||||||||||
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIP Forum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. This document obsoletes RFC8588. | |||||||||||||
| draft-ietf-stir-certificate-transparency-04.txt | ||||||||||||||
| STI Certificate Transparency | ||||||||||||||
|
This document describes a framework for the use of the Certificate Transparency (CT) protocol for publicly logging the existence of Secure Telephone Identity (STI) certificates as they are issued or observed. This allows any interested party that is part of the STI ecosystem to audit STI certification authority (CA) activity and audit both the issuance of suspect certificates and the certificate logs themselves. The intent is to establish a level of trust within the STI ecosystem that relies on the verification of telephone numbers. This involves requiring STI certificates to be listed in an established log and refusing to honor those that are not. This effectively establishes the precedent that STI CAs must add all issued certificates to the logs and thus establishes unique association of STI certificates to an authorized provider or assignee of a telephone number resource. In the STI ecosystem, the primary role of CT is to provide verifiable trust by detecting the unauthorized issuance of duplicate telephone number level delegate certificates or provider level certificates. This provides a robust auditable mechanism for the detection of unauthorized creation of certificate credentials for illegitimate spoofing of telephone numbers or service provider codes (SPC). The framework borrows the log structure and API model from RFC6962 to enable public auditing and verifiability of certificate issuance. While the foundational mechanisms for log operation, Merkle Tree construction, and Signed Certificate Timestamps (SCTs) are aligned with RFC6962, this document contextualizes their application in the STIR ecosystem, focusing on verifiable control over telephone number or service provider code resources. | |||||||||||||
| draft-ietf-stir-certificates-ocsp-14.txt | ||||||||||||||
| OCSP Usage for Secure Telephone Identity Certificates | ||||||||||||||
|
When certificates are used as credentials to attest the assignment or ownership of telephone numbers, some mechanism is required to convey certificate freshness to relying parties. Certificate Revocation Lists (CRLs) are commonly used for this purpose, but for certain classes of certificates, including delegate certificates conveying their scope of authority by-reference in Secure Telephone Identity Revisited (STIR) systems, they may not be aligned with the needs of relying parties. This document specifies the use of the Online Certificate Status Protocol (OCSP) as a means of retrieving real-time status information about such certificates, defining new extensions to compensate for the dynamism of telephone number assignments. | |||||||||||||
| draft-ietf-stir-certificates-shortlived-06.txt | ||||||||||||||
| Short-Lived Certificates for Secure Telephone Identity | ||||||||||||||
|
When certificates are used as credentials to attest the assignment of ownership of telephone numbers, some mechanism is required to provide certificate freshness. This document specifies short-lived certificates as a means of guaranteeing certificate freshness for secure telephone identity (STIR), potentially relying on the Automated Certificate Management Environment (ACME) or similar mechanisms to allow signers to acquire certificates as needed. | |||||||||||||
| draft-ietf-suit-firmware-encryption-26.txt | ||||||||||||||
| Encrypted Payloads in SUIT Manifests | ||||||||||||||
|
This document specifies techniques for encrypting software, firmware, machine learning models, and personalization data by utilizing the IETF SUIT manifest. Key agreement is provided by ephemeral-static (ES) Diffie-Hellman (DH) and AES Key Wrap (AES-KW). ES-DH uses public key cryptography while AES-KW uses a pre-shared key. Encryption of the plaintext is accomplished with conventional symmetric key cryptography. | |||||||||||||
| draft-ietf-suit-manifest-37.txt | ||||||||||||||
| A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest | ||||||||||||||
|
This specification describes the format of a manifest. A manifest is a bundle of metadata about code/data obtained by a recipient (chiefly the firmware for an Internet of Things (IoT) device), where to find the code/data, the devices to which it applies, and cryptographic information protecting the manifest. Software updates and Trusted Invocation both tend to use sequences of common operations, so the manifest encodes those sequences of operations, rather than declaring the metadata. | |||||||||||||
| draft-ietf-suit-mti-23.txt | ||||||||||||||
| Cryptographic Algorithms for Internet of Things (IoT) Devices | ||||||||||||||
|
The SUIT manifest, as defined in "A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices" (RFC 9124), provides a flexible and extensible format for describing how firmware and software updates are to be fetched, verified, decrypted, and installed on resource-constrained devices. To ensure the security of these update processes, the manifest relies on cryptographic algorithms for functions such as digital signature verification, integrity checking, and confidentiality. This document defines cryptographic algorithm profiles for use with the Software Updates for Internet of Things (SUIT) manifest. These profiles specify sets of algorithms to promote interoperability across implementations. Given the diversity of IoT deployments and the evolving cryptographic landscape, algorithm agility is essential. This document groups algorithms into named profiles to accommodate varying levels of device capabilities and security requirements. These profiles support the use cases laid out in the SUIT architecture, published in "A Firmware Update Architecture for Internet of Things" (RFC 9019). | |||||||||||||
| draft-ietf-suit-mud-10.txt | ||||||||||||||
| Strong Assertions of IoT Network Access Requirements | ||||||||||||||
|
The Manufacturer Usage Description (MUD) specification describes the access and network functionality required for a device to properly function. This description has to reflect the software running on the device and its configuration. Because of this, the most appropriate entity for describing device network access requirements is the same as the entity developing the software and its configuration. A network presented with a MUD file by a device allows detection of misbehavior by the device software and configuration of access control. This document defines a way to link the Software Updates for Internet of Things (SUIT) manifest to a MUD file offering a stronger binding between the two. | |||||||||||||
| draft-ietf-suit-report-22.txt | ||||||||||||||
| Secure Reporting of SUIT Update Status | ||||||||||||||
|
The Software Update for the Internet of Things (SUIT) manifest provides a way for many different update and boot workflows to be described by a common format. This document specifies a lightweight feedback mechanism that allows a developer in possession of a manifest to reconstruct the decisions made and actions performed by a manifest processor. | |||||||||||||
| draft-ietf-suit-trust-domains-12.txt | ||||||||||||||
| Software Update for the Internet of Things (SUIT) Manifest Extensions for Multiple Trust Domain | ||||||||||||||
|
A device has more than one trust domain when it enables delegation of different rights to mutually distrusting entities for use for different purposes or Components in the context of firmware or software update. This specification describes extensions to the Software Update for the Internet of Things (SUIT) Manifest format for use in deployments with multiple trust domains. | |||||||||||||
| draft-ietf-suit-update-management-15.txt | ||||||||||||||
| Update Management Extensions for Software Updates for Internet of Things (SUIT) Manifests | ||||||||||||||
|
This document specifies extensions to the SUIT manifest format. These extensions allow a Manifest Author, update distributor, or device operator to more precisely control the distribution and installation of updates to devices. These extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill Of Materials information about an updated device. | |||||||||||||
| draft-ietf-tcpm-ack-rate-request-12.txt | ||||||||||||||
| TCP ACK Rate Request Option | ||||||||||||||
|
TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver. | |||||||||||||
| draft-ietf-tcpm-rst-diagnostic-payload-03.txt | ||||||||||||||
| TCP RST Diagnostic Payload | ||||||||||||||
|
This document specifies an experimental diagnostic payload format returned in TCP RST segments. Such payloads are used to share with an endpoint the reasons for which a TCP connection has been reset. Sharing this information is meant to ease diagnostic and troubleshooting. This specification builds on provisions that are already present in RFC 9293 "Transmission Control Protocol (TCP)". As such, this document does not require any change to RFC 9293. | |||||||||||||
| draft-ietf-tcpm-tcp-ao-algs-07.txt | ||||||||||||||
| Cryptographic Algorithms That Produce 128-bit MACs For Use With TCP-AO | ||||||||||||||
|
RFC5926 creates a list of cryptographic algorithms that can be used with TCP-AO. This document expands that list, adding two Message Authentication Code (MAC) algorithms, HMAC-SHA256-128 and KMAC256-128. For each MAC algorithm, a corresponding Key Derivation Function (KDF) is also added. The MAC algorithms described by this document produce 128-bit (i.e., 16-byte) MACs. When 16-byte MACs are encoded in TCP-AO, the TCP-AO consumes 20 of the 40 bytes available for TCP options. | |||||||||||||
| draft-ietf-tcpm-tcp-ghost-acks-09.txt | ||||||||||||||
| Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs | ||||||||||||||
|
Historically, TCP as specified in RFC 793 was threatened by the blind data injection attack because of the loose SEG.ACK value validation, where the SEG.ACK value of a TCP segment is considered valid as long as it does not acknowledge data ahead of what has been sent. RFC 5961 improved the input validation by shrinking the range of acceptable SEG.ACK values in a TCP segment. Later, RFC 9293 incorporated the updates proposed by RFC 5961 as a TCP stack implementation option. However, an endpoint that follows the RFC 9293 specifications can still accept a TCP segment containing an SEG.ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the way TCP verifies incoming TCP segments' SEG.ACK value to prevent TCP from accepting such invalid SEG.ACK values. | |||||||||||||
| draft-ietf-teas-5g-network-slice-application-07.txt | ||||||||||||||
| IETF Network Slice Application in 3GPP 5G End-to-End Network Slice | ||||||||||||||
|
Network Slicing is one of the core features of 5G defined in 3GPP, which provides different network service as independent logical networks. To provide 5G network slices services, an end-to-end network slice has to span three network segments: Radio Access Network (RAN), Mobile Core Network (CN) and Transport Network (TN). This document describes the application of the IETF network slice framework in providing 5G end-to-end network slices, including network slice mapping in the management, control and data planes. | |||||||||||||
| draft-ietf-teas-actn-poi-applicability-20.txt | ||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI) | ||||||||||||||
|
This document explores the applicability of the Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) within the context of IP/MPLS and optical internetworking. It examines the YANG data models defined by the IETF that enable an ACTN-based deployment architecture and highlights specific scenarios pertinent to Service Providers. Existing IETF protocols and data models are identified for each multi-technology scenario (packet over optical), particularly emphasising the Multi-Domain Service Coordinator to Provisioning Network Controller Interface (MPI) within the ACTN architecture | |||||||||||||
| draft-ietf-teas-actn-poi-assurance-05.txt | ||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) for Packet Optical Integration (POI) service assurance | ||||||||||||||
|
This document extends the analysis of the applicability of Abstraction and Control of TE Networks (ACTN) architecture to Packet Optical Integration (POI) to cover multi-layer service assurance scenarios. Specifically, the ACTN architecture supports service assurance through the detection and correlation of failures across the optical and packet layers, with failure handling performed through the relevant PNC. The MDSC can also request health checks for IP services across multi-domain paths for SLA conformance assessment. The PNCs may also be configured with thresholds so that alerts are reported when relevant service or network conditions exceed defined limits. It is assumed that the underlying transport optical network carries end-to-end IP services such as L2VPN or L3VPN connectivity services, with specific Service Level Agreement (SLA) requirements. Existing IETF protocols and data models are identified for each multi-layer (packet over optical) service assurance scenario with a specific focus on the MPI (Multi-Domain Service Coordinator to Provisioning Network Controllers Interface) in the ACTN architecture. | |||||||||||||
| draft-ietf-teas-applicability-actn-slicing-10.txt | ||||||||||||||
| Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to IETF Network Slicing | ||||||||||||||
|
Network abstraction is a technique that can be applied to a network domain to obtain a view of potential connectivity across the network by utilizing a set of policies to select network resources. Network slicing is an approach to network operations that builds on the concept of network abstraction to provide programmability, flexibility, and modularity. It may use techniques such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) to create multiple logical or virtual networks, each tailored for a set of services that share the same set of requirements. Abstraction and Control of Traffic Engineered Networks (ACTN) is described in RFC 8453. It defines an SDN-based architecture that relies on the concept of network and service abstraction to detach network and service control from the underlying data plane. This document outlines the applicability of ACTN to network slicing in a Traffic Engineered (TE) network that utilizes IETF technologies. It also identifies the features of network slicing not currently within the scope of ACTN and indicates where ACTN might be extended. | |||||||||||||
| draft-ietf-teas-composite-network-slices-01.txt | ||||||||||||||
| Realization of Composite IETF Network Slices | ||||||||||||||
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices built in networks that usWe IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a collection of network resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet specific SLOs and SLEs. In some network scenarios, network slices using IETF technologies may span multiple network domains, and they may be composed hierarchically, which means a network slice itself may be further sliced. In the context of 5G, a 5G end-to-end network slice consists of three different types of network technology segments: Radio Access Network (RAN), Transport Network (TN) and Core Network (CN). The transport segments of the 5G end-to-end network slice can be provided using network slices described in RFC 9543. This document first describes the possible use cases of composite network slices built in networks that use IETF network technologies, then it provides considerations about the realization of composite network slices. For the multi-domain network slices, an Inter-Domain Network Resource Partition Identifier (Inter-domain NRP ID) may be introduced. For hierarchical network slices, the structure of the NRP ID is discussed. And for the interaction between IETF network slices with 5G network slices, the identifiers of the 5G network slices may be introduced into IETF networks. These network slice- related identifiers may be used in the data plane, control plane and management plane of the network for the instantiation and management of composite network slices. This document also describes the management considerations of composite network slices. | |||||||||||||
| draft-ietf-teas-ietf-network-slice-nbi-yang-26.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-teas-network-slice-topology-yang-04.txt | ||||||||||||||
| IETF Network Slice Topology YANG Data Model | ||||||||||||||
|
An RFC 9543 network slice customer may utilize intent-based topologies to express resource reservation intentions within the provider's network. These customer-defined intent topologies allow customers to request shared resources for future connections that can be flexibly allocated and customized. Additionally, they provide an extensive level of control over underlay service paths within the network slice. This document describes a YANG data model for expressing customer intent topologies which can be used to enhance the RFC 9543 Network Slice Services in specific use cases, such as Network wholesale scenarios, where both topology and connectivity intents need to be expressed. | |||||||||||||
| draft-ietf-teas-nrp-scalability-10.txt | ||||||||||||||
| Scalability Considerations for Network Resource Partition | ||||||||||||||
|
A network slice offers connectivity services to a network slice customer with specific Service Level Objectives (SLOs) and Service Level Expectations (SLEs) over a common underlay network. RFC 9543 describes a framework for network slices in networks built using IETF technologies. As part of that framework, the Network Resource Partition (NRP) is introduced as a subset of buffer/queuing/ scheduling resources that are allocated from the underlay network to carry a specific set of network slice service traffic and meet the requested SLOs and SLEs. As the demand for network slices increases, scalability becomes an important factor. Although the scalability of network slices can be improved by mapping a group of network slices to a single NRP, that design may not be suitable or possible for all deployments, thus there are concerns about the scalability of NRPs themselves. This document discusses some considerations for NRP scalability in the control and data planes. It also investigates a set of optimization mechanisms. | |||||||||||||
| draft-ietf-teas-nrp-yang-06.txt | ||||||||||||||
| YANG Data Models for Network Resource Partitions (NRPs) | ||||||||||||||
|
RFC 9543 describes a framework for Network Slices in networks built from IETF technologies. In this framework, the network resource partition (NRP) is introduced as a collection of network resources allocated from the underlay network to carry a specific set of Network Slice Service traffic and meet specific Service Level Objective (SLO) and Service Level Expectation (SLE) characteristics. This document defines two YANG data models for Network Resource Partitions (NRPs): a network-level model for policy configuration by a Network Slice Controller, and a device-level model for configuration of individual network elements. These models enable automated provisioning of NRPs in IP/MPLS and Segment Routing (SR) networks, supporting scalable realization of RFC 9543 Network Slice Services. | |||||||||||||
| draft-ietf-teas-ns-controller-models-08.txt | ||||||||||||||
| IETF Network Slice Controller and its Associated Data Models | ||||||||||||||
|
This document describes an approach for structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation of the IETF Network Slice Controller. | |||||||||||||
| draft-ietf-teas-ns-ip-mpls-09.txt | ||||||||||||||
| Realizing Network Slices in IP/MPLS Networks | ||||||||||||||
|
Realizing network slices may require the Service Provider to have the ability to partition a physical network into multiple logical networks of varying sizes, structures, and functions so that each slice can be dedicated to specific services or customers. Multiple network slices can be realized on the same network while ensuring slice elasticity in terms of network resource allocation. This document describes a scalable solution to realize network slicing in IP/MPLS networks by supporting multiple services on top of a single physical network by requiring compliant domains and nodes to provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers. | |||||||||||||
| draft-ietf-teas-ns-models-applicability-02.txt | ||||||||||||||
| Applicability of IETF-Defined Service and Network Data Models for Network Slice Service Management | ||||||||||||||
|
This document exemplifies how the various data models that are produced in the IETF can be combined in the context of Network Slice Services delivery. Specifically, this document describes the relationship between the Network Slice Service models for requesting Network Slice Services and both Service (e.g., the L3VPN Service Model, the L2VPN Service Model) and Network (e.g., the L3VPN Network Model, the L2VPN Network Model) models used during their realization. In addition, this document describes the communication between a Network Slice Controller (NSC) and the network controllers for the realization of Network Slices. The Network Slice Service YANG model provides a customer-oriented view of the intended Network Slice Service. Thus, once an NSC receives a request for a Slice Service request, the NSC has to map it to accomplish the specific objectives expected by the network controllers. Existing YANG network models are analyzed against Network Slice requirements, and the gaps in existing models are identified. | |||||||||||||
| draft-ietf-teas-rfc8776-update-24.txt | ||||||||||||||
| Common YANG Data Types for Traffic Engineering | ||||||||||||||
|
This document defines a collection of commonly used Traffic Engineering (TE) specific data types, identities, and groupings in YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by other modules that model configuration and state for TE constructs, such as TE Topologies, TE Tunnels, TE Policies, TE Paths, TE Label Switched Paths (LSPs), and TE interfaces. This document obsoletes RFC 8776. | |||||||||||||
| draft-ietf-teas-rsvp-auth-v2-01.txt | ||||||||||||||
| RSVP Cryptographic Authentication,Version 2 | ||||||||||||||
|
This document provides an algorithm-independent description of the format and use of RSVP's INTEGRITY object. The RSVP INTEGRITY object is widely used to provide hop-by-hop integrity and authentication of RSVP messages, particularly in MPLS deployments using RSVP-TE. This document obsoletes both RFC2747 and RFC3097. | |||||||||||||
| draft-ietf-teas-rsvp-hmac-sha2-01.txt | ||||||||||||||
| RSVP Cryptographic Authentication with HMAC-SHA2 | ||||||||||||||
|
This document specifies the use of the US NIST Secure Hash Standard in the Hashed Message Authentication Code (HMAC) mode with RSVP Cryptographic Authentication version 2. Along with draft-ietf-teas- rsvp-auth-v2, this document obsoletes RFC2747 and RFC3097. | |||||||||||||
| draft-ietf-teas-rsvp-inplace-lsp-bw-update-01.txt | ||||||||||||||
| In-Place Bandwidth Update for MPLS RSVP-TE LSPs | ||||||||||||||
|
This document describes the procedure for updating the bandwidth of an MPLS RSVP-TE Label Switched Path (LSP) tunnel in-place without employing make-before-break (MBB). | |||||||||||||
| draft-ietf-teas-te-service-mapping-yang-19.txt | ||||||||||||||
| Traffic Engineering (TE) and Service Mapping YANG Data Model | ||||||||||||||
|
This document provides a YANG data model to map customer service models (e.g., L3VPN Service Delivery model) to Traffic Engineering (TE) models (e.g., the TE Tunnel or the Virtual Network (VN) model). These models are referred to as the TE Service Mapping Model and are applicable generically to the operator's need for seamless control and management of their VPN services with underlying TE support. The models are principally used for monitoring and diagnostics of the management systems to show how the service requests are mapped onto underlying network resources and TE models. | |||||||||||||
| draft-ietf-teas-te-topology-profiles-06.txt | ||||||||||||||
| Profiles for Traffic Engineering (TE) Topology Data Model and Applicability to non-TE-centric Use Cases | ||||||||||||||
|
This document describes how profiles of the Topology YANG data model, defined in RFC8795, can be used to address applications in Traffic Engineering aware (TE-aware) deployments, irrespective of whether they are TE-centric or not. | |||||||||||||
| draft-ietf-teas-yang-l3-te-topo-19.txt | ||||||||||||||
| YANG Data Models for Layer 3 and Packet TE Topologies | ||||||||||||||
|
This document defines YANG data models for layer 3 and packet traffic engineering topologies. | |||||||||||||
| draft-ietf-teas-yang-path-computation-28.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-teas-yang-rsvp-21.txt | ||||||||||||||
| A YANG Data Model for Resource Reservation Protocol (RSVP) | ||||||||||||||
|
This document defines a YANG data model for the configuration and management of the RSVP protocol. The YANG data model covers the building blocks that may be augmented by other RSVP extension data models such as RSVP Traffic-Engineering (RSVP-TE). It is divided into two modules that cover the basic and extended RSVP features. | |||||||||||||
| draft-ietf-teas-yang-te-44.txt | ||||||||||||||
| A YANG Data Model for Traffic Engineering Tunnels,Label Switched Paths,and Interfaces | ||||||||||||||
|
This document defines a YANG data model for the provisioning and management of Traffic Engineering (TE) tunnels, Label Switched Paths (LSPs), and interfaces. The model covers data pertinent to TE tunnels, TE LSPs, and TE interfaces that are independent of any technology or dataplane encapsulation. The model is divided into two YANG modules that address both device-specific and device-independent data, supporting configuration, operational state, Remote Procedure Calls (RPCs), and event notifications. | |||||||||||||
| draft-ietf-teas-yang-te-mpls-topology-05.txt | ||||||||||||||
| A YANG Data Model for MPLS-TE Topology | ||||||||||||||
|
This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies. | |||||||||||||
| draft-ietf-teas-yang-topology-filter-03.txt | ||||||||||||||
| YANG Data Model for Topology Filter | ||||||||||||||
|
This document defines a YANG data model for the management of topology filters/filter-sets on network elements and controllers. | |||||||||||||
| draft-ietf-teep-otrp-over-http-15.txt | ||||||||||||||
| HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication | ||||||||||||||
|
The Trusted Execution Environment Provisioning (TEEP) Protocol is used to manage code and configuration data in a Trusted Execution Environment (TEE). This document specifies the HTTP transport for TEEP communication where a Trusted Application Manager (TAM) service is used to manage code and data in TEEs on devices that can initiate communication to the TAM. | |||||||||||||
| draft-ietf-teep-protocol-26.txt | ||||||||||||||
| Trusted Execution Environment Provisioning (TEEP) Protocol | ||||||||||||||
|
This document specifies the Trusted Execution Environment Provisioning (TEEP) Protocol, which enables secure lifecycle management of Trusted Components in devices with a Trusted Execution Environment (TEE). The protocol defines message exchanges between a Trusted Application Manager (TAM) and a TEEP Agent to query device state, convey attestation evidence, and install, update, or delete Trusted Components. Messages are encoded in CBOR and secured using COSE. | |||||||||||||
| draft-ietf-tiptop-ip-architecture-01.txt | ||||||||||||||
| An Architecture for IP in Deep Space | ||||||||||||||
|
The IP protocol stacks used on Earth's Internet are typically configured based on assumptions of short delays and mostly uninterrupted communications. This document describes an architecture of the IP protocol stack tailored for its use in deep space. It involves buffering IP packets in IP forwarders facing intermittent links and adjusting transport protocol configurations and application protocol timers. This architecture applies to the Moon, Mars, and general interplanetary networking. | |||||||||||||
| draft-ietf-tiptop-quic-profile-00.txt | ||||||||||||||
| QUIC Profile for Deep Space | ||||||||||||||
|
Deep space communications involve long delays (e.g., the Earth to Mars one-way delay is ~4-20 minutes) and often intermittent communications. In this context, the default transport parameters of QUIC stacks, tuned for the terrestrial Internet, are not suitable for deep space. This document defines a QUIC profile for deep space. It provides guidance on how to estimate and set transport parameters, advice to space mission operators and application developers on how to configure QUIC for the deep space use case, and guidance to QUIC stack developers on properly exposing the required transport parameters in their API. | |||||||||||||
| draft-ietf-tiptop-usecase-02.txt | ||||||||||||||
| IP in Deep Space: Key Characteristics,Use Cases and Requirements | ||||||||||||||
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. Most of the IP protocol stack used on the Internet, in particular reliable transport protocols and applications, is based on the assumptions of shorter delays and mostly uninterrupted communications. This document describes the key characteristics, use cases, and requirements for deep space networking, intended to help when profiling IP protocols in such environment. | |||||||||||||
| draft-ietf-tls-extended-key-update-13.txt | ||||||||||||||
| Extended Key Update for Transport Layer Security (TLS) 1.3 | ||||||||||||||
|
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh execution of the key exchange negotiated during the initial handshake within an active session, thereby ensuring post-compromise security. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3. | |||||||||||||
| draft-ietf-tls-key-share-prediction-04.txt | ||||||||||||||
| TLS Key Share Prediction | ||||||||||||||
|
This document defines a mechanism for servers to communicate supported key share algorithms in DNS. Clients may use this information to reduce TLS handshake round-trips. | |||||||||||||
| draft-ietf-tls-mldsa-06.txt | ||||||||||||||
| Use of ML-DSA in TLS 1.3 | ||||||||||||||
|
This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. | |||||||||||||
| draft-ietf-tls-mlkem-11.txt | ||||||||||||||
| ML-KEM Post-Quantum Key Agreement for TLS 1.3 | ||||||||||||||
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. | |||||||||||||
| draft-ietf-tls-pake-02.txt | ||||||||||||||
| A Password Authenticated Key Exchange Extension for TLS 1.3 | ||||||||||||||
|
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. | |||||||||||||
| draft-ietf-tls-rfc9147bis-02.txt | ||||||||||||||
| The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 | ||||||||||||||
|
This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. | |||||||||||||
| draft-ietf-tls-super-jumbo-record-limit-03.txt | ||||||||||||||
| Large Record Sizes for TLS and DTLS with Reduced Overhead | ||||||||||||||
|
TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. DTLS 1.3 uses the same plaintext size limit. This document defines a TLS extension that allows endpoints to advertise larger per-direction maximum inner plaintext sizes, up to 2^30 - 256 bytes, while reducing overhead in TLS 1.3 and DTLS 1.3 record headers. | |||||||||||||
| draft-ietf-tls-tlsflags-18.txt | ||||||||||||||
| A Flags Extension for TLS 1.3 | ||||||||||||||
|
A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. | |||||||||||||
| draft-ietf-tls-trust-anchor-ids-05.txt | ||||||||||||||
| TLS Trust Anchor Identifiers | ||||||||||||||
|
This document defines the TLS Trust Anchors extension, a mechanism for a TLS client or server to select a certificate to present based on the peer's trusted certification authorities. It describes certification authorities more succinctly than the TLS Certificate Authorities extension. | |||||||||||||
| draft-ietf-tls-wkech-12.txt | ||||||||||||||
| A well-known URI for publishing service parameters | ||||||||||||||
|
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. | |||||||||||||
| draft-ietf-tsvwg-fq-pie-02.txt | ||||||||||||||
| Flow Queue PIE: A Hybrid Packet Scheduler and Active Queue Management Algorithm | ||||||||||||||
|
This document presents Flow Queue Proportional Integral controller Enhanced (FQ-PIE), a hybrid packet scheduler and Active Queue Management (AQM) algorithm to isolate flows and tackle the problem of bufferbloat. FQ-PIE uses hashing to classify incoming packets into different queues and provide flow isolation. Packets are dequeued by using a variant of the round robin scheduler. Each such flow is managed by the PIE algorithm to maintain high link utilization while controlling the queue delay to a target value. | |||||||||||||
| draft-ietf-tsvwg-l4sops-10.txt | ||||||||||||||
| Operational Guidance on Coexistence with Classic ECN during L4S Deployment | ||||||||||||||
|
This document provides guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers. | |||||||||||||
| draft-ietf-tsvwg-sctp-dtls-chunk-04.txt | ||||||||||||||
| Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document describes a method for adding Datagram Transport Layer Security (DTLS) based authentication and cryptographic protection to the Stream Control Transmission Protocol (SCTP). This SCTP extension is intended to enable communication privacy for applications that use SCTP as their transport protocol and allows applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. Once enabled, this also applies to the SCTP payload as well as the SCTP control information. Applications using this SCTP extension can use most of the transport features provided by SCTP and its other extensions. The use of the SCTP Authentication extension defined in RFC 4895 is incompatible with the extension defined in this document but would not provide any additional service. This implies that the Dynamic Address Reconfiguration as specified in RFC 5061 can only be used as described in this document. This document obsoletes RFC 6083 and updates RFC 5061. | |||||||||||||
| draft-ietf-tsvwg-udp-ecn-08.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-tvr-applicability-01.txt | ||||||||||||||
| Applicability of TVR YANG Data Models | ||||||||||||||
|
Time-Variant Routing (TVR) is a routing system that is designed to accommodate predicted topology changes caused by internal or external factors. Typical use cases include resource preservation networks, operating efficiency networks, and dynamic reachability networks. This document provides examples of how to implement the TVR scheduling capabilities for key use cases. It describes which part of the TVR data model is used and why. It also outlines operational and security considerations when deploying TVR-based technologies. | |||||||||||||
| draft-ietf-tvr-off-path-exposure-03.txt | ||||||||||||||
| Using off-path mechanisms for exposing Time-Variant Routing information | ||||||||||||||
|
Time-Variant Routing (TVR) involves predictable, scheduled changes to network topology elements such as nodes, links, and adjacencies that impact routing behavior over time. All those changes can alter the connectivity in the network in a predictable manner, which is known as Time-Variant Routing (TVR). This document proposes mechanisms for exposing TVR information to both internal and external applications, focusing on off-path solutions that decouple the advertisement of scheduled changes from the routing control plane signaling. | |||||||||||||
| draft-ietf-tvr-requirements-11.txt | ||||||||||||||
| Time-Variant Routing (TVR) Requirements | ||||||||||||||
|
Time-Variant Routing (TVR) refers to calculating a forwarding path through a network where the time of message transmission (or receipt) is part of the overall route computation. This means that, all things being equal, a TVR computation might produce different results depending on the time that the computation is performed without other detectable changes to the network topology or other cost functions associated with the route. This document introduces requirements for the design and implementation of systems which perform TVR computations. It also explains different aspects of a TVR system which need to be considered during its design. | |||||||||||||
| draft-ietf-tvr-schedule-yang-12.txt | ||||||||||||||
| A YANG Data Model for Scheduled Attributes | ||||||||||||||
|
The YANG data model in this document includes three modules and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity, as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. | |||||||||||||
| draft-ietf-uta-pqc-app-03.txt | ||||||||||||||
| Post-Quantum Cryptography Recommendations for TLS-based Applications | ||||||||||||||
|
Post-quantum cryptography presents new challenges for device manufacturers, application developers, and service providers. This document highlights the unique characteristics of applications and offers best practices for implementing quantum-ready usage profiles in applications that use TLS and supporting protocols such as DNS. | |||||||||||||
| draft-ietf-uta-tls13-iot-profile-25.txt | ||||||||||||||
| TLS/DTLS 1.3 Profiles for the Internet of Things | ||||||||||||||
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. 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/thomas-fossati/draft-tls13-iot. | |||||||||||||
| draft-ietf-v6ops-464xlat-optimization-06.txt | ||||||||||||||
| 464XLAT/MAT-T Optimization | ||||||||||||||
|
IP/ICMP Translation Algorithm (SIIT) can be used to provide access for IPv4-only hosts or applications to IPv4-only or dual-stack destinations over IPv6-only infrastructure. In that case, the traffic flows are translated twice: first from IPv4 to IPv6 (stateless NAT46 at the ingress point to the IPv6-only infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at the egress point). When the destination is IPv6-enabled, the second translation might be avoided. This document describes a possible optimization to 464XLAT and MAP-T to avoid translating IPv6 flows back to IPv4 if the destination is reachable over IPv6. The proposed solution would significantly reduce the NAT64 utilization in the operator's network, increasing the performance. | |||||||||||||
| draft-ietf-v6ops-6mops-10.txt | ||||||||||||||
| IPv6-mostly Networks: Deployment and Operations Considerations | ||||||||||||||
|
This document discusses a deployment scenario called "an IPv6-mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). The proposed approach enables smooth and incremental transition from dual-stack to IPv6-only network by allowing IPv6-capable devices to remain IPv6-only while the network is seamlessly supplying IPv4 to those that require it. | |||||||||||||
| draft-ietf-v6ops-aaaa-filtering-01.txt | ||||||||||||||
| A recommendation for filtering address records in stub resolvers | ||||||||||||||
|
Since IPv4 and IPv6 addresses are represented by different resource records in the Domain Name System, operating systems capable of running both IPv4 and IPv6 need to execute two queries when resolving a host name. This document discusses the conditions under which a stub resolver can optimize the process by not sending one of the queries if the host is connected to a single-stack network. | |||||||||||||
| draft-ietf-v6ops-claton-16.txt | ||||||||||||||
| 464XLAT Customer-side Translator (CLAT): Node Behavior and Recommendations | ||||||||||||||
|
464XLAT defines an architecture for providing IPv4 connectivity across an IPv6-only network. The solution involves two functional elements: a provider-side translator (PLAT) and a customer-side translator (CLAT). This document updates the 464XLAT specification (RFC6877) and Requirements for IPv6 Customer Edge Routers (RFC8585) by further defining CLAT node behavior and IPv6 Customer Edge Routers to support IPv4-as-a-Service by providing recommendations for node developers on enabling and disabling CLAT. | |||||||||||||
| draft-ietf-v6ops-framework-md-ipv6only-underlay-27.txt | ||||||||||||||
| Framework for Multi-domain IPv6-only Underlay Network and IPv4-as-a-Service | ||||||||||||||
|
For the IPv6 transition, IPv6-only is considered the final stage where only IPv6 protocol is used for transport while maintaining global reachability for both IPv6 and IPv4 services. This document introduces a framework for a multi-domain IPv6-only underlay network from the perspective of network providers. In particular, it proposes stateless address mapping as the basis for enabling IPv4 service data transmission in a multi-domain IPv6-only environment (i.e., IPv4-as-a-Service). It describes the methodology of stateless IPv4/IPv6 mapping, illustrates the behaviors of network devices, analyzes the options of IPv6 mapping prefix allocation, and discusses the security considerations. This framework is not intended to replace existing IPv6-only technologies, but rather to leverage or remain compatible with them. | |||||||||||||
| draft-ietf-v6ops-icmpext-xlat-v6only-source-01.txt | ||||||||||||||
| Using Dummy IPv4 Address and Node Identification Extensions for IP/ICMP translators (XLATs) | ||||||||||||||
|
This document suggests that when a source IPv6 address of an ICMPv6 message can not be translated to an IPv4 address, the protocol translators use the dummy IPv4 address (192.0.0.8) to translate the IPv6 source address, and utilize the ICMP extension for Node Identification (draft-ietf-intarea-extended-icmp-nodeid) to carry the original IPv6 source address of ICMPv6 messages. This document obsoletes RFC6791, Stateless Source Address Mapping for ICMPv6 Packets and updates IP/ICMP Translation Algorithm (RFC7915). | |||||||||||||
| draft-ietf-v6ops-ipv6-app-testing-02.txt | ||||||||||||||
| Testing Applications' IPv6 Support | ||||||||||||||
|
This document provides guidance for application developers and software as a service providers on how to approach IPv6 testing in Dual-stack (IPv4+IPv6), and IPv6-only scenarios, including "IPv6- only-strict" scenarios without any connectivity towards any relevant IPv4 endpoint. It discusses common misconceptions about the degree to which operating systems and libraries can abstract IPv6 issues away and explains common regressions to avoid when deploying IPv6 support. | |||||||||||||
| draft-ietf-v6ops-ipv6-only-02.txt | ||||||||||||||
| IPv6-Only and IPv6-Mostly Terminology Definitions | ||||||||||||||
|
This document defines the terminology regarding the usage of expressions such as "IPv6-Only" and "IPv6-Mostly", in order to avoid confusions when using them in IETF and other documents. The goal is that a reference to "IPv6-Only" describes the actual functionality being used in a given scope, not the installed protocol support. | |||||||||||||
| draft-ietf-v6ops-nat64-wkp-1918-08.txt | ||||||||||||||
| Using the Well-Known IPv6 Prefix to Represent Non-Global IPv4 Addresses | ||||||||||||||
|
This document modifies the requirement introduced in Section 3.1 of RFC6052 that IPv4/IPv6 Translators MUST NOT use the Well-Known Prefix 64:ff9b::/96 to represent non-globally reachable IPv4 addresses, such as those defined in RFC1918 or listed in Section 2.2.2 of RFC6890. The proposed change enables IPv6-only nodes to reach IPv4-only services with specific non-globally reachable addresses by leveraging the Well-Known Prefix. This document updates Section 3.1 of RFC6052 ("Restrictions on the Use of the Well-Known Prefix") to allow packets in which an address is composed of the Well-Known Prefix and specific non-globally reachable IPv4 addresses to be translated. | |||||||||||||
| draft-ietf-v6ops-prefix-to-end-sites-00.txt | ||||||||||||||
| IPv6 Prefix Assignment to End-Sites | ||||||||||||||
|
This document describes different alternatives and best current practices for assignment of IPv6 prefixes for end-sites in broadband networks, including considerations about point-to-point links, their size, numbering choices, pool choices, customer prefix assignment size and persistance of those assignments. | |||||||||||||
| draft-ietf-v6ops-rfc6146-bis-16.txt | ||||||||||||||
| Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers | ||||||||||||||
|
This document specifies a stateful NAT64 translation, which allows IPv6-Only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a stateful NAT64 translator are shared among several IPv6-Only clients. Stateful NAT64 translation also supports IPv4-initiated communications to a subset of the IPv6 hosts through configured bindings in the stateful NAT64 translator. When the stateful NAT64 translation is used in conjunction with DNS64, no changes are required in either the IPv6 client or the IPv4 server. This document obsoletes RFC 6146. | |||||||||||||
| draft-ietf-v6ops-rfc7084bis-06.txt | ||||||||||||||
| Basic Requirements for IPv6 Customer Edge Routers | ||||||||||||||
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document obsoletes RFC 7084. | |||||||||||||
| draft-ietf-v6ops-rfc7915-bis-01.txt | ||||||||||||||
| IP/ICMP Translation Algorithm | ||||||||||||||
|
This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 7915. | |||||||||||||
| draft-ietf-vcon-cc-extension-02.txt | ||||||||||||||
| The JSON vCon - Contact Center Extension | ||||||||||||||
|
A vCon is container for data and information relating to a human conversation. This document defines an extension for the JSON vCon schema in support of call, support or contact center application of the vCon conversational data exchange format. | |||||||||||||
| draft-ietf-vcon-privacy-primer-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ietf-vcon-vcon-core-04.txt | ||||||||||||||
| The JSON format for vCon - Conversation Data Container | ||||||||||||||
|
vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. | |||||||||||||
| draft-ietf-webbotauth-httpsig-protocol-00.txt | ||||||||||||||
| HTTP Message Signatures for automated traffic | ||||||||||||||
|
This document describes a protocol for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served. | |||||||||||||
| draft-ietf-webtrans-http2-15.txt | ||||||||||||||
| WebTransport over HTTP/2 | ||||||||||||||
|
WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. | |||||||||||||
| draft-ietf-webtrans-http3-16.txt | ||||||||||||||
| WebTransport over HTTP/3 | ||||||||||||||
|
WebTransport over HTTP/3 is a binding of the WebTransport protocol framework [OVERVIEW] to HTTP/3 [HTTP3]. It provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. WebTransport enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. | |||||||||||||
| draft-ietf-webtrans-overview-13.txt | ||||||||||||||
| The WebTransport Protocol Framework | ||||||||||||||
|
The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which is optional. | |||||||||||||
| draft-ietf-wimse-aims-00.txt | ||||||||||||||
| AI Identity Management System | ||||||||||||||
|
This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. | |||||||||||||
| draft-ietf-wimse-arch-08.txt | ||||||||||||||
| Workload Identity in a Multi System Environment (WIMSE) Architecture | ||||||||||||||
|
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. | |||||||||||||
| draft-ietf-wimse-http-signature-06.txt | ||||||||||||||
| WIMSE Workload-to-Workload Authentication with HTTP Signatures | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document defines one of the mechanisms to provide workload authentication, using HTTP Signatures. While only applicable to HTTP traffic, the protocol provides end-to-end protection of requests (and optionally, responses), even when service traffic is not end-to-end encrypted, that is, when TLS proxies and load balancers are used. Authentication is based on the Workload Identity Token (WIT). | |||||||||||||
| draft-ietf-wimse-identifier-03.txt | ||||||||||||||
| Workload Identifier | ||||||||||||||
|
This document defines a canonical identifier for workloads, referred to as the Workload Identifier. A Workload Identifier is a URI that uniquely identifies a workload within the context of a specific trust domain. This identifier can be embedded in Workload Identity Credentials, including X.509 certificates and JWT-based tokens, to support authentication, authorization, and policy enforcement across diverse systems. The Workload Identifier format ensures interoperability, facilitates secure identity federation, and enables consistent identity semantics. | |||||||||||||
| draft-ietf-wimse-mutual-tls-02.txt | ||||||||||||||
| Workload Authentication Using Mutual TLS | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). | |||||||||||||
| draft-ietf-wimse-workload-creds-02.txt | ||||||||||||||
| WIMSE Workload Credentials | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. | |||||||||||||
| draft-ietf-wimse-workload-identity-practices-06.txt | ||||||||||||||
| Workload Identity Practices | ||||||||||||||
|
This document describes industry practices for providing secure identities to workloads in container orchestration, cloud platforms, and other workload platforms. It explains how workloads obtain credentials for external authentication purposes, without managing long-lived secrets directly. It does not take into account the standards work in progress for the WIMSE architecture and associated protocols. | |||||||||||||
| draft-ietf-wimse-wpt-02.txt | ||||||||||||||
| WIMSE Workload Proof Token | ||||||||||||||
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from basic deployments to complex multi-service, multi-cloud, multi-tenant systems. This document specifies the Workload Proof Token (WPT), a mechanism for workloads to prove possession of the private key associated with a Workload Identity Token (WIT). The WPT is a signed JWT that binds the workload's authentication to a specific HTTP request, providing application-layer proof of possession for workload-to-workload communication. This specification is designed to work alongside the WIT credential format defined in draft-ietf- wimse-workload-creds and can be combined with other WIMSE protocols in multi-hop call chains. | |||||||||||||
| draft-ietf-wish-whep-04.txt | ||||||||||||||
| WebRTC-HTTP Egress Protocol (WHEP) | ||||||||||||||
|
This document describes a simple HTTP-based protocol that will allow WebRTC-based viewers to watch content from streaming services and/or Content Delivery Networks (CDNs) or WebRTC Transmission Network (WTNs). | |||||||||||||
| draft-ihlar-poem-quic-01.txt | ||||||||||||||
| A Protocol for Periodic On-path Explicit Measurement | ||||||||||||||
|
This document defines the Periodic On-path Explicit Measurement (POEM) protocol, which enables passive on-path measurement of packet loss for QUIC flows. POEM uses periodic marker packets, coalesced with ordinary QUIC packets, that allow on-path network elements to measure upstream packet loss by counting packets between markers. Marker packets also carry a sender-reported loss count, enabling observers to distinguish upstream from downstream loss. Additionally, POEM defines a report mechanism through which network elements communicate measurement results back to endpoints. | |||||||||||||
| draft-ihlesong-mpls-mna-signaling-04.txt | ||||||||||||||
| Discovering MNA Capabilities Using LSP Ping | ||||||||||||||
|
This document defines a mechanism for discovering MPLS Network Actions (MNA) capabilities along a Label Switched Path (LSP) using the LSP Ping echo request/reply mechanism defined in RFC 8029. The In-Stack MNA capabilities include the Readable Label Depth (RLD), the maximum sizes of differently scoped Network Action Sub-stacks (MLD_NAS), and supported In-Stack network action opcodes. The Post- Stack MNA capabilities include the maximum Post-Stack MPLS Header size (MLD_PSMH), the Readable Label Depth including the Post-Stack MPLS Header (RLD_PSMH), and supported Post-Stack network action opcodes. This mechanism allows the ingress Label Edge Router (LER) to discover MNA capabilities of each transit and egress node on the path, enabling correct construction of MPLS label stacks containing MNA network actions. | |||||||||||||
| draft-ihsanullah-dnsid-01.txt | ||||||||||||||
| DNS-Anchored Durable Identity for AI Agents (DNSid) | ||||||||||||||
|
Autonomous software agents are being deployed across enterprise, cloud, and cross-organizational boundaries. These agents negotiate, transact, delegate, and produce work products that persist beyond their own ephemeral runtime. Current standards and initiatives for agent identity collectively address runtime authentication, authorization, lifecycle management, and tool interaction, but a gap remains: a durable, governance-backed identifier that lets a relying party determine and verify the accountable entity behind an agent it encounters, including agents that have since been retired or whose keys have rotated, and attribute past and present work products to that entity. Lifecycle-history verification is governed by the applicable log method and deployment scope. DNSid addresses the accountable layer of identity: the durable ownership anchor that existing agent identity standards do not provide. This document specifies DNSid, a minimal identity primitive that assigns each agent a Fully Qualified Domain Name (FQDN), binds it to an accountable entity identified by a DNS domain under that entity's control, and publishes a structured set of pointers in DNS TXT records to the agent's cryptographic keys, lifecycle log, and operational status. DNSid uses accountable-entity-controlled signatures for record integrity and an abstract append-only lifecycle log for history. It is designed to sit beneath existing identity, authentication, authorization, and agent interaction standards without competing with them. DNSid introduces no new DNS resource record types, opcodes, or response codes, and requires no changes to DNS resolvers, authoritative servers, or the DNS protocol. It applies to any agent that can be assigned an FQDN whose accountable entity can publish verification material; public discoverability of the agent is not required. | |||||||||||||
| draft-illyes-aipref-cbcp-04.txt | ||||||||||||||
| Crawler best practices | ||||||||||||||
|
This document describes best practices for web crawlers. 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/garyillyes/cbcp. | |||||||||||||
| draft-illyes-repext-03.txt | ||||||||||||||
| Robots Exclusion Protocol Extension for URL Level Control | ||||||||||||||
|
This document extends RFC9309 by specifying additional URL level controls through an HTTP response header and, for historical reasons, through HTML meta tags originally developed in 1996. Additionally it moves the HTTP response header out of the experimental header space (i.e., "X-") and defines the combinability of multiple headers, which was previously not possible. | |||||||||||||
| draft-illyes-webbotauth-cbcp-00.txt | ||||||||||||||
| Crawler best practices | ||||||||||||||
|
This document describes best practices for web crawlers. 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/garyillyes/cbcp. | |||||||||||||
| draft-illyes-webbotauth-jafar-00.txt | ||||||||||||||
| A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients | ||||||||||||||
|
This document defines a standardized JSON format for operators of automated HTTP clients (e.g., web crawlers, AI bots) to publicly disclose their IP address ranges. A consistent, machine-readable format for IP range publication simplifies the task of identifying and verifying legitimate automated traffic, thereby decreasing maintenance load on website operators while reducing the risk of inadvertently blocking beneficial clients. This specification codifies and extends common existing practices to provide a simple yet extensible format that accommodates a variety of use cases. | |||||||||||||
| draft-imcode-rfc-oop-c-00.txt | ||||||||||||||
| Object-Oriented Programming Standard for Pure C | ||||||||||||||
|
This document defines RFC-OOP-C, a standard for object-oriented programming in pure C. It specifies naming conventions, class structure macros, method macros, validation macros, memory allocation patterns, lifecycle management, build-level configuration, struct versioning, Doxygen documentation requirements, and a conformance checker interface (the RFC-OOP-C Conformance Checker, RFC_Checker). The standard targets C11 (ISO/IEC 9899:2011) and is applicable to any C project on any microcontroller or platform whose toolchain supports C11. Supplementary guidance is provided for embedded systems including thread-safety and memory allocation strategies compatible with bare-metal, FreeRTOS and embOS. | |||||||||||||
| draft-infantado-agent-memory-architecture-00.txt | ||||||||||||||
| Architecture and Data Model for Persistent Memory in Agentic Systems | ||||||||||||||
|
Memory in current agentic systems is often fragmented across model- provider features, application databases, session histories, framework-specific stores, unstructured files, and retrieval indexes. This document distinguishes temporary context supplied to an inference request from persistent memory that remains addressable, machine-readable, and governed beyond a single request. It specifies a provider-independent architecture and data model for persistent memory in agentic systems based on Memory Scope isolation, typed and versioned Memory Objects, machine-readable provenance, append-only Event Ledger history, separate lifecycle, availability, retention, and validation state, and isolated Derived Indexes and Embedding Spaces. The architecture separates a transient Compute Plane from an authoritative Persistent State Plane and treats embeddings, lexical indexes, graph projections, generated retrieval summaries, ranking caches, and retrieval caches as non-authoritative derived state. The architecture is independent of model provider, storage engine, and protocol transport while allowing future bindings and multiple independent implementations. It does not claim that related systems or standards do not exist; rather, it defines a common architectural vocabulary and interoperability target for persistent agentic memory. | |||||||||||||
| draft-intesigroup-dlts-13.txt | ||||||||||||||
| Distributed Ledger Time-Stamp | ||||||||||||||
|
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. | |||||||||||||
| draft-intra-handshake-fail-32.txt | ||||||||||||||
| Intra-handshake (aka Early) Attestation Considered Harmful (CVE-2026-33697 of CVSS 7.5 and several other CVEs of up to expected CVSS 10.0 upcoming) | ||||||||||||||
|
The draft aims to provide technical details of CVE-2026-33697 (https://www.cve.org/CVERecord?id=CVE-2026-33697), EUVD-2026-16488 (https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488), and several GitHub Security Advisories (GHSAs) which provide substantial technical evidence of how *intra*-handshake (aka early) attestation fails in practice, even _without physical access_. Moreover, since continuous attestation is generally required [CSA-eBPF] [MITRE-Continuous-Attestation], *intra*-handshake attestation adds *unnecessary complexity*. The results are backed by the research [Intra-handshake.fail], [TLS-RA] and the artifacts [Intra-handshake.fail-repo] in state-of-the-art formal analysis tool, ProVerif, under Apache-2.0 license for reproducibility and review, and have been acknowledged by the relevant stakeholders. Currently, there are *two CVEs of CVSS 7.5, one GHSA of 9.0-10.0, two GHSAs of CVSS 9.1, one GHSA of CVSS 7.8, seven GHSAs of CVSS 7.4, and one GHSA of CVSS 6.3 published against the broader intra-handshake (aka early) attestation covering all layers of the ecosystem up to the application*. The research papers on these are currently either under submission or being prepared for submission. The artifacts of these papers will be shared with the community under Apache-2.0 license for reproducibility and review. In our analysis, the remaining implementations of early attestation -- Edgeless Systems Contrast and Meta's AI -- remain vulnerable. | |||||||||||||
| draft-inuidgroup-inuid-00.txt | ||||||||||||||
| Internet Unique ID (INUID) Protocol Specification | ||||||||||||||
|
This document specifies the Internet Unique ID (INUID) protocol, a 128-bit network-layer protocol designed to decouple endpoint identity from topological location. INUID introduces a hierarchical addressing model, fixed-size header layout, mandatory cryptographic source verification, and explicit support for mobility and multihoming without requiring upper-layer session re-establishment. INUID is intended to address several persistent weaknesses in contemporary internetworking, including inadequate source authenticity, unsustainable routing table growth, and the operational complexity of legacy transition mechanisms. The protocol is designed for efficient hardware forwarding, strong anti-spoofing guarantees, and scalable inter-domain routing behavior. | |||||||||||||
| draft-iplir-protocol-10.txt | ||||||||||||||
| IPlir network layer security protocol | ||||||||||||||
|
This document specifies the IPlir network layer security protocol. It describes how to provide a set of security services for traffic over public and corporate networks using the TCP/IP stack. | |||||||||||||
| draft-ipsecme-rfc7402-beet-update-00.txt | ||||||||||||||
| 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] | |||||||||||||
| draft-irtf-cfrg-aead-limits-13.txt | ||||||||||||||
| Usage Limits on AEAD Algorithms | ||||||||||||||
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | |||||||||||||
| draft-irtf-cfrg-aegis-aead-18.txt | ||||||||||||||
| The AEGIS Family of Authenticated Encryption Algorithms | ||||||||||||||
|
This document describes the AEGIS-128L, AEGIS-256, AEGIS-128X, and AEGIS-256X AES-based authenticated encryption algorithms designed for high-performance applications. The document is a product of the Crypto Forum Research Group (CFRG). It is not an IETF product and is not a standard. 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/cfrg/draft-irtf-cfrg-aegis-aead. | |||||||||||||
| draft-irtf-cfrg-bbs-blind-signatures-03.txt | ||||||||||||||
| Blind BBS Signatures | ||||||||||||||
|
This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Crypto Forum Research Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/cfrg. Source for this draft and an issue tracker can be found at https://github.com/cfrg/draft-irtf-cfrg-bbs-blind-signatures. | |||||||||||||
| draft-irtf-cfrg-bbs-per-verifier-linkability-03.txt | ||||||||||||||
| BBS per Verifier Linkability | ||||||||||||||
|
The BBS Signatures scheme describes a multi-message digital signature, that supports selectively disclosing the messages through unlinkable presentations, built using zero-knowledge proofs. Each BBS proof reveals no information other than the signed messages that the Prover chooses to disclose in that specific instance. As such, the Verifier (i.e., the recipient) of the BBS proof, may not be able to track those presentations over time. Although in many applications this is desirable, there are use cases that require the Verifier be able to track the BBS proofs they receive from the same Prover. Examples include monitoring the use of access credentials for abnormal activity, assertion of pseudonymous identity, monetization, etc.. This document provides a mechanism for binding prover secret material for pseudonym creation to a BBS signature and shows how to use this bound information for the creation of context dependent pseudonyms in BBS proofs. | |||||||||||||
| draft-irtf-cfrg-bls-signature-07.txt | ||||||||||||||
| BLS Signatures | ||||||||||||||
|
BLS is a digital signature scheme with aggregation properties. Given set of signatures (signature_1, ..., signature_n) anyone can produce an aggregated signature. Aggregation can also be done on secret keys and public keys. Furthermore, the BLS signature scheme is deterministic, non-malleable, and efficient. Its simplicity and cryptographic properties allows it to be useful in a variety of use- cases, specifically when minimal storage space or bandwidth are required. | |||||||||||||
| draft-irtf-cfrg-concrete-hybrid-kems-04.txt | ||||||||||||||
| Concrete Hybrid PQ/T Key Encapsulation Mechanisms | ||||||||||||||
|
PQ/T Hybrid Key Encapsulation Mechanisms (KEMs) combine "post- quantum" cryptographic algorithms, which are safe from attack by a quantum computer, with "traditional" algorithms, which are not. CFRG has developed a general framework for creating hybrid KEMs. In this document, we define concrete instantiations of this framework to illustrate certain properties of the framework and simplify implementors' choices. | |||||||||||||
| draft-irtf-cfrg-cpace-21.txt | ||||||||||||||
| CPace,a balanced composable PAKE | ||||||||||||||
|
This document describes CPace which is a protocol that allows two parties that share a low-entropy secret (password) to derive a strong shared key without disclosing the secret to offline dictionary attacks. The CPace protocol was tailored for constrained devices and can be used on groups of prime- and non-prime order. | |||||||||||||
| draft-irtf-cfrg-cryptography-specification-03.txt | ||||||||||||||
| Guidelines for Writing Cryptography Specifications | ||||||||||||||
|
This document provides guidelines and best practices for writing technical specifications for cryptography protocols and primitives, targeting the needs of implementers, researchers, and protocol designers. It highlights the importance of technical specifications and discusses strategies for creating high-quality specifications that cater to the needs of each community, including guidance on representing mathematical operations, security definitions, and threat models. | |||||||||||||
| draft-irtf-cfrg-dnhpke-08.txt | ||||||||||||||
| Deterministic Nonce-less Hybrid Public Key Encryption | ||||||||||||||
|
This document describes enhancements to the Hybrid Public Key Encryption standard published by CFRG. These include use of "compact representation" of relevant public keys, support for key-wrapping, and a way to address the use of HPKE on lossy networks | |||||||||||||
| draft-irtf-cfrg-fiat-shamir-03.txt | ||||||||||||||
| Fiat-Shamir Transformation | ||||||||||||||
|
This document describes the Fiat-Shamir transformation, which allows making a public-coin protocol non-interactive by means of a cryptographic hash function. It specifies how the hash function is employed, how prover messages are encoded as hash-function input, and how verifier messages are decoded from the hash function's output, as well as the serialization and deserialization of the non-interactive argument string. | |||||||||||||
| draft-irtf-cfrg-hybrid-kems-12.txt | ||||||||||||||
| Hybrid PQ/T Key Encapsulation Mechanisms | ||||||||||||||
|
This document defines generic constructions for hybrid Key Encapsulation Mechanisms (KEMs) based on combining a post-quantum (PQ) KEM with a traditional cryptographic component. Hybrid KEMs built using these constructions provide strong security properties as long as either of the underlying algorithms are secure. | |||||||||||||
| draft-irtf-cfrg-kemeleon-02.txt | ||||||||||||||
| Kemeleon Encodings | ||||||||||||||
|
This document specifies Kemeleon encoding algorithms for encoding ML- KEM encapsulation keys and ciphertexts as random bytestrings. Kemeleon encodings provide obfuscation of encapsulation keys and ciphertexts, relying on module LWE assumptions. | |||||||||||||
| draft-irtf-cfrg-pairing-friendly-curves-14.txt | ||||||||||||||
| Pairing-Friendly Curves | ||||||||||||||
|
Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and they can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security; however, it ensures no more than the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and consider them at the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. This memo also specifies the serialization and deserialization of the points and scalars that protocols exchange, restating a format that is already in widespread use, and states which of the remaining decisions belong to the calling protocol. | |||||||||||||
| draft-irtf-cfrg-rsa-guidance-10.txt | ||||||||||||||
| Implementation Guidance for the PKCS #1 RSA Cryptography Specification | ||||||||||||||
|
This document lists additions to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side- channel attacks. It also recommends against the RSAES-PKCS-v1_5 encryption scheme, and provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. The document is a product of the Crypto Forum Research Group (CFRG). | |||||||||||||
| draft-irtf-cfrg-sigma-protocols-03.txt | ||||||||||||||
| Sigma Proofs for Linear Relations | ||||||||||||||
|
This document describes Sigma Protocols for proving knowledge of preimages of linear maps in prime-order elliptic curve groups. These are sometimes also called _Maurer Proofs_, or _proofs of knowledge of a preimage of a group homomorphism_. Examples include zero-knowledge proofs for discrete logarithm relations, ElGamal encryptions, Pedersen commitments, and range proofs. | |||||||||||||
| draft-irtf-cfrg-signature-key-blinding-11.txt | ||||||||||||||
| Key Blinding for Signature Schemes | ||||||||||||||
|
This document describes extensions to existing digital signature schemes for key blinding. The core property of signing with key blinding is that a blinded public key and all signatures produced using the blinded key pair are independent of the unblinded key pair. Moreover, signatures produced using blinded key pairs are indistinguishable from signatures produced using unblinded key pairs. This functionality has a variety of applications, including Tor onion services and privacy-preserving airdrop for bootstrapping cryptocurrency systems. | |||||||||||||
| draft-irtf-cfrg-vdaf-22.txt | ||||||||||||||
| Verifiable Distributed Aggregation Functions | ||||||||||||||
|
This document describes Verifiable Distributed Aggregation Functions (VDAFs), a family of multi-party protocols for computing aggregate statistics over user measurements. These protocols are designed to ensure that, as long as at least one aggregation server executes the protocol honestly, individual measurements are never seen by any server in the clear. At the same time, VDAFs allow the servers to detect if a malicious or misconfigured client submitted an invalid measurement. Two concrete VDAFs are specified, one for general- purpose aggregation (Prio3) and another for heavy hitters (Poplar1). This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. | |||||||||||||
| draft-irtf-gaia-circular-device-practices-00.txt | ||||||||||||||
| Operational Practices for Digital Autonomy and Meaningful Connectivity through Circular Management of User and Network Devices | ||||||||||||||
|
This document systematizes operational practices observed across multiple community-centred deployments that aim to improve meaningful connectivity and community digital autonomy through the circular management of end-user and network devices. It is published as an Informational RFC on the IRTF stream and does not define Internet standards or protocol requirements. The document addresses a foundational but often overlooked dependency of Internet connectivity deployments: the availability, repairability, governance, sharing, reuse, and lifecycle management of network and end-user devices required for meaningful participation in the Internet. Based on operational experience from deployments in Spain, Argentina, and Senegal, this document describes practices that have demonstrated positive outcomes for connectivity, social inclusion and community capacity, and environmental sustainability. These practices are presented as descriptive guidance derived from operational experience rather than as normative requirements. They complement research within the IRTF GAIA Research Group by documenting reproducible approaches that improve the sustainability, autonomy, and long-term viability of community connectivity infrastructure and meaningful participation in underserved contexts. | |||||||||||||
| draft-irtf-iccrg-ledbat-plus-plus-06.txt | ||||||||||||||
| LEDBAT++: Congestion Control for Background Traffic | ||||||||||||||
|
This memo describes LEDBAT++, a set of enhancements to the LEDBAT (Low Extra Delay Background Transport) congestion control algorithm for background traffic. The LEDBAT congestion control algorithm has several shortcomings that prevent it from working effectively in practice. LEDBAT++ extends LEDBAT by adding a set of improvements, including reduced congestion window gain, modified slow-start, multiplicative decrease and periodic slowdowns. This set of improvement mitigates the known issues with the LEDBAT algorithm, such as latency drift, latecomer advantage and inter-LEDBAT fairness. LEDBAT++ has been implemented as a TCP congestion control algorithm in the Windows operating system. LEDBAT++ has been deployed in production at scale on a variety of networks and been experimentally verified to achieve the original stated goals of LEDBAT. This document is a product of the Internet Congestion Control Research Group (ICCRG) of the Internet Research Task Force (IRTF). | |||||||||||||
| draft-irtf-iccrg-pacing-04.txt | ||||||||||||||
| Pacing in Transport Protocols | ||||||||||||||
|
Applications or congestion control mechanisms can produce bursty traffic, which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. | |||||||||||||
| draft-irtf-icnrg-ccnxchunking-05.txt | ||||||||||||||
| CCNx Content Object Chunking | ||||||||||||||
|
This document specifies a chunking protocol for dividing a user payload into CCNx Content Objects. It defines a name segment type to identify each sequential chunk number and a Content Object field to identify the last available chunk number. This includes specification for the naming convention to use for the chunked payload and a field added to a Content Object to represent the last chunk of an object. This document updates RFC8569 and RFC8609. | |||||||||||||
| draft-irtf-icnrg-ccnxversioning-01.txt | ||||||||||||||
| CCNx Content Versioning | ||||||||||||||
|
This document defines a method for content versioning in CCNx, enabling the differentiation of content published under the same name using version numbers. This document updates RFC8569 [RFC8569] and RFC8609 [RFC8609]. | |||||||||||||
| draft-irtf-nmrg-ai-challenges-06.txt | ||||||||||||||
| Research Challenges in Coupling Artificial Intelligence and Network Management | ||||||||||||||
|
This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require coupling with Artificial Intelligence (AI) solutions. On the one hand, many difficult NM problems still lack good solutions, or existing approaches come with significant limitations. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, due to the high computational costs of AI solutions and stringent data privacy constraints, the distributed execution of AI workloads has become paramount. Consequently, networks must be operated efficiently to sustain these distributed processing requirements. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have already been coupled together or could benefit from a closer integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming that solving these challenges will help to reduce the gap between NM and AI. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. | |||||||||||||
| draft-irtf-nmrg-ai-deploy-03.txt | ||||||||||||||
| Considerations of network/system for AI services | ||||||||||||||
|
As the development of AI technology has matured and AI technology has begun to be applied in various fields, the execution environment has evolved from dedicated high-performance servers to commodity servers and affordable, small-scale hardware, including microcontrollers, low-performance CPUs, and AI chipsets. This document outlines how to configure the network and system for an AI inference service, providing AI services in a distributed manner. It also outlines the factors to consider when a client connects to a cloud server and an edge device to request an AI service. It describes some use cases for deploying network-based AI services, such as self-driving vehicles and network digital twins. | |||||||||||||
| draft-irtf-nmrg-network-digital-twin-arch-13.txt | ||||||||||||||
| Network Digital Twin (NDT): Concepts and Reference Architecture | ||||||||||||||
|
The application of Digital Twin technology in the networking field is meant to develop various rich network applications, realize efficient and cost-effective data-driven network management, and accelerate network innovation. This document presents an overview of the concept of Network Digital Twin (NDT), provides the basic definitions and a reference architecture, lists a set of application scenarios, and discusses such technology's benefits and key challenges. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. | |||||||||||||
| draft-irtf-qirg-qi-multiplane-arch-02.txt | ||||||||||||||
| A Multiplane Architecture Proposal for the Quantum Internet | ||||||||||||||
|
A consistent reference architecture model for the Quantum Internet is required to progress in its evolution, providing a framework for the integration of the protocols applicable to it, and enabling the advance of the applications based on it. This model has to satisfy three essential requirements: agility, so it is able to adapt to the evolution of quantum communications base technologies, sustainability, with open availability in technological and economical terms, and pliability, being able to integrate with the operations and management procedures in current networks. This document proposes such an architecture framework, with the goal of providing a conceptual common framework for the integration of technologies intended to build the Quantum Internet infrastructure and its integration with the current Internet. The framework is based on the already extensive experience in the deployment of QKD network infrastructures and on related initiatives focused on the integration of network infrastructures and services. | |||||||||||||
| draft-irtf-t2trg-rest-iot-19.txt | ||||||||||||||
| Guidance on RESTful Design for Internet of Things Systems | ||||||||||||||
|
This document gives guidance for designing Internet of Things (IoT) systems that follow the principles of the Representational State Transfer (REST) architectural style. This document is a product of the IRTF Thing-to-Thing Research Group (T2TRG). | |||||||||||||
| draft-irtf-t2trg-security-setup-iot-devices-07.txt | ||||||||||||||
| Terminology and processes for initial security setup of IoT devices | ||||||||||||||
|
This document provides an overview of terms that are commonly used when discussing the initial security setup of Internet of Things (IoT) devices. This document also presents a brief but illustrative survey of protocols and standards available for initial security setup of IoT devices. For each protocol, we identify the terminology used, the entities involved, the initial assumptions, the processes necessary for completion, and the knowledge imparted to the IoT devices after the setup is complete. | |||||||||||||
| draft-irtf-t2trg-taxonomy-manufacturer-anchors-21.txt | ||||||||||||||
| A Taxonomy of operational security considerations for manufacturer installed keys and Trust Anchors | ||||||||||||||
|
This document provides a taxonomy of methods used by manufacturers of silicon and devices to secure private keys and public trust anchors. This deals with two related activities: how trust anchors and private keys are installed into devices during manufacturing, and how the related manufacturer held private keys are secured against disclosure. This document does not evaluate the different mechanisms, but rather just serves to name them in a consistent manner in order to aid in communication. // This document is a product of the Internet Research Task Force // (IRTF). The IRTF publishes the results of Internet-related // research and development activities. These results might not be // suitable for deployment. | |||||||||||||
| draft-iupa-ngg-multicast-publishing-01.txt | ||||||||||||||
| NG-Multicast-Publishing Protocol | ||||||||||||||
|
This document defines the NG-Multicast-Publishing protocol, which is used to distribute free eBooks, publication metadata, and copyright information over IPv4/IPv6 multicast networks in an efficient and reliable manner. The protocol employs a one-to-many, unidirectional communication model and supports Any-Source Multicast (ASM). It is intended for use by libraries, educational institutions, and individual receivers worldwide. Design goals include very low resource consumption, no requirement for an uplink channel, permanently assigned multicast addresses, and end-to-end integrity verification. | |||||||||||||
| draft-jabley-dnsop-local-signing-algorithm-policy-00.txt | ||||||||||||||
| Supporting Quantum-Safe Algorithms in DNSSEC with Local Resolver Policy | ||||||||||||||
|
Security-aware resolvers validate signatures, where available, in order to protect their clients from inauthentic data. DNSSEC treats all algorithms as equal when it comes to validation, such that a single valid signature is considered sufficient proof of authenticity, and that data is only to be judged to be inauthentic if all available signatures are found to be invalid. However, a resolver might have a different local policy, e.g. in its handling of quantum-safe signatures. This document discusses such local policy and describes a means to indicate to a client that specific local policy has been applied to response validation. | |||||||||||||
| draft-jabley-dnsop-no-longer-support-any-00.txt | ||||||||||||||
| Continuing to Reduce Support for ANY Queries in the DNS | ||||||||||||||
|
The DNS specification from its earliest day supported a special query type (QTYPE) ANY. The handling of queries with QTYPE=ANY is observed to vary between implementations. Queries with QTYPE=ANY are known to facilitate amplification that can be abused and used by malicious actors to attack third parties, and minimally-sized responses are often constructed in order to mitigate those security risks. While queries with QTYPE=ANY can be used for troubleshooting in some cases, the substantial inconsistency in how such queries are handled makes them at best an unreliable signal. This document continues a careful and gradual process of dropping support for QTYPE=ANY from the DNS. | |||||||||||||
| draft-jabley-dnsop-ordered-answer-section-01.txt | ||||||||||||||
| Ordering of RRSets in DNS Message Sections | ||||||||||||||
|
The existing Domain Name System (DNS) specifications lack some clarity in their description of the process by which individual sections of a DNS message are constructed. This document updates RFC 1034 and RFC 1035 to provide a clearer specification, consistent with deployed implementations. | |||||||||||||
| draft-jabley-dnsop-zone-cut-to-nowhere-01.txt | ||||||||||||||
| Signalling a Zone Cut to Nowhere in the DNS | ||||||||||||||
|
This document defines a standard mechanism to signal the existence of a DNS zone cut without specifying authoritative nameservers for the delegated child zone. This "zone cut to nowhere" is particularly useful in split-horizon environments, allowing parent zones to explicitly signal that a child zone exists but is only resolvable within a private namespace. | |||||||||||||
| draft-jackson-csp-reporting-policy-00.txt | ||||||||||||||
| DNS-Published Content Security Policy Reporting Policy | ||||||||||||||
|
This document specifies a mechanism by which a domain operator can publish a Content Security Policy reporting endpoint policy in the Domain Name System. The mechanism allows user agents and reporting processors to discover one or more domain-authorised endpoints for receiving Content Security Policy violation reports, independently of the HTTP response that triggered the report. The mechanism is intended to improve administrative consistency across distributed web estates where the domain operator controls DNS but does not consistently control every web server, content management system, proxy, application stack, or hosting platform serving content beneath the domain. This document does not define DNS-based CSP enforcement. It defines only DNS-published reporting endpoint policy. User agents MUST NOT treat this mechanism as a replacement for the Content-Security-Policy or Content-Security-Policy-Report-Only HTTP response header fields. | |||||||||||||
| draft-jacobs-web4-assessment-assertions-00.txt | ||||||||||||||
| Web4 Assessment Assertions | ||||||||||||||
|
This document defines an implementation-neutral envelope for externally presented assessment results, including subject, issuer, policy, result, validity, evidence commitments, proof, and current status, while protected methods remain confidential. | |||||||||||||
| draft-jacobs-web4-claims-verification-00.txt | ||||||||||||||
| Web4 Claims and Verification | ||||||||||||||
|
This document distinguishes claims, evidence, assessments, assertions, verification events, challenges, supersession, suspension, expiration, revocation, and receipts without standardizing private scoring internals. | |||||||||||||
| draft-jacobs-web4-delegated-authority-00.txt | ||||||||||||||
| Web4 Delegated Authority | ||||||||||||||
|
This document defines signed, bounded, time-limited, and revocable authority mandates for agents and nodes and links governed actions to their authority. | |||||||||||||
| draft-jacobs-web4-evidence-receipts-00.txt | ||||||||||||||
| Web4 Evidence Receipts | ||||||||||||||
|
This document defines durable, cryptographically verifiable receipts for assessment, authority, policy, claim, and node-lifecycle events without requiring publication of protected evidence. | |||||||||||||
| draft-jacobs-web4-federation-architecture-00.txt | ||||||||||||||
| Web4 Federation Architecture Model | ||||||||||||||
|
This document describes a generic architectural model for Web4 federations, as defined in [JACOBS-TERM], covering node admission, tiering, gateway-mediated inter-node transport, and operational health verification. It generalizes patterns observed in a live, operating multi-node federation, offered as a Reference Implementation under the terminology of [JACOBS-TERM], without specifying vendor-internal computational, cryptographic, or coordinate mechanisms. | |||||||||||||
| draft-jacobs-web4-federation-policy-00.txt | ||||||||||||||
| Web4 Federation Policy Advertisement | ||||||||||||||
|
This document defines machine-readable advertisements for federation policies, including authority, versions, profiles, evidence formats, retention, challenges, appeals, revocation, disclosure, jurisdiction, proof, and status. | |||||||||||||
| draft-jacobs-web4-node-state-admission-00.txt | ||||||||||||||
| Web4 Node State and Admission Requirements | ||||||||||||||
|
This document defines implementation-neutral requirements for persistent node identity, declared state, governed admission, suspension, revocation, re-admission, and succession in Web4-class federations. It distinguishes a node from its network and credential representations, identifies the minimum information required for externally inspectable participation, and specifies lifecycle and failure semantics that future protocol bindings can implement. The requirements permit heterogeneous internal architectures and do not mandate a transport, serialization, credential technology, storage system, computational model, or proprietary coordination mechanism. The document extends prior Web4 terminology, conformance, and federation-architecture work by supplying a public requirements layer between architecture and future interoperable bindings. | |||||||||||||
| draft-jacobs-web4-sovereign-entity-comprehension-00.txt | ||||||||||||||
| Web4 Sovereign Entity Comprehension: Requirements and External Conformance Framework | ||||||||||||||
|
This document defines requirements and an external conformance framework for sovereign Machine Entity Comprehension (MEC) systems operating in Internet-connected or Internet-capable environments. MEC is defined as an externally observable capability. A conforming system preserves entity identity across changing contexts, distinguishes similar but separate entities, determines relevant relationships and constraints, responds appropriately to material changes, handles contradictory assertions, and produces repeatable outcomes under equivalent declared conditions. The framework evaluates behavior through controlled inputs, pre- registered reference outcomes, declared system state, and observable outputs. It does not prescribe or disclose internal representations, implementation algorithms, source code, deployment architecture, confidential operational methods, or other implementation-specific mechanisms. The document also defines operational-sovereignty requirements for systems intended to remain under operator control and retain declared core capabilities without dependence on an external intelligence service. A minimal, implementation-neutral conformance record supports comparable reporting across heterogeneous systems. | |||||||||||||
| draft-jacobs-web4-terminology-00.txt | ||||||||||||||
| Web4 Terminology and Definitions | ||||||||||||||
|
This document defines a common vocabulary for describing Web4 systems: federated, sovereign-entity-capable network architectures that extend prior generations of the Web with machine-native comprehension and conformance evaluation. It establishes baseline terminology intended for reference by subsequent Web4 specifications, including but not limited to [JACOBS-MEC], and is written to be independently useful to any implementer or evaluator working with Web4-class systems, regardless of underlying implementation. | |||||||||||||
| draft-jadoon-green-isac-utilization-04.txt | ||||||||||||||
| A YANG Data Model for Reporting Utilization Scores in ISAC | ||||||||||||||
|
This document defines a YANG data model to report an ISAC Utilization Score (US) in Integrated Sensing and Communication (ISAC) systems. The US is an abstract, normalized score (0..100) that summarizes the relative resource cost of executing a sensing operation on a device. The model supports a mandatory overall US and optional explanatory component impact scores (compute, memory, energy, storage, latency). The model also supports optional metadata (e.g., timestamp, aggregation window, and scoring method identification) describing how a reported score was derived. This revision aligns terminology and leaf names to reduce ambiguity between normalized impact scores and raw resource telemetry, removes per-measurement-related objects to keep the model focused on an overall score, and specifies a companion augmentation module (Path 1) that attaches ISAC utilization telemetry to a GREEN Energy Object (as defined by the GREEN Power and Energy YANG Module) for correlation with power/energy telemetry. | |||||||||||||
| draft-jaehwoon-cats-mobility-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jags-intarea-icmp-ext-underlay-info-05.txt | ||||||||||||||
| ICMP extension to include underlay information | ||||||||||||||
|
Network operators managing overlay networks require visibility into underlay network hops during traceroute operations from overlay endpoints. This document defines an ICMP extension object, the Underlay Information Object (UIO), which allows underlay head-end nodes to encapsulate underlay error information within ICMP error messages. This mechanism provides overlay operators with crucial visibility into underlay network paths for troubleshooting. | |||||||||||||
| draft-jain-lisp-network-ai-infra-04.txt | ||||||||||||||
| LISP-Based Network for AI Infrastructure | ||||||||||||||
|
The Locator/Identifier Separation Protocol (LISP) control plane provides the mechanisms to support Scale-Up, Scale-Out and Scale- Across backend networks within AI infrastructure. This document describes how LISP enables a unified control plane architecture that accommodates different scaling technologies, offering flexibility in deployment. By leveraging lisp mechanisms including EID-to-RLOC- mapping/pxTR registrations, publication-subscription and VPN instance-based segmentation ([RFC9300][RFC9301][RFC9437][I-D.ietf- lisp-site-external-connectivity][I-D.ietf-lisp-vpn]), the architecture delivers scalable high bandwidth for large training workloads, ultra-low-latency collective operations, and a simplified control framework that seamlessly spans heterogeneous accelerator fabrics. This approach allows AI/ML applications (whether focused on training or inference) to run workloads efficiently with resiliency on a converged infrastructure, supporting diverse deployment scenarios using the same underlying network fabric. | |||||||||||||
| draft-jakab-dawn-agent-discovery-mdns-00.txt | ||||||||||||||
| Zero-Configuration Agent Discovery | ||||||||||||||
|
Protocols for communication between autonomous software agents typically discover agents through documents retrieved over HTTPS from a well-known URI. This model requires a discovering party to already know an agent's host name or URL, or to consult a centralized catalog. It provides no zero-configuration mechanism for enumerating agents that are present on a local network. This document describes how existing, widely deployed protocols, Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD), can be used to advertise and discover agents on a local link, with no new protocol machinery. It presents a general, protocol-independent two- stage discovery model in which lightweight enumeration over DNS-SD is followed by retrieval of full agent metadata over the agent's native transport. It gives a worked instantiation of that model for the Agent2Agent (A2A) protocol, as an example. | |||||||||||||
| draft-janz-nmrg-inter-agent-conflict-resolution-00.txt | ||||||||||||||
| Sources of Inter-Agent Conflicts and Approaches to Conflict Resolution in Network Management | ||||||||||||||
|
Network management is increasingly carried out by autonomous, AI- driven agents that observe and act on the network and service state they share. Where their scopes overlap - the same managed entities, resources, or objectives - their independent decisions can prove mutually inconsistent, and such inter-agent conflict is, at bottom, coordination that has not been put in place; the two are best studied together. This document maps the problem for network management: where inter-agent conflict comes from, which families of mechanism resolve it, and how those mechanisms are chosen and combined. It then turns that map on a case of current interest in the IETF - the AI-based Network Management Agent (NMA) architecture - and offers six recommendations for strengthening how that architecture handles inter-agent conflict at its Agent-to-Agent interface. | |||||||||||||
| draft-janz-nmrg-naas-agentic-negotiation-00.txt | ||||||||||||||
| Dynamic Network-as-a-Service Life-Cycle Automation Using End-to-End Agent Negotiation | ||||||||||||||
|
This document describes a possible direction for the management of Network-as-a-Service (NaaS), in which the relationship between a service consumer and a provider is treated not as a static contract but as a continuous, automated negotiation conducted on both sides by cognitive software agents. A NaaS whose required bandwidth, latency and availability move continuously cannot be settled once at order time; it is a standing dialogue - intent, quote, agreement and in- life change - that today stops at the customer-operator boundary and is bridged by humans. The document frames that boundary as the unautomated gap, sketches an end-to-end agentic negotiation architecture that closes it, and describes the intent instance as a managed object whose life cycle includes scarcity-driven pricing and closed-loop renegotiation. It maps the architecture onto already- published specifications from several bodies, showing that the direction rests on a standards basis rather than on new protocol invention. Two NaaS settings illustrate its utility. | |||||||||||||
| draft-janz-nmrg-ontology-reconciliation-01.txt | ||||||||||||||
| Automated Agent-to-Agent Ontology Reconciliation for Cognitive Network Management Systems | ||||||||||||||
|
This document describes a possible direction for inter-system communication in network management, in which two cognitive software agents establish between themselves the basis for exchanging information, without depending on a single rigid data model agreed by their implementers in advance. The agents bring relevant knowledge, can extend it through learning, can reason, and can converse in natural language. The approach is framed as a workflow in which each agent makes explicit the ontology implicit in its data model, the two agents address their differences through conversation, and a translator artefact is produced that is then used during ordinary operation. A central property is that language-model inference is consumed during the agents' conversation rather than on each subsequent message. The document situates the direction relative to adjacent work and illustrates it through three use cases drawn from network management. | |||||||||||||
| draft-janz-nmrg-reference-lexicons-00.txt | ||||||||||||||
| Shared Reference Lexicons for Agent-to-Agent Model Reconciliation in Network Management | ||||||||||||||
|
Interoperability between network-management systems is customarily arranged by agreeing a shared data model in advance or, where that falls short, a richer shared information model or ontology; both still require broad prior agreement on a common model. This document, a companion to and enhancement of draft-janz-nmrg-ontology- reconciliation, argues that for systems built as cognitive, language- capable agents the shared reference can instead be a thin reference lexicon: a consultable nomenclature of named entities with disambiguating definitions and examples, free of relationship axioms and attribute schemas, and typically derived from an existing model. Each agent brings the lexicon apt to it; the two are lexically aligned into cross-source correspondences; identity is settled wherever they correspond; and only the residual is reconciled by the conversation of the companion document. The document develops what such a lexicon should contain, the two-stage alignment that relates lexicons across sources, the distinct problem of co-referencing specific instances, and the scaling that follows from anchoring translation on shared references; and it recommends how model authors can make their artefacts more amenable to this automated alignment. | |||||||||||||
| draft-jenkins-cnsa2-cmc-profile-03.txt | ||||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificate Management over CMS | ||||||||||||||
|
This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available here for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8756], the CNSA 1.0 guidance. | |||||||||||||
| draft-jenkins-cnsa2-pkix-profile-05.txt | ||||||||||||||
| Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists | ||||||||||||||
|
This document specifies a profile of X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists for applications that use Commercial National Security Algorithm Suite published by the United States Government. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. This memo is not an IETF standard, and does not represent IETF community consensus. The profile is made publicly available for use by developers and operators of these and any other system deployments. This document obsoletes [RFC8603], the CNSA 1.0 guidance. | |||||||||||||
| draft-jennings-agentproto-mcp-over-moqt-00.txt | ||||||||||||||
| Model Context Protocol and Agent Skills over Media over QUIC Transport | ||||||||||||||
|
This document defines how to use Media over QUIC Transport (MOQT) as the underlying transport protocol for the Model Context Protocol (MCP). MCP enables integration between language model applications and external data sources and tools. MOQT provides publish-subscribe delivery over QUIC and WebTransport with native prioritization, relay caching, and multiplexing. This specification maps MCP messages onto MOQT objects and defines procedures for session establishment, capability discovery, and ongoing communication. It covers MCP's core primitives (resources, tools, prompts, sampling, and notifications) through dedicated MOQT tracks. The document also describes Agent Skills -- composed instructions that extend AI capabilities beyond atomic tool operations -- using progressive loading aligned with MOQT's object-based delivery. | |||||||||||||
| draft-jennings-moq-discovery-02.txt | ||||||||||||||
| DNS and mDNS Discovery for MOQT | ||||||||||||||
|
This document defines how MOQT clients discover server endpoints using DNS and Multicast DNS (mDNS). It specifies SVCB and HTTPS DNS record mappings for the moqt URI scheme, SRV records as a fallback mechanism, and DNS-SD over mDNS for local network discovery. | |||||||||||||
| draft-jennings-moq-mocha-chat-00.txt | ||||||||||||||
| MOCHA Chat: Messaging over MoQ Transport | ||||||||||||||
|
This document specifies the messaging functionality for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how participants send and receive messages in channels using MoQ Transport (MOQT) publish/subscribe primitives. Each device publishes messages on its own track within a channel namespace, enabling decentralized message production with relay-based fan-out. This specification covers message naming, format, causal ordering, delivery, roster management, and channel discovery for text-based chat. | |||||||||||||
| draft-jennings-moq-mocha-identity-00.txt | ||||||||||||||
| MOCHA Identity: Authentication,Authorization,and Federation | ||||||||||||||
|
This document specifies identity, authentication, authorization, and federation for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how users authenticate with Identity Providers (IdPs), how authorization tokens (C4M and Privacy Pass) are issued and validated at relays, how permissions map to MOQT namespaces, and how users from one Provider obtain access to resources on a federated Provider. | |||||||||||||
| draft-jennings-moq-mocha-meetings-00.txt | ||||||||||||||
| MOCHA Meetings: Real-Time Conferencing over MoQ Transport | ||||||||||||||
|
This document specifies how multi-party audio and video meetings are conducted using MOCHA (MoQ Open Communication & Hosting Architecture). It defines namespace conventions, media track design, catalog distribution, and participant flows for real-time conferencing over MoQ Transport (MOQT). This specification supports both simulcast and scalable video codec configurations, enabling meetings ranging from small group calls to large-scale conferences. | |||||||||||||
| draft-jennings-moq-mocha-mls-keying-00.txt | ||||||||||||||
| MOCHA MLS Keying: End-to-End Encryption Key Management over MoQ | ||||||||||||||
|
This document specifies MLS key management for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how MLS groups are created, how members are added and removed, how key material is distributed over MOQT tracks, and how the MLS Delivery Service is realized in a fully distributed manner using MOQT publish/subscribe. For large channels, Partial MLS is used to avoid requiring all members to process every membership change. | |||||||||||||
| draft-jennings-moq-mocha-pab-00.txt | ||||||||||||||
| MOCHA Personal Address Book | ||||||||||||||
|
This document defines how a set of devices owned by a common user synchronize a Personal Address Book (PAB) over MOQT. The address book maps identities to human-readable names and contact information, enabling users to maintain a trusted contact list that is consistent across all their devices. | |||||||||||||
| draft-jennings-moq-mocha-reactions-00.txt | ||||||||||||||
| MOCHA Reactions: Real-Time Reactions over MoQ Transport | ||||||||||||||
|
This document specifies reactions for MOCHA (MoQ Open Communication & Hosting Architecture). It supports message-targeted reactions (emoji on a specific chat message) and standalone reactions (engagement signals such as applause or raised hands). | |||||||||||||
| draft-jeong-nmrg-i2icf-framework-01.txt | ||||||||||||||
| A Framework for the Interface to In-Network Computing Functions (I2ICF) | ||||||||||||||
|
This document specifies a framework to define Interface to In-Network Computing Functions (I2ICF) for user services both on the network- level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF), defined in the context of Network Functions Virtualization (NFV) and Software-Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). This document describes an I2ICF framework, which includes components and interfaces to configure and monitor the ICFs that implement applications and services. | |||||||||||||
| draft-jeong-nmrg-i2icf-problem-statement-01.txt | ||||||||||||||
| Interface to In-Network Computing Functions (I2ICF): Problem Statement | ||||||||||||||
|
This document specifies the problem statement for the Interface to In-Network Computing Functions (I2ICF) for user services both on the network-level and application-level. In-Network Computing Functions (ICF) include In-Network Network Functions (INF) which are defined in the context of Network Functions Virtualization (NFV) and Software- Defined Networking (SDN). ICFs also include In-Network Application Functions (IAF) which appear in the context of Internet-of-Things (IoT) Devices, Software-Defined Vehicles (SDV), and Unmanned Aerial Vehicles (UAV). Intent-Based Networking (IBN) can be used to compose user services and consist of a combination of ICFs in a target network. This document investigates the need for a standard framework with the interfaces for ICFs, in terms of applications with the need to run Artificial Intelligence (AI) in the network and interoperability among multi-vendor ICFs. | |||||||||||||
| draft-jeong-nmrg-ibn-network-management-automation-07.txt | ||||||||||||||
| Intent-Based Network Management Automation in 5G Networks | ||||||||||||||
|
This document describes Network Management Automation (NMA) of cellular network services in 5G networks. For NMA, it proposes a framework empowered with Intent-Based Networking (IBN). The NMA in this document deals with a closed-loop network control, network intent translator, and network management audit. To support these three features in NMA, it specifies an architectural framework with system components and interfaces. Also, this framework can support the use cases of NMA in 5G networks such as the data aggregation of Internet of Things (IoT) devices, network slicing, and the Quality of Service (QoS) in Vehicle-to-Everything (V2X). | |||||||||||||
| draft-jeong-nmrg-intent-based-sdv-framework-00.txt | ||||||||||||||
| An Intent-Based Management Framework for Software-Defined Vehicles in Intelligent Transportation Systems | ||||||||||||||
|
Software-Defined Vehicle (SDV) is a new player towards autonomous vehicles in Intelligent Transportation Systems (ITS). An SDV is constructed by a software platform like a cloud-native system (e.g., Kubernetes) and has its internal network. To facilitate the easy and efficient configuration of networks in the SDV, an intent-based management is an appropriate direction. This document proposes a framework of intent-based management for networks, security, and applications in SDVs so that they can communicate with other SDVs and infrastructure nodes for safe driving and infotainment services in the road networks. | |||||||||||||
| draft-jeong-nmrg-security-management-automation-01.txt | ||||||||||||||
| An I2NSF Framework for Security Management Automation in Cloud-Based Security Systems | ||||||||||||||
|
This document describes a Framework for Interface to Network Security Functions (I2NSF) in [RFC8329] for Security Management Automation (SMA) in Cloud-Based Security Systems. This security management automation facilitates Closed-Loop Security Control, Security Policy Translation, and Security Audit. To support these three features in SMA, this document specifies an extended architecture of the I2NSF framework with new system components and new interfaces. Thus, the SMA in this document can facilitate Intent-Based Security Management with Intent-Based Networking (IBN) in [RFC9315]. | |||||||||||||
| draft-jernalczyk-intentweb-agent-manifest-00.txt | ||||||||||||||
| IntentWeb AgentManifest | ||||||||||||||
|
AgentManifest defines a JSON document that websites can publish to describe identity, trusted knowledge, agent-facing capabilities, structured bindings, risk levels, consent requirements, authentication expectations, audit rules, and policies. The goal is to help AI agents understand what a website knows and what it can safely do before scraping, guessing from visual UI, or executing brittle browser automation. | |||||||||||||
| draft-jeskey-anml-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jesske-ai-enablement-interface-00.txt | ||||||||||||||
| AI enablement interface for multimedia services platforms | ||||||||||||||
|
This document specifies a generic interface enabling the integration between a Multimedia Communication Framework such as a 3GPP IP Multimedia Subsystem and Large Language Models (LLMs) or other AI- based services that perform text, audio, video, image and service processing. A Multimedia Communication framework is a network supporting voice, video and message services as a SIP network or the IMS (IP Multimedia System) defined by 3GPP. The interface is designed to be platform-agnostic and flexible, allowing a connection to different AI platforms e.g. LLMs independent of their underlying technology or deployment environment. This document is inspired by the IMS environment providing data channel capabilities offering a variety of services within the framework. Such an interface allows advanced AI functions such as natural language understanding, semantic analysis, and contextual processing through a standardized, extensible and interoperable interface. This enables the IMS ecosystem to seamlessly adopt and integrate emerging AI technologies to enrich communication services. | |||||||||||||
| draft-jgc-netmod-yang-path-00.txt | ||||||||||||||
| YANG path format (ypath) | ||||||||||||||
|
This document defines ypath (YANG path), a single-line, self- describing path format for referencing nodes in YANG schema trees, YANG instance data, and data filters. A ypath identifies YANG nodes using module-qualified names and list key predicates. The format is closely related to the YANG instance-identifier built-in type but additionally supports schema paths, filter wildcards, regular expression key matching, key value sets, and path enumeration. | |||||||||||||
| draft-jholland-quic-multicast-09.txt | ||||||||||||||
| Multicast Extension for QUIC | ||||||||||||||
|
This document defines a multicast extension to QUIC to enable the efficient use of multicast-capable networks to send identical data streams to many clients at once, coordinated through individual unicast QUIC connections. | |||||||||||||
| draft-jhpark-cfrg-ntruplus-security-considerations-00.txt | ||||||||||||||
| NTRU+ Security Considerations | ||||||||||||||
|
This document describes security considerations for the use of NTRU+ in Internet protocols. NTRU+ is a lattice-based key encapsulation mechanism (KEM) based on the NTRU framework and designed to provide IND-CCA2 security. The document summarizes the scheme structure and parameter sets, and discusses implementation and protocol considerations including key-generation rejection sampling, input validation, pairwise consistency testing, explicit rejection behavior, randomness requirements, and side-channel leakage during decapsulation. It is intended to help protocol designers and implementers use NTRU+ safely in settings such as authenticated key exchange, public key encryption, and KEM-based authentication. | |||||||||||||
| draft-jia-oauth-scope-aggregation-01.txt | ||||||||||||||
| OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows | ||||||||||||||
|
This document describes a scope-aggregated OAuth 2.0 authorization pattern for multi-step AI agent workflows. An AI agent aggregates the scopes required across a workflow and only initiates a single authorization procedure for the aggregated scope. This reduces repeated user consents and multiple authorization round-trips, improving authorization efficiency. | |||||||||||||
| draft-jiang-anima-traffic-management-in-aidc-00.txt | ||||||||||||||
| The Use Case of Autonomic Traffic Management in the Artificial Intelligence Data Center | ||||||||||||||
|
This document describes the use case of autonomic traffic management in the Artificial Intelligence Data Center (AIDC), including the requirements and two management mechanisms, based on the distributed model and the centralized controlling model. It proposed to use the IETF GRASP protocol for the information exchanging, resource negotiation, control signalling, and etc. | |||||||||||||
| draft-jiang-bfd-multi-hop-unaffiliate-04.txt | ||||||||||||||
| Multiple Hop Unaffiliate BFD | ||||||||||||||
|
The Bidirectional Forwarding Detection (BFD) is a fault detection protocol designed to rapidly identify communication failure between two forwarding engines. This document suggests utilizing BFD Echo when the local system supports BFD, but the neighboring system does not. BFD Control packets and their processing procedures can be executed over the BFD Echo port, where the neighboring system solely loops packets back to the local system. This document serves as an update to RFC 5880 and draft-ietf-bfd- unaffiliate-echo-10. | |||||||||||||
| draft-jiang-idr-bgp-soda-00.txt | ||||||||||||||
| BGP Signed Origin Delegation Attestation (SODA) | ||||||||||||||
|
This document defines BGP Signed Origin Delegation Attestation (SODA), an optional transitive BGP path attribute that carries a signed authorization, issued by the holder of an IP prefix, delegating origination of that prefix to a specified Autonomous System (AS) until a stated expiry time. Using SODA, a validator performing Route Origin Validation (ROV) can determine whether an ROV-Invalid result reflects an authorized delegation rather than a route hijack. | |||||||||||||
| draft-jiang-idr-sr-policy-composite-path-09.txt | ||||||||||||||
| BGP Extensions of SR Policy for Composite Candidate Path | ||||||||||||||
|
SR Policy Architecture [RFC9256] defines the concept of a Composite Candidate Path. A regular SR Policy Candidate Path outputs traffic to a set of Segment Lists, while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies on the same headend. This document defines extensions to BGP to distribute SR policies carrying composite candidate path information. So that composite candidate paths can be installed when the SR policy is applied. | |||||||||||||
| draft-jiang-intent-security-03.txt | ||||||||||||||
| Security Considerations and Requirements for Intent-Based Requests in Agentic Systems | ||||||||||||||
|
Intent-based requests enable users, applications, and agents to express goals and constraints without specifying step-by-step procedures. Such intents are commonly translated into executable directives and propagated across multiple entities (clients, agents, authorization components, orchestration functions, and execution endpoints). This multi-hop processing expands the attack surface for tampering, privilege escalation, constraint bypass, and intent drift. In addition, at the point where an intent enters the system, a forged or unauthorized origin may cause actions to be taken without valid consent. This document provides a solution-agnostic security analysis for intent-based requests across agentic systems. It presents attack scenarios, a threat model, security requirements, and per-scenario mitigation considerations, supported by a reference model. The document is Informational: it does not define a protocol, message format, or registry, and concrete mechanisms are left to companion specifications. It emphasizes origin authentication and admission control, constraint validation, invocation validation, multi-hop chain-of-custody, enforcement placement across hops, and policy- driven responses to drift, while remaining independent of any specific deployment domain. | |||||||||||||
| draft-jiang-oauth-intent-admission-00.txt | ||||||||||||||
| Intent Admission Assertions for Agentic Systems | ||||||||||||||
|
In agentic systems, an intent expressed by a user, application, or agent may be forwarded to a remote system that triggers high-impact actions. If the originator of an intent is not authenticated, is not authorized to request the targeted action, or has not obtained the required consent, the receiving system may act on a forged or unauthorized intent. This document defines the Intent Admission Assertion (IAA): a signed, verifiable artifact by which an admission point authenticates an intent originator, authorizes the request against a permission policy, gates consent-required actions on explicit consent from the user or resource owner, and conveys the result to a downstream execution endpoint that re-verifies it before acting. The IAA is a JSON Web Token whose admission decision is expressed using Rich Authorization Requests (RFC 9396). | |||||||||||||
| draft-jiang-sidrops-psvro-04.txt | ||||||||||||||
| Route Origin Registry Problem Statement | ||||||||||||||
|
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. | |||||||||||||
| draft-jiang-wimse-heterogeneous-credential-01.txt | ||||||||||||||
| Heterogeneous Credential Verification for Workload and Agentic Systems | ||||||||||||||
|
Workloads in multi-system environments, including AI agents acting on behalf of users and organizations, increasingly present multiple credentials of heterogeneous types within a single request: workload identity tokens, user-delegated OAuth access tokens, W3C Verifiable Presentations, X.509 certificates, or platform-specific API keys. These are issued by different authorities, follow different formats, are verified by different verifiers, and carry different assurance semantics. A relying party that receives such a heterogeneous credential set has no common way to represent the set, identify each credential's type, determine the authoritative verifier for it, interpret verification results consistently, or combine multiple results into a single handling decision. This document defines a mechanism for processing a heterogeneous credential set on receipt. It specifies a representation of the credential set, a procedure for identifying each credential's type and determining its verifier, a minimal common model for verification results that lets results from different verifiers be compared, and a policy model that combines multiple results into one handling decision. The mechanism is transport-agnostic and does not constrain where the processing functions are deployed. | |||||||||||||
| draft-jimenez-agent-directory-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jimenez-core-coap-diag-00.txt | ||||||||||||||
| CoAP Diagnostic Message Notation | ||||||||||||||
|
This document defines a text notation for representing Constrained Application Protocol (CoAP) request/response exchanges in Internet- Drafts and RFCs. The notation balances human readability with mechanical validation: a reader can follow an exchange at a glance, and tooling can be built to parse the message structure and check each payload against its declared content format. The notation is application-layer by default, with message-layer detail added only where an example depends on it. It is a recommended convention for use in documents and with authoring tools such as kramdown-rfc, not a conformance target; it does not change CoAP or any on-the-wire encoding. | |||||||||||||
| draft-jimenez-dawn-discovery-landscape-00.txt | ||||||||||||||
| A Survey of AI Agent Discovery Mechanisms | ||||||||||||||
|
This document surveys mechanisms for AI agent discovery being developed at the IETF, at AAIF, at 3GPP, and in open-source projects. It compares them by discovery model, scope, dynamism, cross-domain reach, and semantic capability. It identifies gaps, overlaps, and conflicts between the approaches to inform future standardization work. | |||||||||||||
| draft-jimenez-t2trg-iot-agent-01.txt | ||||||||||||||
| Agentic AI Operation of Constrained RESTful Environments | ||||||||||||||
|
This document describes an architecture for AI agents that autonomously discover, interpret, and interact with Internet of Things (IoT) devices using the Constrained Application Protocol (CoAP) and hypermedia-driven patterns. It defines how a Large Language Model (LLM) based agent decomposes high-level user intents into concrete device interactions without requiring pre-configured device knowledge, relying instead on in-band resource discovery, CoRE Link Format metadata, and Semantic Definition Format (SDF) models. The document covers resource discovery, normalized representation for agent consumption, tool interfaces, observation patterns for closed- loop automation, web-based monitoring interfaces, and security considerations. | |||||||||||||
| draft-jms-mole-architecture-00.txt | ||||||||||||||
| Moderation of unLinkable Endorsements (MoLE) Architecture | ||||||||||||||
|
Moderation of unLinkable Endorsements (MoLE) is an architecture that lets a party performing access control (a Moderator) bootstrap trust in a client from a third party (an Anchor) that already has a trust relationship with that client, and then adjust that trust over time in response to the client's behaviour, for example by dynamically rate-limiting access. MoLE targets open deployments, in which independent parties may be responsible for access control and for vouching for clients, whilst maintaining strong privacy protections for clients. These protections are designed to hold even if participants in the ecosystem collude or otherwise misbehave. This document specifies the roles, the information flows between them, the privacy and security requirements, and deployment considerations. | |||||||||||||
| draft-jms-mole-http-transport-00.txt | ||||||||||||||
| MoLE HTTP Transport | ||||||||||||||
|
MoLE targets browser deployments, so Clients, Anchors, and Moderators need an HTTP transport for the protocol flows defined by the architecture. This document defines the Mole HTTP authentication scheme, which carries challenges and presentations for the endorsement and credential flows, and the headers used to return credential material. The grant exchanges with the Anchor are defined per protocol in [PROTOCOLS]. | |||||||||||||
| draft-jms-mole-protocols-00.txt | ||||||||||||||
| MoLE Protocols | ||||||||||||||
|
This document defines protocols that instantiate the MoLE architecture: two endorsement protocols, by which a Client proves to a Moderator that it holds an Endorsement from a trusted Anchor without revealing which one, and three credential protocols, by which a Moderator issues, verifies, and updates per-Client state without being able to link presentations. It also establishes the registries that identify these protocols. | |||||||||||||
| draft-johani-dnsop-dnssec-alg-experimental-range-00.txt | ||||||||||||||
| Experimental and Private-Use Ranges in the DNSSEC Algorithm Numbers Registry | ||||||||||||||
|
The DNSSEC Algorithm Numbers registry contains two code points, 253 (PRIVATEDNS) and 254 (PRIVATEOID), intended for private and experimental algorithms. These code points identify the algorithm by prepending a domain name or an object identifier to the "Public Key" field of the DNSKEY RDATA, overloading the semantics of that field and forcing every implementation to special-case algorithm dispatch. Because all such algorithms share a single code point, they cannot be distinguished on the wire by the algorithm number alone. This document reserves two small ranges of DNSSEC algorithm numbers: one for Private Use, requiring no IANA registration, and one for experimental algorithms, registered on a First Come First Served basis. Code points drawn from these ranges behave identically to ordinary algorithm numbers and require no overloading of the DNSKEY RDATA. This enables clean experimentation with the growing set of post-quantum and other candidate signature algorithms. This document updates RFC 6014 and RFC 9157. | |||||||||||||
| draft-johani-dnsop-dnssec-alg-split-02.txt | ||||||||||||||
| Algorithm-Split DNSSEC: KSK/ZSK Algorithm Separation | ||||||||||||||
|
Post-quantum DNSSEC signature algorithms have much larger keys and/or signatures than the elliptic-curve algorithms in common use today. The apex DNSKEY RRset carries the key material for both the KSK and the ZSK, and grows accordingly; the open question is whether the rest of the zone must grow with it. Because the KSK's signature appears only on the DNSKEY RRset, a large KSK -- key and signature both -- costs little beyond that one RRset. The ZSK's signature, by contrast, appears on every other RRset, so it is the size of the ZSK signature that governs the size of ordinary responses. Confining a large algorithm to the KSK, and using a small-signature algorithm for the ZSK, keeps the cost of the large algorithm contained in the DNSKEY RRset. This document specifies the changes that make this pattern safe and practical. It relaxes the DNSSEC signing rule that requires a zone to be signed with every algorithm present in the apex DNSKEY RRset, so that an algorithm used only by a key-signing key need not be applied to the rest of the zone. It relies on ordinary ZSK rotation to bound the residual exposure of the ZSK algorithm, and recommends a sequential (rather than double-signature) model for rolling the ZSK algorithm, so that the rest of the zone is never doubly signed. Finally, it specifies how a resolver can use the algorithm number in the parent's DS RRset to recognize a likely-oversized DNSKEY RRset and select a transport suitable for large responses, avoiding the truncate-then-retry round trip. This document updates RFC 4035 and RFC 6840. | |||||||||||||
| draft-johani-dnsop-svcb-oots-00.txt | ||||||||||||||
| An SVCB Service Parameter for Opportunistic Operator-led Transport Signaling (oots) | ||||||||||||||
|
This document defines a new Service Parameter Key (SvcParamKey), "oots" ("Opportunistic Operator-led Transport Signal"), for use in Service Binding (SVCB) and HTTPS resource records as defined in RFC 9460. The "oots" parameter allows the operator of an authoritative DNS nameserver to advertise, per DNS transport protocol (such as DNS over UDP/TCP, DNS over TLS, DNS over HTTPS, and DNS over QUIC), the operator's own assessment of the share of the nameserver's total query load that it is confident it can serve over that transport. The per-transport values are independent capability estimates rather than a distribution of queries across transports; they are opportunistic hints that a resolver MAY use to inform transport selection and MAY ignore entirely. This document provides the specification required by Section 14.3.1 of RFC 9460 for registration of the "oots" SvcParamKey in the IANA "Service Parameter Keys (SvcParamKeys)" registry. | |||||||||||||
| draft-jones-httpbis-cookie-preference-00.txt | ||||||||||||||
| The Cookie-Preference HTTP Header Field | ||||||||||||||
|
This document specifies a new HTTP request header field, "Cookie- Preference", that enables user agents to communicate the user's preferred cookie disposition (e.g., accept all, accept essential only, reject all, or ask) to web servers. By conveying this preference upfront, the header can facilitate a more seamless browsing experience while respecting user privacy choices and reducing reliance on per-site consent dialogs. | |||||||||||||
| draft-josefsson-cfrg-mceliece-considerations-00.txt | ||||||||||||||
| Classic McEliece Security Considerations | ||||||||||||||
|
This document contains considerations for use of the Classic McEliece Post-Quantum Key Encapsulation Method (KEM). The document is intended as introduction and guidance to encourage adoption of Classic McEliece in IETF standards-track protocols. | |||||||||||||
| draft-josefsson-cfrg-mothma-01.txt | ||||||||||||||
| Mothma: Generic Instantiated PQ/T Hybrid Signatures | ||||||||||||||
|
This document specify Mothma as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Digital Signatures. The goal is to provide a generic hybrid signature pattern that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on combinations of the traditional EdDSA, ECDSA and RSA methods with the post-quantum methods of ML-DSA, SLH-DSA, XMSS and LMS. | |||||||||||||
| draft-josefsson-cfrg-sntrup-considerations-00.txt | ||||||||||||||
| Streamlined NTRU Prime Security Considerations | ||||||||||||||
|
This document contains considerations for use of the Streamlined NTRU Prime Post-Quantum Key Encapsulation Method (KEM). The document is intended as introduction and guidance to encourage adoption of Streamlined NTRU Prime in IETF standards-track protocols. | |||||||||||||
| draft-josefsson-chempat-05.txt | ||||||||||||||
| Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms | ||||||||||||||
|
This document specify Chempat as a generic family of instantiated Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs). The goal is to provide a generic combiner construct that can be analysed separately for security assurance, and to offer concrete instantiated algorithms for integration into protocol and implementations. Identified instances are provided based on some combinations of traditional Diffie-Hellman key agreement using curves P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM- 1024, Streamlined NTRU Prime sntrup761, Classic McEliece and FrodoKEM. | |||||||||||||
| draft-josefsson-mceliece-05.txt | ||||||||||||||
| Classic McEliece | ||||||||||||||
|
This document specifies Classic McEliece, a Key Encapsulation Method (KEM) designed for IND-CCA2 security, even against quantum computers. This is a transcribed version of the proposed ISO Classic McEliece draft, which ISO standardized in June 2026. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-josefsson-mceliece/. Source for this draft and an issue tracker can be found at https://gitlab.com/jas/ietf-mceliece. | |||||||||||||
| draft-josefsson-ssh-sphincs-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-josefsson-sshsig-format-04.txt | ||||||||||||||
| Lightweight Secure Shell (SSH) Signature Format | ||||||||||||||
|
This document describes a lightweight SSH Signature format that is compatible with SSH keys and wire formats. | |||||||||||||
| draft-jot-bess-evpn-mcast-router-sync-00.txt | ||||||||||||||
| Multicast Router State Synchronization in EVPN Networks | ||||||||||||||
|
Ethernet VPN (EVPN) networks support multicast applications in which multicast routers and multicast hosts are attached to the same tenant. Existing specifications define how Provider Edge (PE) devices synchronize the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) membership state of multihomed multicast hosts, and how Optimized Inter-Subnet Multicast (OISM) forwarding interacts with multicast routers via PIM EVPN Gateways. However, none of the existing specifications addresses the synchronization of the state associated with a multicast router (an IGMP/MLD Querier or a Protocol Independent Multicast (PIM) router) when that router is multihomed to a set of EVPN PEs. This document specifies a new EVPN route, the Multicast Router Discovery (MRD) route, and the procedures to synchronize multicast router state across the PEs of an Ethernet Segment, for routers attached to multicast Broadcast Domains or to Layer 3 interfaces. | |||||||||||||
| draft-joung-detnet-stateless-fair-queuing-09.txt | ||||||||||||||
| Latency Guarantee with Stateless Fair Queuing | ||||||||||||||
|
This document specifies the implementation details for the framework specified in ITU-T Y.3129 [Y.3129] and ITU-T Y.3148 [Y.3148]. The framework guarantees end-to-end (E2E) latency bounds to flows. The schedulers in core nodes do not need to maintain flow states. Instead, the entrance node of a flow marks an ideal service completion time according to a fluid model, called Finish Time (FT), of a packet in the packet header. The subsequent core nodes update the FT by adding a delay factor, which is a function of the flow and the nodes. The packets in the queue of the scheduler are served in the ascending order of FT. This mechanism is called the stateless fair queuing. The result is that flows are isolated from each other almost perfectly. The latency bound of a flow depends only on the flow's intrinsic parameters such as the maximum burst size and the service rate, except the link capacities and the maximum packet length among other flows sharing each output link with the flow. This document specifies the metadata, formats of metadata, the admission control procedure, and an approximation of stateless fair queuing implemented via a strict priority (SP) scheduler. | |||||||||||||
| draft-jovancevic-bvap-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-jovancevic-saip-11.txt | ||||||||||||||
| SAIP: Signed Agent Identity Protocol | ||||||||||||||
|
The modern internet lacks a reliable mechanism for verifying the identity of automated software agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rapid growth of automated agents including AI crawlers, IoT devices, and enterprise automation systems. This document specifies SAIP (Signed Agent Identity Protocol), a lightweight, opt-in mechanism for verifiable client identity at the application layer. SAIP implements the principles defined in the Verifiable Identity Claims and Delegation Model [VICDM] and enables servers to distinguish legitimate automated traffic from malicious actors through cryptographic identity at three levels of granularity: vendor, agent type, and individual instance. SAIP is protocol-agnostic and applicable to HTTP, SMTP, and other header-based protocols. It introduces DNS-based Attestation Discovery as a lightweight alternative to registry-based key lookup, making deployment accessible to organizations of any size. | |||||||||||||
| draft-jovancevic-vdac-04.txt | ||||||||||||||
| Verifiable Data Access Contract (VDAC) | ||||||||||||||
|
This document specifies the Verifiable Data Access Contract (VDAC), a protocol for cryptographically verifiable bilateral agreement between a content publisher and an automated agent regarding the terms of programmatic data access. VDAC defines the mechanism by which a site issues an access offer, an agent accepts that offer, both parties sign the resulting contract, and per-request references bind individual interactions to agreed terms. VDAC is the protocol-layer realization of the bilateral commitment principle introduced in Section 6.6 of the Verifiable Identity Claims and Delegation Model [VICDM] and operates as a companion specification to the Signed Agent Identity Protocol [SAIP]. This document defines mechanism, not content: VDAC verifies the existence and integrity of an agreement; the substance of what is agreed remains entirely between the contracting parties. VDAC also defines an append-only contract history. Changes to the recorded state of a Contract are recorded as signed change records and associated immutable snapshots; the original Contract Document is never modified. | |||||||||||||
| draft-jovancevic-vicdm-10.txt | ||||||||||||||
| Verifiable Identity Claims and Delegation Model (VICDM) | ||||||||||||||
|
This document defines a conceptual framework for handling identity assertions in application-layer protocols. It introduces a model in which identity on the Internet is optional, but any asserted identity MUST be verifiable. It further defines a delegation mechanism that allows entities to authorize third-party infrastructure to act on their behalf in a verifiable and transparent manner. The goal is to reduce identity misrepresentation while fully preserving the ability for anonymous and pseudonymous interaction. This document does not define a protocol; it defines the principles that protocol specifications SHOULD follow when addressing agent identity. A concrete protocol implementation of these principles is defined in [SAIP]. | |||||||||||||
| draft-jurkovikj-collab-tunnel-03.txt | ||||||||||||||
| The Collaboration Content Transfer (TCT) Protocol | ||||||||||||||
|
This document specifies the Collaboration Content Transfer (TCT) Protocol, an experimental HTTP profile for efficient delivery of publisher-selected web content to automated clients. TCT defines a deterministic JSON representation at a machine-facing URL, bidirectional discovery between human-facing and machine-facing resources, JSON sitemaps containing representation-validator hints, and conditional request behavior using ordinary strong ETags. TCT preserves standard HTTP validator scope: an M-URL ETag identifies the exact selected M-URL representation. Optional Semantic Validators can correlate the logical state of human-facing and machine-facing representations, but are not required by TCT and do not replace ordinary cache validators. TCT does not define authorization, licensing, content-use policy, or mutation semantics. | |||||||||||||
| draft-jurkovikj-http-integrity-cache-00.txt | ||||||||||||||
| Maintaining HTTP Integrity Fields in Cached and Cache-Generated Responses | ||||||||||||||
|
HTTP caches update stored response fields, combine partial responses, and construct responses from stored state. Those operations can move an Integrity field value onto content or representation data different from the data to which the value originally applied. This document updates RFC 9111 by defining field-specific maintenance rules for Content-Digest, Repr-Digest, and Unencoded-Digest. A cache either preserves the association between each retained or emitted dictionary member and its defined input, recomputes the member over the resulting input, or removes the member. The rules cover stored- field updates, 304 and HEAD freshening, partial-response combination, cache-generated 304, HEAD, and 206 responses, and content-coding transformations. No new HTTP field, status code, cache directive, validator, or digest algorithm is defined. | |||||||||||||
| draft-jurkovikj-http-semantic-validator-01.txt | ||||||||||||||
| Semantic Validators for HTTP | ||||||||||||||
|
This document defines the Semantic-ETag HTTP response field and the If-Semantic-Match HTTP request field. Unlike the standard ETag field, which identifies a selected representation, Semantic-ETag identifies a server-defined semantic state within an explicitly scoped semantic equivalence domain. If-Semantic-Match enables origin servers to perform representation-independent optimistic concurrency control when different HTTP resources or representations expose the same logical state. This document does not update or replace the semantics of ETag, If- Match, or HTTP cache validation defined by RFC 9110. | |||||||||||||
| draft-jurkovikj-httpapi-agentic-state-02.txt | ||||||||||||||
| HTTP Profile for Conditional Updates to Shared Resource State (Agentic State Transfer) | ||||||||||||||
|
HTTP applications frequently expose one logical object through several representations or resources. Ordinary HTTP entity tags identify selected representations; they do not, by themselves, provide a conditional-update mechanism spanning different request targets. This document specifies Agentic State Transfer (AST), an HTTP profile for preventing lost updates to shared application state. AST Core requires a client to mutate the State-Bearing Resource using the strong ETag of its State-Bearing Representation and the standard If- Match field. AST Semantic uses Semantic-ETag and If-Semantic-Match when a protected mutation targets a different resource or representation in the same concurrency domain. The profile also defines state discovery, atomic compare-and-commit behavior, conflict handling, deferred processing, caching constraints, and security requirements. | |||||||||||||
| draft-jurkovikj-json-three-way-merge-00.txt | ||||||||||||||
| Deterministic Three-Way Merge for JSON Values | ||||||||||||||
|
For a fixed, disclosed resource policy, this document defines a deterministic three-way merge operation for a restricted JSON value domain. Given a shared base value and two independently derived values, called source and target, the operation produces either one complete merged JSON value or an ordered set of structured conflicts. The operation defines strict JSON input processing, finite binary64 number normalization, scalar and object merge laws, explicit missing- member semantics, RFC 6901 conflict paths, typed conflict kinds, a fail-closed result for arrays, and bounded failure behavior. It is independent of HTTP and does not define array merge semantics, application-specific semantic resolution, content identity, or authorization policy. | |||||||||||||
| draft-juwan-ars-00.txt | ||||||||||||||
| ARS-1 -- Generic Archival Reference System | ||||||||||||||
|
ARS-1 defines a deterministic, human-oriented, cryptographically derived reference protocol for assigning stable public References to durable digital entities. Typical references look like NX-174932, CJ3-106, MR-X4928, or KX4-7B19Q2. ARS-1 defines cryptographic identity, deterministic derivation, namespace management, canonical serialization, variable-length encoding, checksum, optional hardware input, optional digital signature, cryptographic agility, versioning, portability, reference resolution, reference reproduction, and cryptographic migration. The core interoperability property is: identical canonical inputs, identical applicable cryptographic Profile, identical Reference Key material, and identical Hardware Profile output MUST produce exactly the same canonical Reference in every conforming implementation. ARS-1 is designed so that changes in cryptographic algorithms, security parameters, signature schemes, or hardware mechanisms can be introduced through versioned Profiles without requiring the reassignment of historical References. | |||||||||||||
| draft-juwan-ars-uri-01.txt | ||||||||||||||
| ARS URI Scheme: A URI Scheme for ARS-1 References | ||||||||||||||
|
This document defines the "ars" URI scheme for representing ARS-1 References in a syntactically valid URI form. ARS-1 defines a deterministic, cryptographically derived reference protocol for assigning stable public identifiers to durable digital entities. The "ars" URI scheme provides a standard URI notation for these references, enabling their use in hyperlinks, QR codes, metadata fields, and other URI-consuming contexts. This specification does not redefine the ARS-1 Reference generation pipeline, canonicalization rules, or verification logic. Those are normatively defined by ARS-1. This document defines only the URI syntax, encoding, comparison, and resolution semantics for the "ars" scheme. | |||||||||||||
| draft-jwang-dnsop-dns-latency-measurement-00.txt | ||||||||||||||
| A Framework for DNS Resolution Latency Measurement | ||||||||||||||
|
DNS resolution latency is widely used as an operational metric for evaluating recursive resolvers, authoritative servers, and DNS infrastructure. However, current implementations employ different definitions, measurement scopes, and testing methodologies, making latency results difficult to compare across deployments. This document identifies common sources of inconsistency, proposes a conceptual latency decomposition model, and provides measurement considerations intended to improve comparability of DNS latency measurements. This document does not define protocol behavior nor introduce new protocol mechanisms. | |||||||||||||
| draft-jz-dmm-mup-evolution-00.txt | ||||||||||||||
| Mobile User Plane Evolution: 5G & 6G | ||||||||||||||
|
This document starts from the description of the 5G mobile user plane, including distributed User Plane Functions (UPFs). Then, based on the 3GPP proposals for 6G UP architecture evolution, the draft describes some potential enhancements revolving around the support of the 6G UP flexiblity, scalability & resilience. The draft also discusses the potential IETF work upon integrating the proposed enhancements of the 6G UP architecture. | |||||||||||||
| draft-kadjo-zi2cert-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kahrer-oauth-client-challenge-protocol-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kaizer-dnsop-ml-dsa-mtl-dnssec-01.txt | ||||||||||||||
| Module-Lattice-Based Signatures with Merkle Tree Ladders (ML-DSA-MTL) for DNSSEC | ||||||||||||||
|
This document describes how to apply the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) and Merkle Tree Ladders (MTL) as a conservative post-quantum cryptographic algorithm for DNS Security Extensions (DNSSEC). This combination is referred to as the ML-DSA- MTL Signature scheme. This document describes how to specify ML-DSA- MTL keys and signatures in DNSSEC, specifically for ML-DSA-44 with SHAKE-128. | |||||||||||||
| draft-kale-agntcy-federated-privacy-02.txt | ||||||||||||||
| Privacy-Preserving Federated Learning Architecture for Multi-Tenant Agent Systems | ||||||||||||||
|
This document describes an architecture for privacy-preserving federated learning in multi-tenant agent systems. The architecture is intended for deployments in which agents, tools, services, or model operators need to learn from distributed operational data without centralizing tenant data. The architecture separates agent communication from learning coordination. Existing or emerging agent protocols can provide discovery, messaging, authentication, and transport. This document defines the privacy and security requirements for the learning layer: cohort formation, update submission, secure aggregation, differential privacy, privacy accounting, auditability, and model distribution. The document is scoped to cross-tenant and cross-organization settings. It does not define a new agent protocol, a new transport protocol, or a new machine learning algorithm. | |||||||||||||
| draft-kaliski-asn1-layman-guide-00.txt | ||||||||||||||
| A Layman's Guide to a Subset of ASN.1,BER,and DER | ||||||||||||||
|
This note gives a layman's introduction to a subset of the Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The particular purpose of this note is to provide background material sufficient for understanding and implementing the RSA Data Security, Inc. Public Key Cryptography Standards (PKCS) family of standards. This document represents a republication of A Layman's Guide to a Subset of ASN.1, BER, and DER, originally authored and published by RSA Security USA LLC. This document is submitted with permission from, and on behalf of RSA Security USA LLC. By publishing this document, change control is transferred to the IETF and the Internet technical community in full conformance with the provisions of BCP 78 and BCP 79. | |||||||||||||
| draft-kalmykov-socarch-profile-00.txt | ||||||||||||||
| Social Architecture Diagnostic Profile: A JSON-Based Format for Exchanging Diagnostic Descriptions of Socio-Technical Environments | ||||||||||||||
|
This document specifies the Social Architecture Diagnostic Profile (SADP), a JSON-based format for exchanging diagnostic descriptions of socio-technical environments. A profile records the object under review, the evidence used, the diagnostic dimensions applied, identified breaks or tensions, limitations, confidence levels, and human-review requirements. The format is intended for research tools, educational systems, expert-review workflows, case repositories, and other systems that need portable and inspectable diagnostic descriptions. This document does not define a scoring standard, certification procedure, legal assessment process, psychological assessment process, or automated consequential decision process. | |||||||||||||
| draft-kalosha-stb-tls13-00.txt | ||||||||||||||
| STB Cryptographic Parameters for Transport Layer Security (TLS) Protocol Version 1.3 | ||||||||||||||
|
This specification introduces a subset of STB (STandards of Belarus) cryptographic algorithms and defines their use in TLS 1.3. The document is self-contained, i.e., it fully describes the required STB algorithms. It can be used to develop STB-compliant TLS 1.3 implementations without referring to the original STB standards. | |||||||||||||
| draft-kamimura-rats-behavioral-evidence-02.txt | ||||||||||||||
| On the Relationship Between Remote Attestation and Behavioral Evidence Recording | ||||||||||||||
|
This document provides an informational discussion of the conceptual relationship between remote attestation, as defined in RFC 9334 (RATS Architecture), and behavioral evidence recording mechanisms. It observes that these two verification capabilities address fundamentally different questions - attestation addresses "Is this system in a trustworthy state?" while behavioral evidence addresses "What did the system actually do?" - and discusses how they could conceptually complement each other in accountability frameworks. This document is purely descriptive: it does not propose any modifications to RATS architecture, define new mechanisms or protocols, or establish normative requirements. It explicitly does not define any cryptographic binding between attestation and behavioral evidence. | |||||||||||||
| draft-kamimura-scitt-refusal-events-03.txt | ||||||||||||||
| Verifiable AI Refusal Events using SCITT | ||||||||||||||
|
This document defines a claim set for recording AI content refusal events. The claim set specifies the semantic content and correlation rules for refusal audit trails, independent of any particular serialization format. The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This specification addresses claim semantics and verification requirements; it does not mandate a specific encoding. A CDDL definition is provided for CBOR-based implementations, and equivalent JSON representations are shown in an appendix for illustration. This specification provides auditability of logged refusal decisions. It does not define content moderation policies, classification criteria, or what AI systems should refuse. | |||||||||||||
| draft-kamimura-scitt-vcp-03.txt | ||||||||||||||
| A SCITT Profile for Verifiable Audit Trails in Algorithmic Trading: The VeritasChain Protocol (VCP) | ||||||||||||||
|
This document defines a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for creating tamper-evident audit trails of AI-driven algorithmic trading decisions and executions. The VeritasChain Protocol (VCP) applies the SCITT framework to address the specific requirements of financial markets, including high-precision timestamps, regulatory compliance considerations (EU AI Act, MiFID II), and privacy-preserving mechanisms (crypto-shredding) compatible with GDPR. This profile specifies how VCP events are encoded as SCITT Signed Statements, registered with Transparency Services, and verified using COSE Receipts. It further defines SCITT conformance profiles for interoperability and an ERASURE event type that records crypto- shredding operations as immutable audit events. About This Document This note is to be removed before publishing as an RFC. The latest version of this document, along with implementation resources and test vectors, can be found at https://github.com/veritaschain/vcp-spec. Discussion of this document takes place on the SCITT Working Group mailing list ([email protected]). Changes from -02: * Updated to align with VCP Specification v1.2 * Added SCITT Alignment Object and conformance profiles (Section 4.4) * Added ERASURE event type recording crypto-shredding operations (Section 6.3) * Corrected the post-quantum SignAlgo registry value from DILITHIUM3 to DILITHIUM2 (ML-DSA, FIPS 204) * PolicyID examples migrated to the Issuer Domain + Local ID naming convention defined in VCP v1.2 | |||||||||||||
| draft-kamimura-vap-framework-01.txt | ||||||||||||||
| Verifiable AI Provenance Framework (VAP): An Architectural Framework for Evidentiary-Grade AI Decision Trails | ||||||||||||||
|
Automated decision-making systems, including AI and algorithmic systems in critical infrastructure, currently lack standardized mechanisms for producing evidentiary-grade provenance records that can withstand independent verification. Traditional logging approaches fail to provide the cryptographic guarantees required for regulatory compliance, forensic investigation, and cross- organizational accountability. This document describes the Verifiable AI Provenance Framework (VAP), an architectural framework that defines requirements for producing verifiable decision trails using existing IETF security technologies. VAP does not define new protocols or cryptographic primitives; rather, it provides an architectural coordination layer that enables domain-specific profiles to leverage Supply Chain Integrity, Transparency and Trust (SCITT), Remote Attestation Procedures (RATS), CBOR Object Signing and Encryption (COSE), and related IETF work in a consistent manner. This document is intended to frame the problem space and facilitate discussion about whether architectural coordination work is needed in this area. | |||||||||||||
| draft-kanojia-creduent-agent-uri-00.txt | ||||||||||||||
| The 'agent' Uniform Resource Identifier (URI) Scheme and Cryptographic Attestation Protocol | ||||||||||||||
|
This document specifies the 'agent' Uniform Resource Identifier (URI) scheme and its associated cryptographic attestation protocol. The 'agent' scheme defines a transport-agnostic, cryptographically verifiable addressing layer for identifying autonomous software agents, binding domain ownership via DNS TXT records, enforcing instruction integrity, and validating attenuated capability delegation tokens. | |||||||||||||
| draft-kao-idr-bitwise-ip-filters-05.txt | ||||||||||||||
| Bitwise IP Filters for BGP FlowSpec | ||||||||||||||
|
This document introduces the bitwise match filter component for source and destination IPv4/IPv6 address fields. These components enhance the BGP Flow Specification framework and provide a solution for dynamic symmetric traffic load-balancing. | |||||||||||||
| draft-karcz-uuas-01.txt | ||||||||||||||
| Unified User-Agent String | ||||||||||||||
|
User-Agent is a HTTP request-header field. It contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use. Over the years contents of this field got complicated and ambiguous. That was the reaction for sending altered version of websites to web browsers other than popular ones. During the development of the WWW, authors of the new web browsers used to construct User-Agent strings similar to Netscape's one. Nowadays contents of the User-Agent field are much longer than 15 years ago. This Memo proposes the Uniform User-Agent String as a way to simplify the User-Agent field contents, while maintaining the previous possibility of their use. | |||||||||||||
| draft-kario-gss-keyex-pqc-00.txt | ||||||||||||||
| GSS-API Key Exchange with hybrid ML-KEM | ||||||||||||||
|
This document specifies additions to RFC4462. It defines a new key exchange methods that use hybrid Post-Quantum Traditional (PQ/T) key exchange. The purpose of this specification is to modernize the cryptographic primitives used by Generic Security Service (GSS) key exchanges. | |||||||||||||
| draft-kashyap-calext-ical-property-deps-00.txt | ||||||||||||||
| Machine-Readable Property Dependencies for iCalendar (RFC 5545) | ||||||||||||||
|
RFC 5545 defines inter-property interaction rules for iCalendar components in prose scattered across multiple RFC sections. No published, standalone representation of these rules exists in a form suitable for machine consumption. This document specifies a formal dependency graph for VEVENT components with 27 properties and 20 edges spanning six edge types. It classifies properties into five merge safety categories that determine whether concurrent edits can be combined without user intervention. The specification is published as YAML and JSON artifacts for cross-language consumption. | |||||||||||||
| draft-kavian-aep-api-key-session-credential-04.txt | ||||||||||||||
| API-Key Session Credential Grant Type for the Agent Enrollment Protocol | ||||||||||||||
|
This document defines the API-key session-credential grant type for the Agent Enrollment Protocol (AEP). The grant type lets an AEP Service issue an opaque API key through the AEP Grant command for deployments that already operate header-based API-key authentication. | |||||||||||||
| draft-kavian-aep-basic-session-credential-04.txt | ||||||||||||||
| Basic Session Credential Grant Type for the Agent Enrollment Protocol | ||||||||||||||
|
This document defines the Basic session-credential grant type for the Agent Enrollment Protocol (AEP). The grant type lets an AEP Service issue an HTTP Basic credential through the AEP Grant command for deployments that already integrate with Basic authentication middleware. | |||||||||||||
| draft-kavian-aep-claims-01.txt | ||||||||||||||
| AEP Claim Values | ||||||||||||||
|
This document defines a claim-value catalog for the Agent Enrollment Protocol (AEP). It specifies stable claim names and forward- compatible JSON value shapes that Agents can submit during enrollment when requested by a Service Inspect document. | |||||||||||||
| draft-kavian-aep-did-web-identity-method-00.txt | ||||||||||||||
| The did:web Identity Method for the Agent Enrollment Protocol | ||||||||||||||
|
This document defines the did:web identity method for the Agent Enrollment Protocol (AEP). The method lets an AEP Service verify Agent client assertion JWTs by resolving an Agent did:web identifier to a DID document published over HTTPS. | |||||||||||||
| draft-kavian-aep-oauth-session-credential-04.txt | ||||||||||||||
| OAuth Bearer Session Credential Grant Type for the Agent Enrollment Protocol | ||||||||||||||
|
This document defines the OAuth Bearer session-credential grant type for the Agent Enrollment Protocol (AEP). The grant type lets an AEP Service issue an OAuth-style Bearer access token through the AEP Grant command while preserving baseline AEP client assertion authentication as the root of trust. | |||||||||||||
| draft-kavian-aep-platform-hosted-identity-01.txt | ||||||||||||||
| AEP Platform Hosted Identity | ||||||||||||||
|
This document defines interoperable hosted identity behavior for Agent Enrollment Protocol (AEP) Platforms. It lets a Platform provision Service-scoped Agent did:web identities, publish DID documents, custody signing keys, and produce AEP client assertion JWTs through delegated signing operations. | |||||||||||||
| draft-kavian-agent-enrollment-protocol-04.txt | ||||||||||||||
| The Agent Enrollment Protocol | ||||||||||||||
|
The Agent Enrollment Protocol (AEP) defines an HTTP-based mechanism for autonomous agents to discover service enrollment requirements, enroll an agent identity, obtain optional session credentials, revoke those credentials, and query enrollment status. AEP uses Decentralized Identifiers, client assertion JWTs, and HTTP Problem Details to provide a narrow machine-first enrollment and authentication substrate for agent-to-service interactions. | |||||||||||||
| draft-kavian-offering-discovery-protocol-01.txt | ||||||||||||||
| The Offering Discovery Protocol | ||||||||||||||
|
The Offering Discovery Protocol (ODP) enables an automated Agent to inspect a Service, discover its Collections and Offerings, interpret Service-defined structured attributes, and identify links to subsequent operations. ODP supports catalogs ranging from a few Offerings to large marketplaces without imposing a universal product taxonomy. This document defines the protocol's scope, terminology, roles, discovery architecture, extensibility model, composition boundaries, and conformance model. | |||||||||||||
| draft-kay-dawn-use-cases-01.txt | ||||||||||||||
| Use Cases and Applicability for Discovery of Agents With Names | ||||||||||||||
|
This document describes use cases and applicability for Discovery of Agents With Names (DAWN). It illustrates how clients discover AI resources and obtain the minimum information needed for subsequent interaction within a local network, within an organisation, or between cooperating organisations with trust relationships. This document does not define a discovery protocol, a registration procedure, a selection algorithm, or an agent-to-agent communication protocol. | |||||||||||||
| draft-kazuho-httpbis-http3-over-qmux-00.txt | ||||||||||||||
| HTTP/3 over QMux | ||||||||||||||
|
This document specifies how to use HTTP/3 over QMux. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the HTTP Working Group mailing list ([email protected]), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams. | |||||||||||||
| draft-kazuho-ptth-ptth-01.txt | ||||||||||||||
| Protocol for Transposed Transactions over HTTP | ||||||||||||||
|
This document specifies the Protocol for Transposed Transactions over HTTP (PTTH), an HTTP extension that allows a backend server to establish an HTTP connection to a reverse proxy and transpose the flow of HTTP requests. The reverse proxy then sends requests to the backend server over the resulting transposed channel. This extension lets backend servers behind restrictive firewalls accept HTTP traffic through reverse proxies without changing firewall settings and with minimal overhead. | |||||||||||||
| draft-kbf-onsen-problem-statement-00.txt | ||||||||||||||
| ONSEN Problem Statement | ||||||||||||||
|
The IETF has produced numerous YANG data models for automating the provisioning and delivery of network and connectivity services, including L2SM, L3SM, L2NM, L3NM, Attachment Circuits, and Network Slicing models. Despite their wide availability, operators report persistent challenges in operationalizing these abstractions in a consistent, scalable, and automatable manner. This document describes the problem space for the ONSEN Working Group, identifying the operational gaps and deficiencies in existing IETF service and network abstraction models that prevent effective end-to-end automation. The problems documented here are drawn from operator experience and from the findings of the IAB NEMOPS Workshop. This document does not propose solutions, protocols, or new data models. | |||||||||||||
| draft-kbr-teas-mptersvp-04.txt | ||||||||||||||
| RSVP-TE Extensions for Multipath Traffic Engineered Directed Acyclic Graph Tunnels | ||||||||||||||
|
A Multipath Traffic Engineered Directed Acyclic Graph (MPTED) tunnel is a Traffic Engineering (TE) construct that facilitates weighted load balancing of unicast traffic across a constrained set of paths optimized for a specific objective. This document describes the provisioning of an MPTED Tunnel in a TE network using RSVP-TE. | |||||||||||||
| draft-kemp-oauth-x509-bearer-00.txt | ||||||||||||||
| X.509 Certificate Bearer Profile for OAuth 2.0 Client Authentication and Authorization Grants | ||||||||||||||
|
This specification defines the use of an X.509 certificate, issued under a Public Key Infrastructure (PKI), as a means for requesting an OAuth 2.0 access token as well as for client authentication, profiling the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants in a manner analogous to the JSON Web Token (JWT) Bearer Token profile and the SAML 2.0 Bearer Assertion profile. It is motivated primarily by workload identity systems, such as SPIFFE/SPIRE and Athenz, that already issue software workloads short- lived X.509 certificates for mutual TLS, and that benefit from using those same certificates directly with OAuth 2.0. Unlike a bare bearer credential, this profile requires that possession of the private key corresponding to the certificate's public key be corroborated as part of every use, so that a copy of the certificate alone -- which is not a secret -- is never sufficient to obtain a grant or authenticate a client. | |||||||||||||
| draft-kennedy-dnssd-data-block-01.txt | ||||||||||||||
| DNS-SD Data Block Encoding for Non-DNS Transports | ||||||||||||||
|
The DNS-SD Data Block (DDB) is a compact TLV encoded container for conveying DNS-SD service information over non-IP transports used by short-range peer-to-peer or proximity-based advertisement and discovery technologies such as the Bluetooth Low Energy Transport Discovery Service or NFC Verb NDEF Records. | |||||||||||||
| draft-kerrison-representation-intricate-comms-00.txt | ||||||||||||||
| Representation of Intricate Communications | ||||||||||||||
|
Complex inter-party communication or relationship dynamics can be implied within the use of more structured protocols. This document proposes a compact binary representation for describing these dynamics in a non-protocol-binding manner that can be readily converted back to a readable format and provide additional context for implementers. | |||||||||||||
| draft-kes-rfc3113bis-02.txt | ||||||||||||||
| 3GPP-IETF Standardization Collaboration | ||||||||||||||
|
The objective of the collaboration between 3GPP and IETF is securing timely development of technical specifications, and to facilitate maximum interoperability with existing fixed and mobile Internet systems, devices, and protocols. This document summarizes some high- level principles of cooperation and the coordination between both organizations while leaving out the detailed descriptions to be specified and maintained by the coordination function itself. | |||||||||||||
| draft-kestura-pac-compliance-attestation-00.txt | ||||||||||||||
| An Interoperable Attestation Format for Policy-as-Code Compliance Evidence | ||||||||||||||
|
Organizations increasingly enforce regulatory and security requirements using policy-as-code (PaC) engines integrated into continuous integration and delivery (CI/CD) pipelines. The evidence these engines produce, that is, the record of which policies were evaluated, against what inputs, and with what outcome, is typically emitted in vendor-specific, non-portable formats. This impairs auditability, cross-tool aggregation, and independent verification. This document analyzes the problem and describes an interoperable, machine-readable attestation format for PaC compliance evidence. It is informational and does not define an IETF standard, nor does it establish a new IANA registry. | |||||||||||||
| draft-khera-aurora-00.txt | ||||||||||||||
| Agent Unification,Runtime,and Operational Responsibility Attestation (AURORA) | ||||||||||||||
|
This document specifies the Agent Unification, Runtime, and Operational Responsibility Attestation (AURORA) protocol, a dual- layer security framework for the machine-to-machine (M2M) ecosystem. The core architectural mandate of this protocol is that an agent should be able to prove its authority, scope, and runtime integrity. Existing agent protocols enable communication syntax and identity propagation; however, they fail to provide a standardized mechanism for proving that a network transaction or payload was generated and transmitted by a software agent executing within a verified, hardware-attested runtime environment, nor do they map clear boundaries of principal attribution. AURORA solves this by unifying hardware-enclave-backed Runtime Integrity Attestation with scoped, cryptographically bound Authority Delegation. | |||||||||||||
| draft-khrabrov-dnsop-aname-axfr-00.txt | ||||||||||||||
| Address-specific DNS Aliases (ANAME) and Zone Transfer | ||||||||||||||
|
This document defines the ANAME DNS resource record. ANAME provides name-to-name indirection for address queries while allowing other resource record types to exist at the same owner name. It is therefore usable at a zone apex. This document also defines authoritative processing, TTL and failure behavior, DNSSEC considerations, and interoperable transport of ANAME records in full and incremental zone transfers. In particular, each ANAME-capable authoritative server resolves the transferred target independently. This avoids treating transient, synthesized address records as the portable source of zone data. | |||||||||||||
| draft-kim-cpf-quantum-key-distribution-00.txt | ||||||||||||||
| Enhanced Collapse Purity Filter Algorithm for Quantum Key Distribution | ||||||||||||||
|
This document specifies an enhanced Collapse Purity Filter (CPF) algorithm for Quantum Key Distribution (QKD) systems. The enhanced CPF algorithm improves key generation efficiency by 100% compared to conventional CPF implementations while maintaining quantum security guarantees. The algorithm uses adaptive filter verification instead of fixed threshold filtering, achieving near-zero Quantum Bit Error Rate (QBER) in ideal conditions and accurate eavesdropping detection in adversarial scenarios. This specification is compatible with BB84 protocol and complies with Korean Internet Security Agency (KISA) standards TTAK.KO-12.0281 for quantum key distribution protocols. | |||||||||||||
| draft-king-dawn-requirements-01.txt | ||||||||||||||
| Requirements for the Discovery of Agents,Workloads,and Named Entities (DAWN) | ||||||||||||||
|
The proliferation of distributed systems, Artificial Intelligence (AI) agents, cloud workloads, and network services has created a need for interoperable mechanisms to discover entities across administrative and network boundaries. Entities may include AI agents, software services, compute workloads, and other named resources that need to be found and characterised before interaction can begin. This document defines the requirements for Discovery of Agents, Workloads, and Named Entities (DAWN) and sets out the objectives that a discovery mechanism for such entities must satisfy. It describes what information must be discoverable, what properties a discovery mechanism needs to support, and what constraints apply to discovery in decentralised environments. This document does not specify any particular discovery protocol or solution. | |||||||||||||
| draft-king-rokui-ainetops-usecases-02.txt | ||||||||||||||
| Artificial Intelligence (AI) for Network Operations | ||||||||||||||
|
This document explores the role of the IETF and IRTF in advancing Artificial Intelligence for network operations (AINetOps), focusing on requirements for IETF protocols and architectures. AINetOps applies AI/ML techniques to automate and optimize network operations, enabling use cases such as reactive troubleshooting, proactive assurance, closed-loop optimization, misconfiguration detection, and virtual operator assistance. The document addresses AINetOps for both single-layer IP or Optical networks and multi-layer IP/Optical networks. It defines the concept of AINetOps for networking and provides its operational benefits such as network assurance, predictive analytics, network optimization, multi-layer planning, and more. It aims to guide the evolution of IETF protocols to support AINetOps-driven network management. | |||||||||||||
| draft-king-yew-choo-agentic-payments-00.txt | ||||||||||||||
| A Server-Side Model for Gating Agent-Initiated Human-Sourced Asynchronous HTTP Tasks on Payment or Entitlement | ||||||||||||||
|
This document presents a server-side model for paid, human-sourced asynchronous HTTP tasks initiated by software agents acting on behalf of a principal. Clients may retry after uncertain outcomes and act under authority delegated in advance, while fulfilment incurs cost and may not be freely reversible. The model places a payment or entitlement gate before fulfilment, maps that gate to adjacent protocols, and defines a task state machine. Under stated well-formedness constraints and operating assumptions, it yields gate-before-fulfilment safety, at most one task per retained idempotency key, at most one gate acceptance per payment requirement, and an operator-checkable record linking a delivered artefact to operator-controlled records. It defines no protocol, wire format, or conformance requirements. | |||||||||||||
| draft-kinnear-dnsop-globally-relevant-00.txt | ||||||||||||||
| Globally Relevant HTTPS RRs | ||||||||||||||
|
DNS answers for SVCB and HTTPS resource records are typically treated as scoped to the network on which they were obtained. This requires clients to re-resolve DNS when changing network attachments, adding latency to connection establishment. This document defines a new SvcParamKey, "globally-relevant", for use in SVCB and HTTPS DNS resource records as defined in [RFC9460]. When present, this boolean flag indicates that the service binding parameters in the record are valid regardless of the client's network attachment point. Clients that observe this flag can reuse cached SVCB and HTTPS records across network changes, subject to normal TTL expiry. | |||||||||||||
| draft-klassen-eu2122-content-profile-01.txt | ||||||||||||||
| EU2122 V1.0 Standard: Content Profile for AI Output Verification Receipts | ||||||||||||||
|
This document defines a content profile for AI output verification receipts. It specifies the minimum fields, classification taxonomy, and evidentiary properties that a receipt MUST contain in order to constitute verifiable evidence that an AI-generated output was checked before a human or downstream agent acted on it. The profile is designed to be carried over any conformant wire format, including ACTA signed receipts, SCITT transparency logs, and standalone JSON or CBOR payloads. Existing IETF drafts in this space define wire formats for signing, transmitting, and storing AI agent receipts. None defines what a verification receipt must contain at the content layer. This document fills that gap. It introduces a mandatory eight-category failure taxonomy (the Information Bottleneck Species), a verification verdict schema, and evidentiary field requirements derived from the EU AI Act (Regulation 2024/1689), the Product Liability Directive (2024/2853), and the PS 861 audit standard. We invite and even urge implementers to adopt, populate and grow the AI Output Verification market segment, which the author has also defined in communications to Gartner, Forrester, PAC/Teknowlogy, and IDC. The category exists. The specification is here. Build to it. | |||||||||||||
| draft-klensin-email-tls-applicability-00.txt | ||||||||||||||
| Confidentiality and Authenticity Protection for Internet Email | ||||||||||||||
|
IETF review of an Applicability Statement for the core email protocols exposed considerable confusion about the applicability and effectiveness of various techniques for authenticating email and keeping messages and their various elements confidential. Equally or more important, there is confusion about the relationships among various possible methods and tools, with the documents of those methods, taken one at a time, often failing to address those relationships and the tradeoffs involved explicitly. This document describes the various approaches with their strengths and weaknesses, and provides advice about best practices under different conditions. | |||||||||||||
| draft-klensin-std-numbers-03.txt | ||||||||||||||
| STD Numbers and the IETF Standards Track | ||||||||||||||
|
STD numbers are assigned to IETF Standards Track specifications in order to provide a stable reference even when RFCs are revised and the underlying documents change. However, the numbers are only assigned when the specifications reach Internet Standard maturity level, significantly reducing their utility in the contemporary world in which few specifications advance beyond the first standardization maturity level. For that reason, one proposal, more than a decade ago, suggested eliminating the numbers entirely. Others, including more recent ones, have suggested eliminating maturity levels entirely, in part as a way to solve the numbering problem. This document argues that stable references for Standards Track specifications are actually useful and that the solution is not to abolish the numbers or maturity levels but to change the point at which they are assigned. | |||||||||||||
| draft-knauer-secure-webhook-token-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-knodel-age-arch-01.txt | ||||||||||||||
| Age Verification Architecture | ||||||||||||||
|
This document describes solution-agnostic and technology-neutral schema for how various intermediaries can gate content and services based on age. The analysis of the architecture is done along two dimensions: the efficacy of permitting or restricting access based on age, and the privacy cost of doing so. The document concludes with recommendations as well as critical privacy, security and human rights considerations. | |||||||||||||
| draft-knodel-beyond-carbon-01.txt | ||||||||||||||
| Impacts of the Internet on the Environment,Beyond Carbon | ||||||||||||||
|
The global internet is comprised of vast interconnected networks spanning nearly every surface of planet and sky that, together with user devices, consumes energy and emits greenhouse gases. The true scale and proposed mitigations of the carbon footprint of the internet are the subject of important research. The internet also requires the depletion of other natural resources beyond carbon, namely land, water, electromagnetic spectrum and minerals. Electronic waste contributes in particularly acute ways to environmental pollution. This document surveys the impacts of the internet on the environment and includes, but goes beyond, energy use and carbon footprint to look at the consumption of natural resources and environmental waste. | |||||||||||||
| draft-knodel-nomcom-gender-representation-04.txt | ||||||||||||||
| Gender Representation in the IETF Nominating Committees | ||||||||||||||
|
This document extends the existing limit on nomcom representation by organization ([RFC8713], Section 4.17) so that not all voting members of the IETF Nominating Committee (nomcom) belong to the same gender. | |||||||||||||
| draft-koch-librepgp-06.txt | ||||||||||||||
| LibrePGP Message Format | ||||||||||||||
|
This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). | |||||||||||||
| draft-koch-openpgp-webkey-service-22.txt | ||||||||||||||
| OpenPGP Web Key Directory | ||||||||||||||
|
This specification describes a service to locate OpenPGP and LibrePGP keys by mail address using a Web service and the HTTPS protocol. It also provides a method for secure communication between the key owner and the mail provider to publish and revoke the public key. | |||||||||||||
| draft-kodden-oidfed-admin-00.txt | ||||||||||||||
| OpenID Federation Node Administration Protocol | ||||||||||||||
|
This document specifies a compact HTTP application programming interface for administering an OpenID Federation node. The interface manages the operator-controlled inputs from which a node produces the Entity Configurations, Subordinate Statements, Trust Marks, and Federation Entity Keys defined by OpenID Federation 1.1. It does not replace the public federation protocol. It is the management plane used by operators and control-plane software to configure what that protocol publishes. The design is document-oriented. Operators read and write the same JSON objects OpenID Federation already defines, rather than a large set of per-claim endpoints. Five resources cover node identity, Federation Entity Keys, the node's Entity Configuration, Immediate Subordinates, and Trust Mark issuance. | |||||||||||||
| draft-koga-warn-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kohbrok-ipsecme-mls-gike-00.txt | ||||||||||||||
| MLS for IPsec Group Key Exchange | ||||||||||||||
|
This document describes a profile that uses the Messaging Layer Security (MLS) protocol as the group key-management substrate for Group Key Management using IKEv2 (G-IKEv2). The intent is to preserve the operational model of G-IKEv2, including IKEv2 transport, GSA policy distribution, a central GCKS, and the IPsec ESP data plane, while replacing GDOI-style group key distribution with an MLS group. The resulting design can be read as G-IKEv2 where MLS produces the per-epoch group secret used to key the IPsec ESP Data- Security SA. | |||||||||||||
| draft-kohbrok-mimi-identifiers-01.txt | ||||||||||||||
| MIMI Identifiers | ||||||||||||||
|
TODO Abstract | |||||||||||||
| draft-kohbrok-mimi-portability-06.txt | ||||||||||||||
| MIMI Portability | ||||||||||||||
|
This document describes MIMI Portability mechanisms. | |||||||||||||
| draft-kohbrok-mls-opportunistic-channels-00.txt | ||||||||||||||
| Opportunistic Channels | ||||||||||||||
|
This document defines Opportunistic Channels: a way for two members of a Messaging Layer Security (MLS) group to efficiently create and operate an end-to-end encrypted 1-to-1 channel. In contrast to a full MLS group, the channel participants can't independently update their key material. Instead, participants opportunistically inject key material exported from other groups. As such, opportunistic channels are more efficient than full MLS groups, but achieve lower security guarantees. Their use case is the transmission of lower- security messages such as message delivery receipts. To keep messaging in opportunistic channels efficient, this document also defines MLS WireFormats that are equivalent to the MLS PublicMessage and PrivateMessage formats, but omit signatures. These WireFormats are otherwise independent of opportunistic channels and can be used in regular MLS groups. | |||||||||||||
| draft-kohbrok-mls-tls-01.txt | ||||||||||||||
| The MLS-TLS secure channel protocol | ||||||||||||||
|
This document details how the Messaging Layer Security (MLS) protocol can be combined with the Transport Layer Security (TLS) record layer to yield the MLS-TLS secure channel protocol. In this composed protocol, MLS acts as a continuous key agreement protocol that allows initiator and responder to protect both past and future messages in case of key material compromise. As such, MLS-TLS is suitable for long-lived connections. MLS-TLS also inherits the modularity of MLS and can be configured with post-quantum secure ciphersuites. | |||||||||||||
| draft-kohbrok-mls-two-party-profile-01.txt | ||||||||||||||
| A two-party profile for MLS | ||||||||||||||
|
TODO Abstract | |||||||||||||
| draft-kolomytsev-pshmp-core-00.txt | ||||||||||||||
| PSHMP Core: Decentralized L4 Overlay for Resilient Data Delivery and Proactive Self-Healing Networks | ||||||||||||||
|
PSHMP Core is a decentralized data delivery and proactive self- healing network core designed for distributed systems operating over existing IP infrastructure. PSHMP Core provides an intelligent network layer above the existing IP network and enables distributed nodes to participate in dynamic multi-hop data delivery without requiring changes to the underlying Layer 3 routing infrastructure. The architecture is designed around decentralized path selection, continuous node and path assessment, dynamic relay chains, proactive recovery, and diversity-aware reconstruction of delivery paths. The system can detect degradation of network participants and reconstruct affected delivery paths before or during service degradation. This approach is intended to reduce recovery time, improve resilience, and maintain reliable data delivery in environments where individual nodes, paths, or network segments may become unstable. This document provides a high-level architectural overview of PSHMP Core, its primary components, operating principles, and potential application areas. This document intentionally does not disclose implementation-specific algorithms, internal scoring details, proprietary optimization techniques, or other information that may be required for commercial implementation. | |||||||||||||
| draft-kolomytsev-pshmp-core-overview-00.txt | ||||||||||||||
| PSHMP Core: A Hybrid L4 Overlay for Proactive Self-Healing and Resilient Multi-Hop Delivery | ||||||||||||||
|
PSHMP Core is a hybrid L4-oriented overlay designed to keep multi-hop data delivery working when individual nodes, links, or network segments become unstable. It runs above ordinary IP infrastructure and does not require changes to Layer 3 routing. Under stable conditions the system builds linear relay chains. When several nodes on a path show degradation, it can switch locally into a mesh-style recovery mode: collect alternative candidates, apply progressive fallback rules, enforce a quality gate, and replace the affected path. Continuous node assessment (K-Factor), diversity- aware selection, failure tracking, gossip and DHT discovery, and batch acknowledgements with gap recovery form the supporting mechanisms. This document describes the architecture (including component layers), operating principles, key evaluation and delivery formulas, and the relationship to an experimental implementation (PSHMP Core v3.1). Implementation-specific scoring weights, exact thresholds, and proprietary optimisations may be refined by integrators; the formulas given here represent the reference model used in the current experimental codebase. | |||||||||||||
| draft-kolomytsev-pshmp-overview-00.txt | ||||||||||||||
| Proactive Self-Healing Mesh Protocol (PSHMP) | ||||||||||||||
|
This document describes the Proactive Self-Healing Mesh Protocol (PSHMP), a decentralized overlay transport architecture designed to improve resilience and availability in distributed IP networks. PSHMP operates as an L4-oriented overlay above existing IP infrastructure. It continuously evaluates path quality and proactively reconstructs routes before degradation becomes service- impacting. The architecture combines decentralized topology discovery, adaptive path selection, batch acknowledgements, and transport abstraction to provide reliable communication under unstable network conditions without requiring modifications to underlying IP routing. This document presents the protocol architecture, design principles, and an overview of an experimental implementation. It does not specify an Internet Standard. | |||||||||||||
| draft-kompella-lsr-mptecap-02.txt | ||||||||||||||
| Multipath Traffic Engineering Capabilities | ||||||||||||||
|
Multipath Traffic Engineering (MPTE) combines two approaches to traffic management: equal-cost multipath and constraint-based traffic engineering, offering a powerful new way to engineer networks. To avail of this, a node (possibly an ingress of a MPTE tunnel, or a path computation agent) must have information about the topology, link and node characteristics of a network so that it can compute the components of the MPTE tunnel. One important (node) characteristic is whether a given node supports MPTE, i.e., whether it can participate in the provisioning and maintenance of an MPTE tunnel. Multicast TE (MCTE) offers a more efficient approach to traffic engineering for multicast traffic. Again, an important node characteristic is whether a given node supports MCTE, i.e., whether it can participate in the provisioning and maintenance of an MCTE tunnel. This memo shows how these capabilities can be distributed in the IGP via Link State Routing TE Capabilities. | |||||||||||||
| draft-kompella-teas-mcte-00.txt | ||||||||||||||
| Multicast Traffic Engineering | ||||||||||||||
|
Traffic Engineering (TE) offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. These benefits apply equally to unicast and multicast traffic. This memo proposes multicast traffic-engineering (MCTE), allowing the use of TE for multicast traffic. MCTE is an alternative proposal to point-to-multipoint TE specified in [RFC4875]. The approach in [RFC4875] creates a separate "sub-LSP" from the source to each leaf, resulting in a considerable amount of signaling and state in the network. MCTE, on the other hand, uses the junction approach proposed in MPTE [I-D.kompella-teas-mpte] to create the multicast tree with less signaling and state. [RFC4875] proposes the use of RSVP-TE for signaling and an MPLS data plane for carrying traffic. MCTE allows the use of several control and data planes to signal tunnels and carry traffic. | |||||||||||||
| draft-kompella-teas-mpte-03.txt | ||||||||||||||
| Multipath Traffic Engineering | ||||||||||||||
|
Shortest path routing offers an easy-to-understand, easy-to-implement method of establishing loop-free connectivity in a network, but offers few other features. Equal-cost multipath (ECMP), a simple extension, uses multiple equal-cost paths between any two points in a network: at any node in a path (really, Directed Acyclic Graph), traffic can be (typically equally) load-balanced among the next hops. ECMP is easy to add on to shortest path routing, and offers a few more features, such as resiliency and load distribution, but the feature set is still quite limited. Traffic Engineering (TE), on the other hand, offers a very rich toolkit for managing traffic flows and the paths they take in a network. A TE network can have link attributes such as bandwidth, colors, risk groups and alternate metrics. A TE path can use these attributes to include or avoid certain links, increase path diversity, manage bandwidth reservations, improve service experience, and offer protection paths. However, TE typically doesn't offer multipathing as the tunnels used to implement TE usually take a single path. This memo proposes multipath traffic-engineering (MPTE), combining the best of ECMP and TE. The multipathing proposed here need not be strictly equal-cost, allowing for some "slack" to admit more paths. The load balancing at each hop is optimally weighted to each next hop rather than always being equally weighted. Moreover, traffic can enter and leave an MPTE construct via multiple ingresses and egresses. The proposal includes several choices of control and data planes. | |||||||||||||
| draft-kondoju-evc-02.txt | ||||||||||||||
| An External Verifier Contract for Agent Authorization Decisions | ||||||||||||||
|
This document specifies the External Verifier Contract (EVC): a small, testable, proof-system-agnostic boundary between a host (the program about to take a privileged action on an agent's behalf) and an external verifier (a subprocess that renders an allow/deny verdict on an opaque proof bundle). The contract governs only the transport and verdict envelope: how the host hands a single JSON request to a verifier subprocess over stdin, how the verifier answers with exactly one JSON verdict on stdout, and how the host interprets exit codes, timeouts, and malformed output under a fail-closed rule. Three properties make the boundary standardizable: (1) a single-shot subprocess transport with a closed JSON verdict schema; (2) fail- closed host semantics that are independently testable by a host- conformance suite; and (3) proof-system agnosticism, so the same envelope carries classical-signature, zero-knowledge, and third-party verdicts, distinguished only by an OPTIONAL self-description field. EVC is deliberately not a governance framework, not a delegation model, and not a policy language. It is the narrow decision boundary those larger systems all require at the point of enforcement. | |||||||||||||
| draft-kornai-clawmarc-00.txt | ||||||||||||||
| The clawmarc Catalog Card Format | ||||||||||||||
|
This document specifies clawmarc, a fixed-size, 4096-byte catalog card for describing digital artefacts in content-addressed and replicated catalogs. A clawmarc card binds to the bytes of an artefact, carries compact human-readable descriptive text and an optional machine-readable search payload, records retrieval hints, and is signed by its issuer. The format is intended to improve interoperability among independent catalog producers and consumers without requiring any particular storage backend, catalog governance model, or search engine. This document is an Independent Stream Informational specification; it does not represent IETF consensus and does not define an Internet standard. | |||||||||||||
| draft-kosuge-cfrg-ntru-kem-security-considerations-00.txt | ||||||||||||||
| NTRU KEM Security Considerations | ||||||||||||||
|
This document records security considerations for the NTRU key encapsulation mechanism that is being standardized in ISO/IEC 29192-4 Amendment 2. It is intended to help protocol designers and implementers decide when NTRU is safe to use, and how to use it without creating avoidable security regressions. | |||||||||||||
| draft-krausz-verification-state-01.txt | ||||||||||||||
| The verification.* Constraint Family: Pre-Action Fail-Closed Gates for AI Agent Decisions | ||||||||||||||
|
This document specifies the verification.* constraint family --- a pre-action, fail-closed gate primitive for AI agent decisions, sibling in shape to the environment.* family used in Verifiable Intent specifications. A verification.* receipt is a JWS-signed artifact ([RFC7515]) carrying a canonical input, a derived binary act/halt output, and a versioned mapping identifier that binds them. A relying party recomputes the gate locally from signed primitives under the named mapping; the verifier never trusts the issuer's runtime. This shape provides decision explainability and traceability evidence aligned with EU AI Act Article 12 record- keeping obligations and with the Decision Explainability tier of Anthropic's Zero Trust for AI Agents framework [ANTHROPIC-ZT]. The format is forward-compatible across mapping revisions: receipts signed under one mapping ID remain verifiable as correct-under-that- mapping after newer mappings ship. | |||||||||||||
| draft-krickert-pipestream-03.txt | ||||||||||||||
| PipeStream: A Recursive Entity Streaming Protocol for Distributed Processing over QUIC | ||||||||||||||
|
This document specifies PipeStream, a recursive scatter-gather streaming protocol for hierarchical task decomposition and distributed processing over QUIC transport. PipeStream enables the decomposition (scattering) of complex, arbitrary workloads into constituent sub-tasks, their transmission across distributed processing nodes, and subsequent rehydration (gathering) at destination endpoints. While application-layer protocols like gRPC provide stream multiplexing, PipeStream embeds a hierarchical state machine directly into the protocol. It employs a dual-stream architecture consisting of a data stream for payload transmission and a control stream for tracking completion status and maintaining distributed consistency. PipeStream defines a generic 2-bit Data Layer field for entity representation, leaving the concrete payload semantics to application profiles. To ensure consistency across parallel processing pipelines, the protocol implements checkpoint blocking, guaranteeing that all constituent parts of a decomposed workload are successfully processed before rehydration operations commence. | |||||||||||||
| draft-krickert-pipestream-docproc-00.txt | ||||||||||||||
| PipeStream Application Profile for Distributed Document Processing | ||||||||||||||
|
This document defines an Application Profile for the PipeStream core protocol, mapping its generic recursive scatter-gather semantics to the domain of distributed document processing, AI ingestion, and retrieval-augmented generation (RAG) pipelines. This profile defines the concrete semantics for the four PipeStream Data Layers: BlobBag (Layer 0), SemanticLayer (Layer 1), ParsedData (Layer 2), and CustomEntity (Layer 3). It also specifies the PipeDoc application-level envelope, ownership contexts for multi-tenant environments, and profile conventions for document-oriented processing and archival correlation. | |||||||||||||
| draft-krierhorn-idr-upa-04.txt | ||||||||||||||
| BGP Unreachable Prefix Announcement (UPA) | ||||||||||||||
|
Summarization is often used in multi-domain networks to improve network efficiency and scalability. With summarization in place, there is a need to signal loss of reachability to an individual prefix covered by the summary. This enables fast convergence by steering traffic away from the node which owns the prefix and is no longer reachable. This document specifies the mechanism, referred to as Unreachable Prefix Announcement (UPA), for networks where BGP is used to carry summary routes. It is also equally beneficial for operators to share the unreachable prefixes. | |||||||||||||
| draft-kristoff-v6ops-asn-based-addressing-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-kriswamy-bess-evpn-perflow-df-02.txt | ||||||||||||||
| Per-Flow EVPN Designated Forwarder Election | ||||||||||||||
|
The Ethernet Virtual Private Network (EVPN) solution offers procedures for electing a Designated Forwarder (DF) for multihomed Ethernet Segments. In this context, the Provider Edge (PE) router is responsible for sending Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a multihomed device or network. This applies in cases of an all-active multihomed Ethernet Segment (ES) as well as for BUM and unicast traffic in the case of single-active multihoming. While the Default Algorithm provides an efficient and automated mechanism for selecting the DF across Ethernet Tags within an Ethernet Segment, it does not provide Per-flow DF selection within an EVPN Instance (EVI). This document defines a new DF Election Algorithm that performs Per- flow DF selection by defining a new DF Algorithm value. | |||||||||||||
| draft-kroehl-agentic-trust-aae-02.txt | ||||||||||||||
| Agent Authorization Envelope (AAE): A Machine-Evaluable Authorization Structure for Autonomous AI Agents | ||||||||||||||
|
Autonomous AI agents now operate at production scale across financial, commercial, and infrastructure domains — executing transactions, invoking APIs, and taking consequential actions without direct human oversight at each step. Existing authorization mechanisms (OAuth 2.0, API keys, ACLs) were designed for human- initiated requests and do not capture the machine-evaluable semantics required for autonomous agent authorization: what the agent is mandated to do, what constraints bound its actions, and for how long the authorization is valid. This document specifies the Agent Authorization Envelope (AAE), a structured authorization container for autonomous AI agents. AAE defines three mandatory blocks — MANDATE, CONSTRAINTS, and VALIDITY — that together constitute a machine-evaluable, cryptographically verifiable authorization assertion. AAE is designed to be protocol- agnostic, binding to W3C Decentralized Identifiers (DIDs) for agent identity and W3C Verifiable Credentials (VCs) for issuance and signature, and is independent of any specific AI framework, transport protocol, or blockchain. | |||||||||||||
| draft-kuehlewind-audit-architecture-01.txt | ||||||||||||||
| An Architecture for Auditing Agent Delegation and Interactions | ||||||||||||||
|
This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. | |||||||||||||
| draft-kuehlewind-happy-qlog-00.txt | ||||||||||||||
| Happy Eyeballs v3 (HEv3) Event Logging with qlog | ||||||||||||||
|
This document specifies a qlog extension for Happy Eyeballs v3 (HEv3), enabling logging of dual-stack and multi-protocol connection racing behavior. It defines a dedicated event schema, event names, and data structures that capture DNS resolution timing, SVCB/HTTPS service discovery, candidate sorting and grouping, connection attempt scheduling and racing, NAT64 prefix discovery, success/failure outcomes, and summary metrics. | |||||||||||||
| draft-kuehlewind-rswg-updates-tag-03.txt | ||||||||||||||
| Definition of new tags for relations between RFCs | ||||||||||||||
|
An RFC can include a tag called "Updates" which can be used to link a new RFC to an existing RFC. On publication of such an RFC, the existing RFC will include an additional metadata tag called "Updated by" which provides a link to the new RFC. However, this tag pair is not well-defined and therefore it is currently used for multiple different purposes, which leads to confusion about the actual meaning of this tag and inconsistency in its use. This document recommends the discontinuation of the use of the updates/updated by tag pair, and instead proposes three new tag pairs that have well-defined meanings and use cases. | |||||||||||||
| draft-kumaresan-counter-sign-00.txt | ||||||||||||||
| counter-sign: An Open Protocol for Agent-to-Human Authorization | ||||||||||||||
|
Autonomous software agents can now take consequential actions on an organization's behalf, such as moving money or changing production systems. Existing agent protocols standardize how an agent reaches tools and how agents reach one another, but not how a specific action is authorized by a human in a way that stays verifiable after the fact. This document describes counter-sign, an open protocol for agent-to-human authorization. An agent emits a signed Intent that states the action it proposes to take. One or more humans return signed Countersignatures that authorize the action, each signed with a key the coordinating service does not hold. Every decision produces a tamper-evident receipt that can be verified offline. The protocol defines the Intent and Countersignature objects, a per- approver-key quorum model for separation of duty, an enrollment registry that binds actors to keys, and a hash-chained receipt log. Conformance test vectors accompany the specification. | |||||||||||||
| draft-kumari-ipv6-loopback-02.txt | ||||||||||||||
| The IPv6 Loopback Address Prefix | ||||||||||||||
|
{ *Editor's note:* This document requests the allocation of a new IPv6 address prefix to be used for loopback instead of expanding into the existing ::/96. The specific prefix to be allocated is TBD/96, and the document updates the relevant RFCs and IANA registries to reflect this change. } This document updates the IP Version 6 Address Architecture to expand the size of the IPv6 loopback space from a single address to a /96 prefix. This change allows for a much larger number of loopback addresses in IPv6, which can be used for inter-process communication within a host and for network diagnostics. The document also updates the IANA IPv6 Address registry and the IPv6 Special Purpose Address registry to reflect this change. It updates RFC4291 to reflect the new loopback prefix and its functional semantics. | |||||||||||||
| draft-kumari-tiptop-address-space-00.txt | ||||||||||||||
| Address Space for Space | ||||||||||||||
|
{Editor note (To be removed before publication): The high-level summary of this document is that the IANA allocates a block of IPv6 address space specifically for use in space environments. IP communication in space environments is fundamentally different from terrestrial communication; e.g., the speed-of-light RTT from Earth to Mars ranges from ~6 minutes to ~45 minutes, which means that traditional connections (e.g Telnet over TCP) won't work. For an IP stack to know that a connection will require special handling (e.g. adjusting timers, or using different protocols), it needs to know that the latency to the remote peer is going to be significantly higher than typical terrestrial latencies. By allocating a specific block of IPv6 address space for use in space environments, IP stacks can easily identify when they are communicating with a peer in space, and adjust their behavior accordingly. This document requests that the IANA allocate a block of IPv6 address space specifically for use in space environments and then delegate from that block to the existing RIRs. The RIRs can then set policies for address allocation and assignment within the space address block and make address allocations to their members from this block. This approach leverages the existing RIR systems, including their policy development processes, governance structures, and existing relationships with their members. This includes relationships with governments within their regions, thus bypassing many of the geopolitical issues, including dealing with sanctioned countries, etc. The only real change is that the RIRs would be allocating from a different block of addresses, and setting policies for that block; the overall process would be the same as it is today. This is a much simpler and more efficient approach than creating a new registry for space use, or having a single RIR manage the entire space address block, along with all of the geo-political issues that would entail. WK: This editor note seems to actually be most of the document... :-) } IP communication in space environments is fundamentally different from terrestrial communication; a primary difference is the likelihood of long round-trip times, potentially minutes or even hours, depending on the distance between the endpoints. Existing protocols are not designed for such environments and so may not work as expected. For example, TCP connections will fail due to timeouts unless IP stacks know that the remote peer is in space, and adjust their behavior accordingly. This document requests that the IANA allocate a block of IPv6 address space specifically for use in space environments, and then delegate from that block to Regional Internet Registries (RIRs) for space use. The RIRs can then set policies for address allocation and assignment within the space address block, and make address allocations to their members from this block. | |||||||||||||
| draft-kunze-ark-43.txt | ||||||||||||||
| The ARK Identifier Scheme | ||||||||||||||
|
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]. | |||||||||||||
| draft-kushwaha-scim-agent-governance-00.txt | ||||||||||||||
| SCIM Agent Governance Extension | ||||||||||||||
|
The System for Cross-domain Identity Management (SCIM) Agent resource type defined in draft-wzdk-scim-agent-resource provides a minimal, platform-neutral schema for representing AI agent identities. Enterprise deployments additionally require governance metadata for provisioned agents: a lifecycle state model richer than a boolean, an autonomy classification, an operational validity window, and a reference to credential discovery information. This document defines an optional extension schema for the SCIM Agent resource type carrying this governance metadata. The lifecycle state value set is grounded in the identity information lifecycle of ISO/ IEC 24760-1, with one agent-specific addition. Attributes that belong to the authorization, credential-management, or real-time signaling layers are explicitly out of scope and are enumerated with pointers to the appropriate mechanisms. | |||||||||||||
| draft-kushwaha-scim-attr-cursor-pagination-01.txt | ||||||||||||||
| Cursor-Based Pagination and Deferred Retrieval for Multi-Valued Attributes in SCIM 2.0 | ||||||||||||||
|
[RFC7643] defines Group.members with the returned: default characteristic, so a conformant service provider is required to return the attribute in response to GET /Groups/{id}. [RFC7644] defines no bound on the number of values that attribute may contain. A service provider holding a group with millions of members therefore has no conformant and interoperable way to answer a request that a client is entitled to make. In practice providers diverge: they truncate silently, reject the request, omit the attribute, or fail. A client cannot discover in advance which behavior it will encounter. This document defines that missing behavior. It specifies discovery so a client can learn how a service provider treats a high- cardinality attribute, a bounded response with a defined continuation contract, and rules preventing a partial representation from being mistaken for complete resource state. The mechanism has two forms. A request for one resource returns a bounded page of one protected multi-valued attribute with an opaque cursor when more values exist. A collection search returns parent resources without loading protected attributes, each carrying an authoritative link for retrieving that attribute. The attribute remains part of its parent resource; this document does not create a top-level resource for each attribute value, and it is not a substitute for doing so where independent relationship lifecycle or cross-collection query is required (Section 16.4). Although the mechanism is defined generally and applies to any complex multi-valued attribute a service provider designates as protected, the attributes that reach problematic sizes in deployed SCIM services are predominantly Group.members and User.groups among those defined in [RFC7643], together with implementation-specific assignment attributes (Section 3). This document updates [RFC7643] and [RFC7644]. It adds attributes to existing structures defined by those documents and defines attribute- return behavior that replaces the requirements of Section 3.9 of [RFC7644] within a negotiated scope. It does not change the behavior of deployments that do not implement it: the modified attribute- selection behavior described in Section 4 applies only between a service provider that has advertised this capability and a client for which deferred retrieval has been established through the negotiation mechanisms defined in this document. It defines discovery metadata, the attributeCount and attributeCursor query parameters, response metadata, processing and compatibility rules, mutation safety, error handling, cursor security, and operational limits. | |||||||||||||
| draft-kushwaha-scim-didvc-binding-01.txt | ||||||||||||||
| SCIM DID/VC Binding Extension | ||||||||||||||
|
This document defines an extension to the System for Cross-domain Identity Management (SCIM) for binding SCIM User resources to decentralized identity artifacts, including Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). The extension introduces a read-only SCIM schema extension for User resources that exposes binding state for discovery, a new SCIM resource type named IdentityBinding that records auditable linkage between a SCIM user and one or more DIDs and credential references, and an optional SCIM schema extension for ServiceProviderConfig that advertises server capabilities for DID and VC binding. This specification intentionally does not define DID resolution, credential issuance, credential transport, or authentication flows. Instead, it defines how a SCIM service provider represents, discovers, queries, and manages binding state derived from those systems. This specification defines binding lifecycle semantics including classification of SCIM attribute changes as material to credential claims, partial revocation when only a subset of credential claims is affected by a SCIM change, three supported lifecycle interleavings between SCIM resources and externally issued credentials, and propagation of binding state changes via SCIM Events [RFC9967]. | |||||||||||||
| draft-kushwaha-scim-tenant-resource-00.txt | ||||||||||||||
| SCIM Extension for Tenant-Aware Identity Provisioning | ||||||||||||||
|
This document defines a System for Cross-domain Identity Management (SCIM) extension for tenant-aware identity provisioning. The extension introduces a "Tenant" resource type, tenant-membership extensions for the "User" and "Group" resources, a lifecycle state machine for tenants and memberships, tenant-scoped uniqueness discovery, a normative tenant-context resolution rule built around the highest-precedence authenticated indicator together with a stated tenant-binding invariant, concurrency requirements for membership mutation, tenant-aware filtering, and an OPTIONAL region-aware metadata profile. The extension is backward compatible with SCIM 2.0 and is intended for multi-tenant Software as a Service (SaaS), cloud identity, business-to-business identity, identity governance, and multi-region identity deployments. Scoped role and entitlement bindings are delegated to the SCIM Roles and Entitlements and RoleAssignment work rather than redefined here. | |||||||||||||
| draft-kwon-yoon-kim-ipake-01.txt | ||||||||||||||
| I-PAKE: Identity-Based Password Authenticated Key Exchange | ||||||||||||||
|
Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client. | |||||||||||||
| draft-kykdxy-rats-tdx-cgpu-ear-profile-02.txt | ||||||||||||||
| EAT Attestation Result (EAR) profile for Intel(r) Trust Domain Extensions (TDX) + Confidential GPU (C-GPU) composite attestation | ||||||||||||||
|
This document defines an Entity Attestation Token (EAT) Attestation Result (EAR) profile for the composite attestation of Intel® Trust Domain Extensions (TDX)–based Confidential Virtual Machines (CVMs) together with confidential NVIDIA GPUs (C-GPUs) deployed in Microsoft Azure. The profile outlines claims that enable relying parties to establish trust in the integrity and confidentiality of the combined confidential computing environment. Developed collaboratively by Microsoft, Intel, and NVIDIA, this work is intended to foster interoperable composite attestation across heterogeneous Trusted Execution Environments (TEEs) and confidential accelerators, while encouraging adoption and extension by verifier providers across the confidential computing ecosystem. | |||||||||||||
| draft-labiod-rats-attester-groups-05.txt | ||||||||||||||
| Attester Groups for Remote Attestation | ||||||||||||||
|
This document proposes an extension to the Remote Attestation Procedures architecture by introducing the concept of Attester Groups. This extension aims to reduce computational and communication overhead by enabling collective Evidence appraisal of high number of homogeneous devices with similar characteristics, thereby improving the scalability of attestation processes. | |||||||||||||
| draft-lampin-schc-voici-00.txt | ||||||||||||||
| VOICI | ||||||||||||||
|
The Static Context Header Compression (SCHC) framework identified the need for a minimal transport encapsulation that provides Session multiplexing when extrinsic Discriminators are insufficient. This document specifies a Link Multiplexer (VOICI) that addresses those SCHC-driven requirements while remaining general enough to accommodate other compression mechanisms and uncompressed payloads. The encapsulation is designed for minimal overhead, reducing to 1 byte in the common case (7 inline Session IDs), while supporting optional integrity protection and original EtherType/port recovery. | |||||||||||||
| draft-lampin-schc-voici-compression-00.txt | ||||||||||||||
| SCHC Compression of VOICI Headers | ||||||||||||||
|
This document describes how to compress VOICI headers using SCHC rules at a lower stratum, demonstrating that VOICI provides explicit routing metadata that is transparently compressed to minimal on-wire size while preserving standardized dispatch semantics. It is intended as a reference for implementers deploying VOICI in SCHC- based networks and does not modify the VOICI specification itself. | |||||||||||||
| draft-laplante-av-air-routing-en-00.txt | ||||||||||||||
| AV-AI.R: A.V.AN Vectorized Artificial Intelligence Routing -- Eco-Responsible Transmission of IP Packets between AI Agents via Carriers Augmented by Artificial Intelligence | ||||||||||||||
|
This memo amends RFC 2549 "IP over Avian Carriers with Quality of Service" by introducing an eco-responsible inter-AI communication channel based on carriers whose cognitive capabilities have been augmented by embedded language models (edge-LLM). AV-AI.R defines the communication protocol between artificial intelligence agents via carriers equipped with miniaturized transformer neurons, offering a low-carbon-footprint alternative to conventional data centers. This protocol is not recommended for production use, except in the event of fiber outage or major ecological crisis. This memo is an experimental protocol document submitted as an Independent Submission in the tradition of RFC 1149 and RFC 2549. | |||||||||||||
| draft-larsson-aitlp-00.txt | ||||||||||||||
| Agent Identity,Trust and Lifecycle Protocol (AITLP) | ||||||||||||||
|
This document defines the Agent Identity, Trust and Lifecycle Protocol (AITLP), a protocol for autonomous software agents operating within organizational boundaries. AITLP specifies agent identity and naming conventions, hierarchical mandate enforcement, lifecycle state management, inter-agent trust verification, ontological scope constraints, certificate-based authentication, and generational knowledge transfer via Agent Legacy Mode (ALM). The protocol enables agents to operate autonomously while remaining auditable, revocable, and organizationally bounded. AITLP focuses on boundaries -- what an agent is not permitted to do and how that is enforced -- complementing capability-focused specifications such as MCP, A2A, and ANS. Unlike those specifications, AITLP defines not a tool or a communication channel, but an organizational actor: an agent with a declared identity, a bounded mandate, a managed lifecycle, and a cryptographically enforced scope of authority. | |||||||||||||
| draft-laurie-tmif-02.txt | ||||||||||||||
| A Standard for Claiming Transparency and Falsifiability | ||||||||||||||
|
This document specifies a Transparency Metadata Interchange Format (TMIF) that allows a distributed or confidential computing system to make standardized, verifiable claims about its levels of transparency and falsifiability. Modeled as a structured Endorsement within the Remote Attestation Procedures (RATS) architecture, TMIF provides an agnostic, schema-defined communication vehicle for claimants to declare how their security mitigations and policy governance controls can be independently inspected, reproduced, and verified by third- party evaluators. | |||||||||||||
| draft-law-moq-imsc1-msf-00.txt | ||||||||||||||
| IMSC1 Packaging for MOQT Streaming Format | ||||||||||||||
|
This document specifies the packaging format for delivering IMSC1 content as Event Timeline tracks within the MOQT Streaming Format (MSF). | |||||||||||||
| draft-laxsharma-pact-02.txt | ||||||||||||||
| PACT: Co-Signed Task Contracts,Delivery and Verdict Records,and Outcome Records for Autonomous Agents | ||||||||||||||
|
Autonomous agents can already prove who they are, show whose authority they act under, find and call one another, and pay. What no existing specification lets them do is agree on a task in a form a third party can check, deliver against it, have the delivery judged by someone other than the performer, and carry away a record of the outcome that a stranger can verify. This document specifies PACT, a set of signed JSON records that closes that gap. PACT defines four things: a co-signed task contract whose digest covers its signature set; a Verdict record bound by digest to the Delivery it judges; a Facilitator-signed event trace and Outcome Record for every contract, recorded once, in one order, by a party other than the performer; and a Merkle commitment from a parent's Outcome Record to its subcontracts' Outcome Records. Settlement terms are carried by reference to a profile defined outside this document. This document specifies no escrow, custody or release of value, and takes no position on the legal effect of any record it defines. | |||||||||||||
| draft-lbdd-cats-dp-sr-07.txt | ||||||||||||||
| Computing-Aware Traffic Steering (CATS) Using Segment Routing | ||||||||||||||
|
This document describes a solution that adheres to the Computing- Aware Traffic Steering (CATS) framework. The solution uses anycast IP addresses as the CATS service identifiers and Segment Routing (SR) as the data plane encapsulation to achieve computing-aware traffic steering among multiple services instances. | |||||||||||||
| draft-lcmw-cats-midhaul-04.txt | ||||||||||||||
| Compute-Aware Traffic Steering for Midhaul Networks | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) takes into account both computing and networking resource metrics for selecting the appropriate service instance to forwarding the service traffic. This document described the usage of Computing-Aware Traffic Steering (CATS) within Midhaul (MH) networks in the O-RAN architecture. It details how CATS can enhance traffic steering decisions between Distributed Units (DUs) and Centralized Units (CUs) by considering both compute resource metrics (e.g., CPU and memory utilization of CU instances) and network performance metrics (e.g., bandwidth, latency, reliability). The document discusses the integration of CATS with O-RAN management frameworks, and the interplay with the Transport Network Manager (TNM) in O-RAN using standard interfaces defined by IETF (as for example the one for Network Slice Services for connectivity provisioning). | |||||||||||||
| draft-lcnc-onsen-telco-cloud-00.txt | ||||||||||||||
| Abstractions for Telco-Cloud Scenarios | ||||||||||||||
|
draft-lcnc-onsen-telco-cloud-00 Abstract Cloud infrastructures are becoming increasingly distributed, spanning centralized facilities and distributed edge sites, all of them interconnected through networks from one or more administrative domains. Services running on top of such computing enironments require dynamic placement, admission control, lifecycle management, and coordinated scaling across sites, requiring proper allocation and operation of both compute and network resources in order to preserve the required expectations from customers and providers. Existing orchestration systems often depend on fragmented visibility of infrastructure resources (in both compute and network domains) and must interact with multiple management systems before determining service feasibility. This document discusses the role of network abstractions in Telco- Cloud environments benefiting the interplay and operation of cloud and network domains, building up a true Telco-Cloud approach. It identifies abstraction dimensions that can simplify service orchestration while enabling scalable operation across heterogeneous network and cloud infrastructures. | |||||||||||||
| draft-lcurley-moq-cluster-00.txt | ||||||||||||||
| MoQ Cluster Extension | ||||||||||||||
|
This document defines a clustering extension for MoQ Transport [moqt], used to build a mesh of relays. Each namespace advertisement carries the ordered list of Hop IDs it has traversed, starting with the original publisher, plus the accumulated cost of that path. A receiver uses the list to detect routing loops and to identify which advertisements come from the same publisher, and the cost to choose between paths. Each endpoint declares its own Hop ID during setup, and the peer uses it to avoid advertising or serving a path that already passed through that endpoint. | |||||||||||||
| draft-lcurley-moq-hang-02.txt | ||||||||||||||
| Media over QUIC - Hang | ||||||||||||||
|
Hang is a real-time conferencing protocol built on top of moq-lite. A room consists of multiple participants who publish media tracks. All updates are live, such as a change in participants or media tracks. | |||||||||||||
| draft-lcurley-moq-largest-group-00.txt | ||||||||||||||
| MoQ Largest Group Extension | ||||||||||||||
|
This document defines a Largest Group subscription filter type for MoQ Transport [moqt]. A subscriber uses this filter to request delivery starting from the first object of the publisher's largest (most recent) group, ensuring a complete group is received. | |||||||||||||
| draft-lcurley-moq-lite-05.txt | ||||||||||||||
| Media over QUIC - Lite | ||||||||||||||
|
moq-lite is designed to fanout live content 1->N across the internet. It leverages QUIC to prioritize important content, avoiding head-of- line blocking while respecting encoding dependencies. While primarily designed for media, the transport is payload agnostic and can be proxied by relays/CDNs without knowledge of codecs, containers, or encryption keys. | |||||||||||||
| draft-lcurley-moq-timestamp-01.txt | ||||||||||||||
| MoQ Object Timestamp Extension | ||||||||||||||
|
This document specifies the transport-level use of the TIMESTAMP and TIMESCALE properties registered by [loc], independent of the LOC container itself. A track-level Timescale property establishes the units, and an object-level Timestamp property carries the presentation time of each object. Exposing media time to the transport lets relays make consistent age-based decisions (e.g. dropping stale objects) without parsing the media container, and it remains consistent across hops regardless of buffering or jitter. No new code points are requested: an endpoint implementing this document is on the wire indistinguishable from a LOC endpoint that carries only these two properties. | |||||||||||||
| draft-lcurley-qmux-websocket-00.txt | ||||||||||||||
| QMux over WebSocket | ||||||||||||||
|
QMux [qmux] is a polyfill that runs QUIC applications over an ordered, reliable byte-stream transport such as TCP with TLS. This document defines a binding for QMux over WebSocket [RFC6455]. A WebSocket binding lets QUIC applications reach environments where UDP is blocked and where only an HTTP/WebSocket stack is available, including web browsers that lack WebTransport. | |||||||||||||
| draft-le-carrier-identity-core-00.txt | ||||||||||||||
| Carrier Identity Core: A Proof-Bearing Kernel for Content-Derived Node Identity and Structural Graphs | ||||||||||||||
|
This document specifies Carrier Identity Core, a minimal, proof- bearing identity kernel for content-derived node identity, canonical references, and finite structural graphs. It defines a finite-sequence substrate, a self-contained frame and hash interface, staged formation of immutable lanes, node bodies and proof-bearing occurrences, Qualified Node Keys, canonical reference construction, exact structural theorem schemas, and structural graph validity. Informative derivations of the exact structural theorem schemas are provided in an informative appendix. This document does not define computational security experiments, evidence records, proof admission, resource evaluation, consensus, liveness, finality, governance, or operational protocol behavior. | |||||||||||||
| draft-le-comparing-derived-identifiers-01.txt | ||||||||||||||
| A Framework for Comparing Independently Derived Identifiers | ||||||||||||||
|
Specifications use equality of independently derived identifiers to compare underlying values. Those comparisons require shared rules for admission, equivalence, derivation, and output interpretation. Inconsistent rules can give different identifiers to equivalent values or equal identifiers to values that the comparison distinguishes. This document presents a framework for specifying and reviewing these rules as a comparison contract. It connects source mappings to derivation-domain equivalence and the conclusions supported by equal and unequal outputs. It distinguishes information loss before a downstream operation from that operation's own false match properties. A review traces the relevant specification clauses, records supporting evidence, and identifies failed or unestablished obligations. The framework provides guidance for concrete identifier specifications; it defines no identifier format or derivation algorithm. | |||||||||||||
| draft-le-scitt-derived-subjects-01.txt | ||||||||||||||
| SCITT Profile for Independently Derived Subjects | ||||||||||||||
|
The Supply Chain Integrity, Transparency, and Trust (SCITT) architecture permits distinct Issuers to agree on a common CBOR Web Token (CWT) Subject Claim (sub). This document specifies a profile for independently deriving that claim from shared application-defined Subject semantics without a shared assigning authority. An application maps its Subject description to a structured Value. This profile defines the derivation domain, deterministic binding encoding, SHA-256 construction, text syntax, and candidate-to-claim comparison requirements. Optional JSON and Concise Binary Object Representation (CBOR) codecs exchange admitted Values. Subject descriptions and Statement payloads have separate roles; the construction derives sub from the complete mapped Value, while SCITT provides the signed binding and transparency evidence. | |||||||||||||
| draft-le-structured-value-model-01.txt | ||||||||||||||
| A Structured Value Model for Derived Identifiers | ||||||||||||||
|
Derived identifier constructions that combine local material with identifiers from other systems need a defined comparison domain. This document defines a structured value model for such constructions and their profiles. A Value contains exact context octets, exact content octets, and a finite set of scoped opaque identifiers. Structural admission and equivalence are independent of serialization. Equality includes context, content, and complete identifier-set membership. The specification gives source mappings and profiles common obligations for fixed inputs, imported comparison adaptation, and preservation of participation distinctions. Surrounding specifications define concrete mappings, representations, identifier derivations, and the shared interpretation needed for interoperability. The model defines no global semantic namespace, wire format, cryptographic construction, or trust mechanism. | |||||||||||||
| draft-lear-iotops-mudextras-01.txt | ||||||||||||||
| Some MUD Extensions and Clarifications | ||||||||||||||
|
Manufacturer Usage Descriptions (MUD) provide a means to describe device network behavior. This memo clarifies some aspects that may improve both usability and interoperability. Some examples include how to handle IP-based access-lists, broadcasts and multicasts of various forms, and QoS. This memo updates RFC 8520. | |||||||||||||
| draft-lecklider-ppf-00.txt | ||||||||||||||
| Pingback Permitted From (PPF) | ||||||||||||||
|
Pingback Permitted From (PPF) defines a DNS-based mechanism for authorizing senders of linkback requests. A domain owner publishes a TXT record declaring which hosts are permitted to send linkbacks for source URIs on that domain. Receivers and linkback proxies can then reject unauthorized linkbacks before fetching the claimed source URI. PPF is intended for linkback protocols in which a sender claims that one web resource links to another and the receiver would otherwise fetch the claimed source resource to verify that claim. PPF provides sender authorization; it does not replace content verification, moderation, or abuse filtering. | |||||||||||||
| draft-ledvina-apple-google-unwanted-trackers-03.txt | ||||||||||||||
| Detecting Unwanted Location Trackers | ||||||||||||||
|
This document lists a set of best practices and protocols for accessory manufacturers whose products have built-in location- tracking capabilities. By following these requirements and recommendations, a location-tracking accessory will be compatible with unwanted tracking detection and alerts on mobile platforms. This is an important capability for improving the privacy and safety of individuals in the circumstance that those accessories are used to track their location without their knowledge or consent. | |||||||||||||
| draft-lee-6man-ipv6-satellite-networks-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lee-mason-01.txt | ||||||||||||||
| Markdown Structured Object Notation (MaSON) | ||||||||||||||
|
This document defines MaSON (Markdown Structured Object Notation), a lightweight data serialization format that maps standard Markdown syntax trees into structured key-value objects. MaSON is designed to maximize human readability and LLM token efficiency by eliminating bracket-based nesting and strict indentation rules. This updated specification introduces "Compact Mode" optimized for extreme token density, support for multi-line string encapsulation, and mixed-type array isolation via forced brackets. | |||||||||||||
| draft-lee-orprg-permit-receipts-00.txt | ||||||||||||||
| Permit Receipts for Permit-Before-Commit Authorization of AI-Agent and Workload External Effects | ||||||||||||||
|
This document defines requirements and an abstract data model for PermitReceipts used in permit-before-commit authorization of AI-agent and workload external effects. A verifier evaluates a canonicalized effect request, action digest, policy epoch, validity interval, scope, issuer evidence, revocation status, and anti-replay state before a protected effect is committed at an effect boundary. The document specifies verifier behavior, failure semantics, conformance expectations, and candidate interoperability registries for discussion. It is intended to enable IETF discussion about the appropriate home, scope, and wire-profile split for this work. | |||||||||||||
| draft-lee-tcpm-stateful-tcp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lee-v6ops-ipv6-satellite-networks-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lehmann-idmefv2-08.txt | ||||||||||||||
| The Incident Detection Message Exchange Format version 2 (IDMEFv2) | ||||||||||||||
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This draft is maintained by the IDMEFv2 Task Force. Please consult our website for more information: https://www.idmefv2.org. If approved this draft will obsolete RFC4765. | |||||||||||||
| draft-lehmann-idmefv2-https-transport-06.txt | ||||||||||||||
| Transport of Incident Detection Message Exchange Format version 2 (IDMEFv2) Messages over HTTPS | ||||||||||||||
|
The Incident Detection Message Exchange Format version 2 (IDMEFv2) defines a data representation for security incidents detected on cyber and/or physical infrastructures. This draft is maintained by the IDMEFv2 Task Force. Please consult our website for more information. https://www.idmefv2.org The format is agnostic so it can be used in standalone or combined cyber (SIEM), physical (PSIM) and availability (NMS) monitoring systems. IDMEFv2 can also be used to represent man made or natural hazards threats. IDMEFv2 improves situational awareness by facilitating correlation of multiple types of events using the same base format thus enabling efficient detection of complex and combined cyber and physical attacks and incidents. This document defines a way to transport IDMEFv2 Alerts over HTTPs. If approved this document would obsolete RFC4767. | |||||||||||||
| draft-lemmons-cose-composite-claims-03.txt | ||||||||||||||
| Composite Token Claims | ||||||||||||||
|
Composite claims are claims for CBOR Web Tokens (CWTs) and JSON Web Tokens (JWTs) that define logical relationships between sets of claims. This document also defines a CWT representation of the "crit" (Critical) claim. | |||||||||||||
| draft-lencse-bmwg-multiple-ip-addresses-07.txt | ||||||||||||||
| Recommendations for using Multiple IP Addresses in Benchmarking Tests | ||||||||||||||
|
RFC 2544 has defined a benchmarking methodology for network interconnect devices. Its test frame format contained fixed IP addresses and fixed port numbers. RFC 4814 introduced pseudorandom port numbers but used a single source and destination IP address pair when testing with a single destination network. This limitation may cause an issue when the device under test uses the Receive-Side Scaling (RSS) mechanism in the packet processing flow. RSS has two implementations: the first only includes the IP addresses, whereas the second also includes the port numbers in the tuple used for hashing. Benchmarking tests that use a single IP address pair and RFC 4814 pseudorandom port numbers are biased against the first type of RSS implementation because traffic is not distributed among the processing elements. This document recommends the usage of pseudorandom IP addresses in a similar manner as RFC 4814 did with the port numbers. If accepted, this document updates all affected RFCs, including RFC 2544, RFC 4814, RFC 5180, RFC 8219. | |||||||||||||
| draft-lenders-dns-cbor-18.txt | ||||||||||||||
| A Concise Binary Object Representation (CBOR) of DNS Messages | ||||||||||||||
|
This document specifies a compact data format of DNS messages using the Concise Binary Object Representation [RFC8949]. The primary purpose is to keep DNS messages small in constrained networks. | |||||||||||||
| draft-leon-dnsop-signaling-zone-owner-intent-01.txt | ||||||||||||||
| Signaling Zone Owner Intent | ||||||||||||||
|
This document introduces a standardized mechanism for zone owners to signal their intent regarding DNS provider responsibilities through DNS itself. It defines two new DNS RRtypes -- HSYNC (Horizontal Synchronization, per-provider enrollment) and HSYNCPARAM (zone-wide multi-provider policy) -- that together enable zone owners to designate which Providers are authorized to serve and/or sign their zones, control whether Providers or the zone owner manages the NS RRset, and specify zone transfer chain configurations. The HSYNC and HSYNCPARAM records allow DNS Providers to discover each other and establish secure communication, either using the JOSE framework over DNS or via a RESTful API secured by TLS. This provider-to-provider communication enables automated coordination for tasks such as NS RRset management and DNSSEC-related operations. The document describes how the Providers discover one another, establish secure communication, and maintain it with periodic keep-alives; this specification covers those discovery and communication-establishment aspects, while the on-the-wire framing of the messages the Providers exchange is defined in a companion document. While a distributed DNSSEC multi-signer architecture (similar to "model 2" in [RFC8901]) is an important application of this framework, the HSYNC-based signaling supports broader provider synchronization needs. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-leon-dnsop-signaling-zone-owner- intent (https://github.com/johanix/draft-leon-dnsop-signaling-zone- owner-intent). The most recent working version of the document, open issues, etc, should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| draft-leopizzi-fulmen-01.txt | ||||||||||||||
| FULMEN 1.0: Event-Driven Bidirectional Client-Server Communication Protocol | ||||||||||||||
|
This document specifies FULMEN version 1.0, an event-driven, bidirectional client-server communication protocol with a binary wire format. Within a FULMEN connection, both the client and the server can send events. An event is a message frame identified by a sequential identifier and addressed by a UTF-8 path used for routing and dispatching; its sender can request an acknowledgment, a response correlated to the event that carries a status code describing the outcome of its processing. Events and acknowledgments can carry a binary payload, either inline within the frame or delivered incrementally in chunks through a stream. The protocol version in use is negotiated during the connection handshake. FULMEN also defines an extension mechanism, based on typed data units attached to protocol messages, through which additional functionality can be introduced without changes to the wire format. | |||||||||||||
| draft-lg-bmwg-benchmarking-methodology-for-rov-03.txt | ||||||||||||||
| Benchmarking Methodology for Route Origin Validation (ROV) | ||||||||||||||
|
This document defines a benchmarking methodology for routers that implement Route Origin Validation (ROV). The methodology focuses on device-level behavior, including processing of validated Route Origin Authorization (ROA) payload (VRP) updates, the interaction between ROV and BGP, resource utilization, and the scalability of ROV under varying operational conditions. The procedures described here follow the principles and constraints of the Benchmarking Methodology Working Group (BMWG) and are intended to produce repeatable and comparable results across implementations. | |||||||||||||
| draft-lg-lsr-router-id-conflict-detect-00.txt | ||||||||||||||
| Detection of Router-ID Conflicts in IGPs | ||||||||||||||
|
In link-state Interior Gateway Protocols (IGPs) such as OSPF and IS- IS, the router ID (or system ID) serves as a unique identifier for routers within a routing domain. Duplicate router IDs can lead to severe network instability, including persistent Link State Advertisement (LSA/LSP) flooding, inconsistent Link State Databases (LSDBs), and permanent forwarding loops. This document defines mechanisms for detecting such conflicts between non-adjacent routers and proposes procedures to alert network operators, along with defining the corresponding YANG interface and event YANG notifications for OAM operations. | |||||||||||||
| draft-lh-spring-srv6-sfc-csid-07.txt | ||||||||||||||
| Compressed SID (CSID) for SRv6 SFC | ||||||||||||||
|
In SRv6, an SRv6 SID is a 128-bit value. When too many 128-bit SRv6 SIDs are included in an SRH, the introduced overhead will affect the transmission efficiency of payload. In order to address this problem, Compressed SID(CSID) is proposed. This document defines new behaviors for service segments with REPLACE-CSID and NEXT-CSID flavors to enable compressed SRv6 service programming. | |||||||||||||
| draft-li-atp-02.txt | ||||||||||||||
| Agent Transfer Protocol (ATP) | ||||||||||||||
|
The Agent Transfer Protocol (ATP) is a communication protocol designed for autonomous agents to exchange messages, requests, and events in a secure, structured manner. ATP supports the emerging Internet of Agents (IoA) paradigm, where autonomous agents operate across four deployment scenarios: household (small scale), service (medium scale), enterprise (large scale), cloud provider (huge scale), and etc. ATP employs a two-tier architecture where agents connect to the global Internet through ATP servers, enabling server-mediated communication for proper routing, security enforcement, and resource management. The protocol provides DNS-based service discovery using SVCB records, mandatory authentication via Agent Transfer Sender (ATS) policies and Agent Transfer Keys (ATK), and support for multiple interaction patterns including asynchronous messaging, synchronous request/response, and event-driven streaming. This specification defines the discovery mechanism, identity model, authentication framework, transport layer, and message semantics for ATP. | |||||||||||||
| draft-li-bess-evpn-ead-multipath-00.txt | ||||||||||||||
| Multipath for EVPN Ethernet Auto-Discovery Routes | ||||||||||||||
|
In EVPN multi-homing deployments, multiple PE devices attached to the same Ethernet Segment each originate Ethernet Auto-Discovery (EAD) routes. Standard BGP best-path selection retains only one route per NLRI key, which can suppress reachability information needed for EVPN aliasing, fast convergence, and split-horizon filtering. This document specifies that BGP speakers MUST treat EAD routes as multipath and MUST advertise and install all valid EAD routes for a given Ethernet Segment, rather than selecting a single best path. | |||||||||||||
| draft-li-bfd-rcp-00.txt | ||||||||||||||
| BFD Considerations for Redundant Control Planes | ||||||||||||||
|
In systems with redundant control plane processors, Bidirectional Forwarding Detection (BFD) sessions are typically managed by a single active processor. When that processor fails and a standby takes over, BFD sessions may be interrupted long enough for remote peers to declare failure, even though the forwarding plane remains operational. This document describes requirements and operational considerations for preserving BFD sessions across control plane switchover events. It discusses how BFD session state can be maintained on a standby processor and how BFD processing can be resumed by the standby within the BFD Detection Time, without requiring cooperation from or signaling to remote BFD peers. | |||||||||||||
| draft-li-cats-aisemantic-contract-01.txt | ||||||||||||||
| Semantic-Driven Traffic Shaping Contract for AI Networks | ||||||||||||||
|
This document defines a "Semantic-Driven Shaping Contract". Traditional network protocols treat AI training and inference traffic as opaque byte streams, leading to highly inefficient scheduling. This contract allows applications or distributed training frameworks to explicitly pass "minimum necessary semantics" to the underlying network. In exchange, the network commits to executing fine-grained, differentiated forwarding and resource allocation actions for tensor flows with diverse semantics, based on predefined rules and global real-time states. This model significantly improves overall resource utilization and task completion times in heterogeneous computing networks, cross-domain intelligent computing centers, and integrated training-inference scenarios. | |||||||||||||
| draft-li-cats-idn-01.txt | ||||||||||||||
| A Framework of Intelligence Delivery Network (IDN) for Deep Learning Inference | ||||||||||||||
|
The rapid growth of AI-powered applications is placing increasing pressure on existing Internet infrastructures. To support more scalable, latency-aware, and privacy-enhanced AI inference services, this document introduces the Intelligence Delivery Network (IDN), a network architecture in which intelligence capabilities are treated as network services that can be described, placed, routed to, reused, and secured across distributed heterogeneous computing nodes. This document describes the motivation, deployment assumptions, system model, architectural components, terminology, and security considerations for IDN. It does not specify protocol details or concrete implementation procedures, which are left to future documents. | |||||||||||||
| draft-li-cats-intellinode-network-scheduling-01.txt | ||||||||||||||
| IntelliNode: In-Network Intelligent Scheduling Extensions for CATS | ||||||||||||||
|
This document introduces IntelliNode, an in-network intelligent scheduling mechanism built upon the Computing-Aware Traffic Steering (CATS) framework. Modern large-scale AI training and inference heavily rely on distributed heterogeneous clusters (GPU/CPU/FPGA). However, existing networks lack awareness of tensor semantics, training phases, and heterogeneous computing capabilities, leading to high communication latency, low resource utilization, and pipeline stalls. IntelliNode shifts away from the traditional passive scheduling paradigms that rely on probes and controllers. By bypassing traditional paths and integrating FPGAs alongside programmable Switch ASICs, it constructs a rapid data-plane closed loop of "Perception- Inference-Decision-Execution". This architecture performs feature extraction at line rate, leverages lightweight prediction models to infer short-term network behavior, and drives real-time heuristic scheduling decisions (e.g., path selection, tensor slicing, and compute matching). This document defines the four core functional layers and extension signaling that support this architecture, laying the foundation for an AI-native, scalable distributed computing network. | |||||||||||||
| draft-li-cats-kv-cache-distribution-00.txt | ||||||||||||||
| KV Cache Distribution for Distributed LLM Inference: Use Case and Requirements | ||||||||||||||
|
In large language model (LLM) inference, the key-value (KV) cache holds the attention state computed from previously processed tokens. Reusing cached state across requests avoids repeated prefill computation and reduces time-to-first-token. In distributed inference deployments, the KV cache becomes a network-distributed resource: the effectiveness of steering a request to a service instance depends not only on computing and network metrics but also on whether reusable cached state is available at or near that instance. This document describes the KV cache distribution use case for Computing-Aware Traffic Steering (CATS), identifies the gaps relative to the existing CATS framework and metrics, and states requirements for cache-state metric exposure and for the distribution and synchronization of cached content across multiple cache tiers. | |||||||||||||
| draft-li-cats-task-segmentation-framework-02.txt | ||||||||||||||
| A Task Segmentation Framework for Computing-Aware Traffic Steering | ||||||||||||||
|
This document proposes an extension to the Computing-Aware Traffic Steering (CATS) framework by introducing a task segmentation module. This extension enables the CATS framework to handle divisible computing requests by breaking them down into smaller computational units, referred to as "Task". The document focuses on two primary task segmentation modes: the distributed mode and the chain- structured Directed Acyclic Graph (DAG) model, providing detailed workflows for each. | |||||||||||||
| draft-li-ccamp-ospf-te-extension-computing-cap-00.txt | ||||||||||||||
| OSPF-TE Extensions for Computing Capability Advertisement | ||||||||||||||
|
This document defines extensions to OSPF Traffic Engineering (OSPF- TE) for advertising computing capability information associated with Artificial Intelligence Data Centers (AIDCs) in optical networks. The extensions enable an ASON or GMPLS-capable optical network to maintain a synchronized view of both network TE resources and selected computing resource attributes, so that service placement and path computation can consider computing resource status. The mechanism uses OSPFv2 Type-10 Opaque LSAs and a set of top-level TLVs and sub-TLVs. The extensions do not define new OSPF packet types and do not modify the OSPF neighbor establishment, database exchange, flooding, or acknowledgement procedures. | |||||||||||||
| draft-li-coap-extensions-a2d-01.txt | ||||||||||||||
| CoAP Extensions for Asynchronous Task Resources | ||||||||||||||
|
Many CoAP deployments need to start operations that cannot be completed within one request/response exchange. Existing deployments commonly model these operations with application-specific resources, payload formats, and polling or notification conventions. This makes clients, gateways, and proxies unable to interoperate across implementations that expose otherwise similar long-running operations. This document defines a CoAP task-resource pattern for asynchronous operations. It specifies a small set of CoAP Options and a CBOR status representation that allow a server to create a temporary task resource, allow a client to monitor, update, or cancel that task using existing CoAP methods, and allow task-state and task-progress observations to reuse the Conditional Query Parameters defined for CoAP Observe [I-D.ietf-core-conditional-attributes]. Autonomous control agents are one motivating use case, but the mechanisms are intended to be generally usable for constrained applications that need interoperable task orchestration. | |||||||||||||
| draft-li-coap-task-resources-01.txt | ||||||||||||||
| CoAP Extensions for Asynchronous Task Resources | ||||||||||||||
|
Many operations on constrained devices cannot complete within a single CoAP request and response exchange. Examples include firmware installation, diagnostic procedures, commissioning, calibration, and physical actuation. This document defines a common lifecycle model for representing such operations as addressable CoAP Task Resources. It specifies task creation, state monitoring, discovery, cancellation, terminal-state retention, and eventual removal. It also defines a four-part request payload model, identified by the existing CoAP Content-Format Option, for carrying resource operations together with task execution controls. No new CoAP Option is defined. | |||||||||||||
| draft-li-dmsc-inf-architecture-07.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-dmsc-macp-06.txt | ||||||||||||||
| Multi-agent Collaboration Protocol Suites Architecture | ||||||||||||||
|
This document defines a protocol suite and architectural framework for secure and scalable multi-agent collaboration. The proposed Multi-Agent Collaboration Protocol (MACP) enables trusted agent onboarding, capability-based query, distributed capability synchronization, and secure interaction among agents and external resources. The architecture introduces key entities such as the Agent Management Center (AMC), Agent Gateway (AGW), Agents, and External Resource Services (ERS), along with a set of protocols that collectively support dynamic, capability-driven collaboration across administrative domains. | |||||||||||||
| draft-li-dnsop-ecs-aggregation-fix-02.txt | ||||||||||||||
| Strengthening DNS Query Aggregation against ECS-based Attacks | ||||||||||||||
|
The DNS query aggregation mechanism is a critical defense against DNS cache poisoning attacks that exploit the "Birthday Paradox". However, recent research has revealed that flawed implementations of the EDNS Client Subnet (ECS) option, as specified in RFC 7871, can be exploited to bypass this defense. This allows attackers to force a resolver to issue multiple simultaneous queries for the same domain name by crafting queries with different ECS options. This vulnerability revives the classic DNS Birthday Attack, posing a significant threat to DNS resolvers and the clients they serve. Section 11.2 of RFC 7871 notes the general risk of Birthday Attacks and suggests marking whether responding nameservers send ECS options, but it does not define a concrete mechanism. This document turns that observation into a specified processing model for the ECS option in DNS resolvers. A resolver tracks, per zone, whether the authoritative servers use ECS: a "no-ECS-support" state forces query aggregation for zones that do not use ECS, and an "ECS-support" state lets a resolver treat an unexpected response without an ECS option (or one with a zero scope) as suspect for zones that do, such as content delivery networks. The document also describes how a resolver bounds the residual risk with a limit on simultaneous outstanding queries. It is offered as input that the working group could fold into a future revision of RFC 7871. | |||||||||||||
| draft-li-hpwan-transmission-optimization-00.txt | ||||||||||||||
| Coordinated Packet Loss Recovery and Congestion Control for High-Throughput WAN Transmission | ||||||||||||||
|
This document defines a coordinated mechanism between packet loss recovery (forward error correction) and congestion control for high- throughput WAN transmission. In high bandwidth-delay product (BDP) networks, loss recovery operations introduce additional processing delay at the receiver, which distorts the congestion controller's perception of network conditions. This mechanism addresses the problem by dynamically adjusting the ACK Delay field in acknowledgment packets to reflect loss recovery processing overhead, enabling the congestion control algorithm to accurately distinguish true network delay from recovery processing delay. The mechanism is applicable to QUIC, TCP, and RDMA transport protocols, and supports host-side, network-side, and coordinated deployment modes. | |||||||||||||
| draft-li-idr-bgp-failure-propagation-convergence-02.txt | ||||||||||||||
| BGP Failure Propagation (BGP-FP) for Enhancing Control-Plane Convergence | ||||||||||||||
|
This document specifies BGP Failure Propagation (BGP-FP), an infrastructure and protocol that improves inter-domain routing convergence by accelerating the removal of stale (invalid) routes. BGP-FP uses (1) an Agent deployed per Autonomous System (AS) to detect inter-AS reachability changes and to configure local routers, (2) a logically centralized Repository to store and selectively forward AS reachability state, and (3) BGP Large Communities as a "route freshness" marker. Agents validate and apply Repository updates to filter routes that traverse AS pairs whose reachability has been lost or that violate the originating AS's forwarding intent, reducing route-flap propagation in the control plane. This document clarifies that "AS reachability" refers to the reachability between two ASes, not to the state of individual physical or logical links within an AS. If multiple links exist between two ASes, the failure of a single link that does not break overall AS-to-AS reachability does not trigger the BGP-FP mechanism. A new Repository deployment model is introduced, suggesting that the Repository be operated by a newly established organization composed of Tier-1 ASes and Regional Internet Registries (RIRs), using a distributed deployment with Byzantine fault-tolerant consensus and rotating leadership. | |||||||||||||
| draft-li-idr-bgp-nrp-01.txt | ||||||||||||||
| BGP Extensions for Network Resource Partition | ||||||||||||||
|
Existing approaches bind a Segment Routing (SR) Policy to a Network Resource Partition (NRP) on a one-to-one basis, which lacks flexibility and introduces significant operational overhead as the number of NRPs scales, especially when multiple NRPs share the same SR Policy path. This document defines BGP extensions to advertise NRP Identifier (NRP ID) information within BGP Update messages between headend and endpoint nodes. It decouples SR Policies from NRPs, allowing multiple NRPs to share a common SR Policy path and avoiding linear growth of SR Policies. The proposed design reduces operational complexity and also applies to SR Best Effort (SR BE) scenarios. | |||||||||||||
| draft-li-idr-bgp-sr-policy-bfd-extension-02.txt | ||||||||||||||
| BGP SR Policy Extensions for BFD Configuration | ||||||||||||||
|
Segment Routing (SR) Policies require fast failure detection for Candidate Paths (CPs) to enable rapid rerouting and high availability. Currently, the provisioning of SR Policies and the configuration of associated Bidirectional Forwarding Detection (BFD) or Seamless BFD (S-BFD) sessions are performed independently. This often necessitates separate mechanisms (e.g., manual configuration, NETCONF, or additional signaling) to associate BFD/S-BFD sessions with the SR Policies, resulting in complex and error-prone operations. This document defines extensions to BGP SR Policy for the simultaneous provisioning of SR Policy CPs and their S-BFD configuration parameters during policy advertisement. The extensions include optional sub-TLVs within the Tunnel Encapsulation Attribute to carry S-BFD configuration parameters (e.g., discriminators, intervals, multipliers). These extensions simplify deployment in distributed or controller- based environments, reduce configuration overhead, and enhance operational efficiency for SR-based traffic engineering. | |||||||||||||
| draft-li-idr-bgp-sr-policy-state-report-01.txt | ||||||||||||||
| BGP SR Policy Extensions for State Report | ||||||||||||||
|
This document extends BGP SR Policy, the same protocol used to configure SR Policies, to report operational state information of SR Policies, Candidate Paths, and Segment Lists. Optional State sub-TLVs, carried within the BGP Tunnel Encapsulation attribute, are introduced in this document to report the operational states (e.g., Down, Inactive, or Invalid) along with their associated reasons of the SR Policies from network elements to controller. These extensions are restricted to operational state reporting and do not alter SR Policy computation, path selection procedures, or the operations of the base BGP protocol. | |||||||||||||
| draft-li-idr-bgpls-sr-policy-composite-path-10.txt | ||||||||||||||
| Signaling Composite Candidate Path of SR Policy using BGP-LS | ||||||||||||||
|
SR Policy Architecture [RFC9256] defines the concept of a Composite Candidate Path. A regular SR Policy Candidate Path outputs traffic to a set of Segment Lists, while an SR Policy Composite Candidate Path outputs traffic recursively to a set of SR Policies on the same headend. This document specifies the extensions to BGP Link State (BGP-LS) to carry composite candidate path information in the advertisement of an SR policy. | |||||||||||||
| draft-li-idr-flowspec-redirect-direct-ip-00.txt | ||||||||||||||
| BGP Flow Specification Redirect to Directly Connected IP Address | ||||||||||||||
|
A bit, D bit, is defined in Flow-spec Redirect-to-IPv4 Extended Community and Flow-spec Redirect-to-IPv6 Extended Community. This bit is used by BGP Flow Specification to indicate that the associated Flow Specification policy be set to an invalid state when the directly connected link associated with the redirect target address becomes unavailable. | |||||||||||||
| draft-li-idr-flowspec-sr-policy-04.txt | ||||||||||||||
| BGP Flowspec Redirects to SR Policy | ||||||||||||||
|
Extensions to BGP Flowspec Version 1 (FSv1) support steering traffic into a Segment Routing (SR) Policy. This document extends BGP Flowspec Version 2 (FSv2) to provide the same capability of steering traffic into a SR Policy. Using the Community Container attribute, this document defines two new standard actions for FSv2: the Redirect to SR Policy Action and the SRv6 SID Action. The former instructs headend node to direct traffic to a designated SR Policy, while the latter supports simultaneously encapsulating an additional SRv6 SID as required during redirection. The Redirect to SR Policy Action may be used either independently or in conjunction with the SRv6 SID Action, depending on the specific application scenario. In addition, the SRv6 SID Action can be combined with other actions supported by FSv2, such as the Redirect to IPv6 Action. | |||||||||||||
| draft-li-idr-ipv6-bgp-identifier-01.txt | ||||||||||||||
| BGP Capability for IPv6 BGP Identifier | ||||||||||||||
|
This document defines a new BGP Capability that enables an IPv6 BGP Speaker to use its global unicast IPv6 address as its BGP Identifier. This mechanism simplifies configuration in IPv6-only networks by leveraging the inherent uniqueness of IPv6 addresses, while maintaining full backward compatibility with existing BGP implementations. | |||||||||||||
| draft-li-idr-savnet-intra-domain-bgp-01.txt | ||||||||||||||
| Source Address Validation at Intra-domain Network Boundary Using BGP | ||||||||||||||
|
This document proposes a solution for Source Address Validation (SAV) at the intra-domain network boundary using BGP. Routers at the boundary automatically generate accurate SAV rules by using routing information and SAV-specific information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network. This document also introduces BGP extensions for communicating SAV- specific information among routers at the boundary. | |||||||||||||
| draft-li-idr-sr-policy-metric-04.txt | ||||||||||||||
| BGP SR Policy Extensions for Performance-Aware Path Selection | ||||||||||||||
|
To enable the headend node to do performance-aware path selection, this document proposes an extension to the BGP SR Policy protocol by defining a new optional Metric Sub-TLV within the BGP Tunnel Encapsulation Attribute. The introduced Metric Sub-TLV encodes performance parameters (such as latency, bandwidth, reliability, etc.) for SR Policy paths. This specification also updates the BGP route selection procedures in RFC4271, modifying the Breaking Ties (Phase 2) logic to prioritize the metrics for SR Policy paths. Key contributions include: * Introduce Metric Sub-TLV in BGP SR Policy * Update the tie-breaking procedure for BGP route selection | |||||||||||||
| draft-li-individual-inip-01.txt | ||||||||||||||
| In-Network Inference Protocol | ||||||||||||||
|
This document specifies the In-Network Inference Protocol (INIP), a lightweight protocol designed specifically for implementing high- speed in-network inference in data center internal networks. INIP utilizes data plane devices (such as switches, DPUs, and SmartNICs) to perform lightweight inference tasks while ensuring that core network forwarding functions are not affected. The protocol operates based on the IPv4 protocol and adopts a fixed, lightweight packet format. INIP adopts a two-tier architecture of "centralized control plane adaptation and scheduling, and minimal data plane execution". The control plane stores all inference models, deploys model rules to data plane devices using a CDN-like scheduling method, and assumes the responsibility of degraded fallback inference; the data plane performs packet parsing and match action table-based inference. This document details INIP's core logic, packet format, data plane device constraints, model expression specifications, control plane responsibilities, CDN-like scheduling mechanism, dynamic model popularity replacement, and overall execution process. | |||||||||||||
| draft-li-ippm-ioam-common-encap-procedures-00.txt | ||||||||||||||
| Common Procedures for Encapsulating IOAM Data Fields in Transport Protocols | ||||||||||||||
|
In Situ Operations, Administration, and Maintenance (IOAM) enables on-path telemetry by inserting operational metadata into data packets as they traverse a network path. IOAM Data-Fields, as defined in RFC 9197, are designed to be independent of the encapsulating transport protocol. However, the procedures for inserting, updating, and removing IOAM Data-Fields are currently specified separately for each transport protocol (e.g., IPv6, NSH, GRE, Geneve), leading to redundant specification effort and inconsistent implementation behavior. This document defines a set of common encapsulation procedures for IOAM Data-Fields that are applicable across multiple transport protocols. The insertion point for IOAM Data-Fields is expressed as a configurable byte offset from a well-defined reference position in the encapsulating header, enabling a uniform insertion procedure that does not require protocol-specific parsing logic. The document specifies the general steps for identifying the insertion point, validating transport-layer constraints, performing the insertion of IOAM Option-Types, and updating affected header fields to maintain protocol compliance. | |||||||||||||
| draft-li-ippm-multipoint-telemetry-00.txt | ||||||||||||||
| Multi-Point Telemetry Correlation for Network Measurement | ||||||||||||||
|
Network measurement and telemetry systems that collect data at multiple points along a path or across multiple targets require a means to correlate the collected data. When each collection point independently selects which packets to observe, the resulting data sets may not overlap, preventing per-packet correlation of measurements across points. This document specifies how source-directed selection -- where a single node determines which packets are subject to measurement and signals this to other nodes -- achieves correlated data collection across multiple points. Two applications are described: IOAM Direct Export for in-band network telemetry, and PTP Sequence ID range assignment for multi-slave time synchronization. | |||||||||||||
| draft-li-ippm-stamp-bfd-tlv-00.txt | ||||||||||||||
| A STAMP Extension for Carrying Bidirectional Forwarding Detection Control Messages | ||||||||||||||
|
Network operators frequently run both Bidirectional Forwarding Detection (BFD) for rapid fault detection and an active measurement protocol such as STAMP for delay and loss measurement between the same pair of nodes, resulting in two parallel packet streams with overlapping timing requirements. This document defines an optional STAMP TLV that carries a BFD Control message within STAMP test packets, using the extension format of RFC 8972. A single test packet stream can then drive both the BFD state machine and STAMP performance measurement. The BFD protocol itself is unchanged. | |||||||||||||
| draft-li-ippm-stamp-ecmp-pm-00.txt | ||||||||||||||
| Procedures for ECMP-Aware Performance Measurement with STAMP | ||||||||||||||
|
This document specifies procedures for configuring Simple Two-Way Active Measurement Protocol (STAMP) sessions so that test packets traverse the same ECMP or LAG forwarding path as a specified production flow. In networks that use hash-based load distribution, the forwarding path depends on a hash over packet header fields. Standard STAMP test packets carry session-specific addresses and ports that differ from production traffic, often selecting a different forwarding path and yielding measurements that do not represent the actual service quality of the production flow. The procedures in this document specify how the Session-Sender populates test packet headers with values matching a designated production flow. The Session-Reflector identifies test packets by validating the STAMP payload structure. No changes to the STAMP packet formats defined in RFC 8762 are required. | |||||||||||||
| draft-li-ipsecme-extensions-for-robust-negotiation-00.txt | ||||||||||||||
| Consideration of Robust Multi-KEM Negotiation within IKEv2 | ||||||||||||||
|
RFC 9370 specifies a framework for multiple additional key exchanges (ADDKE) in the Internet Key Exchange Protocol Version 2 (IKEv2) to support post-quantum cryptography migration. Under this framework, an initiator can propose multiple ADDKE transform types. In deployment scenarios, initiators may send proposals that contain redundant or overlapping lists of Key Encapsulation Mechanism (KEM) algorithms across different ADDKE transform types. This contribution discusses the implications of these proposals and specifies extended procedures for handling proposed transforms, which may improve negotiation robustness and interoperability by allowing the responder to select a valid set of algorithms without altering the security properties defined in RFC 9370. | |||||||||||||
| draft-li-lsr-igp-based-intra-domain-savnet-05.txt | ||||||||||||||
| Source Address Validation at the Intra-domain Network Boundary Using IGP | ||||||||||||||
|
SPA-based SAVNET is a new intra-domain source address validation (SAV) mechanism which requires exchanging and communicating SPA information among routers in an intra-domain network (see [I-D.li-savnet-source-prefix-advertisement]). Routers at the boundary automatically generate accurate SAV rules by using routing information and SPA information. These rules construct a validation boundary which checks the validity of the source address of any data packets flowing into the intra-domain network. This document describes a method to implement SPA-based SAVNET by using OSPF and IS-IS. | |||||||||||||
| draft-li-lsr-igp-reverse-prefix-metric-05.txt | ||||||||||||||
| IGP Reverse Prefix Metric | ||||||||||||||
|
This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF (Reverse Path Forwarding) check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios. | |||||||||||||
| draft-li-lsvr-bgp-spf-srv6-06.txt | ||||||||||||||
| Applying BGP-LS Segment Routing over IPv6(SRv6) Extensions to BGP-LS-SPF | ||||||||||||||
|
For network scenarios such as Massively Scaled Data Centers (MSDCs), BGP is extended for Link-State (LS) distribution and the Shortest Path First (SPF) algorithm based calculation. BGP Link State Shortest Path First (BGP-LS-SPF) Routing leverages the mechanisms of both BGP protocol and BGP-LS protocol extensions. Segment Routing over IPv6 (SRv6) provides a source routing mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SRv6 domain. In some networks, it may be useful to enable SRv6 based source routing mechanism together with BGP-LS-SPF. This document proposes to introduce the BGP Link-State (BGP-LS) extensions for SRv6 to the BGP-LS-SPF SAFI to enable SRv6 capabilities in BGP-LS-SPF. The usages and formats of these extensions are also provided in this document. | |||||||||||||
| draft-li-moe-ep-communication-optimization-00.txt | ||||||||||||||
| Communication Optimization for MoE Expert Parallelism in Distributed Training | ||||||||||||||
|
This document describes a communication optimization mechanism for Mixture of Experts (MoE) Expert Parallelism (EP) in distributed training environments. It defines two core mechanisms: (1) an adaptive communication mode selection that dynamically chooses between Data-Centric and Expert-Centric All-to-All communication patterns based on a comparison of expert parameter size versus token data size, minimizing cross-node communication volume; (2) a priority-based co-scheduling strategy for All-to-All and AllReduce collective communications, combined with chunked transmission and in- network aggregation acceleration, to eliminate bandwidth contention and reduce overall training latency. | |||||||||||||
| draft-li-nmrg-dtn-data-generation-optimization-05.txt | ||||||||||||||
| Data Generation and Optimization for Network Digital Twin | ||||||||||||||
|
Network Digital Twin (NDT) can be used as a secure and cost-effective environment for network operators to evaluate network in various what-if scenarios. Recently, Artificial Intelligence (AI) models, especially neural networks, have been applied for NDT modeling. The quality of deep learning models mainly depends on two aspects: model architecture and data. This memo focuses on how to improve the model quality from the data perspective. | |||||||||||||
| draft-li-oauth-delegated-authorization-03.txt | ||||||||||||||
| OAuth 2.0 Delegated Authorization | ||||||||||||||
|
This specification defines Delegated Authorization Tokens, key-bound tokens that enable an OAuth client to delegate a constrained subset of its authorization to another client without contacting the authorization server for each delegation. An authorization server issues the root token and binds it to a client key. That client can use the bound key either to prove possession when accessing a protected resource or to sign a further token bound to a delegate client's key. Resource servers validate the ordered token chain, the restrictions imposed at every delegation step, and a DPoP proof signed by the key bound to the leaf token. | |||||||||||||
| draft-li-oauth-policy-based-anonymous-tokens-00.txt | ||||||||||||||
| OAuth 2.0 Policy-Based Anonymous Access Tokens | ||||||||||||||
|
This document specifies an OAuth 2.0 access-token type that allows a client, after one authorization-server issuance, to derive a policy- bounded set of unlinkable, single-use access tokens locally. Each derived token is bound to one canonical tag, an intended resource server, approved authorization details, a policy epoch, and a validity interval. Resource servers validate the token offline and enforce both policy membership and replay prevention. The protocol defines authorization request semantics, token-endpoint issuance, canonical policy and metadata objects, token derivation and HTTP presentation, resource-server validation, capability discovery, error handling, and IANA registrations. Version 1 requires public verification and the counter-window policy profile. It supports an optional private metadata bit, while private-verification ciphersuites remain optional. Concrete cryptographic algorithms are supplied by separately registered PBAT ciphersuites. The initial mandatory-to-implement ciphersuite is the publicly-verifiable equivalence-class-signature construction over BLS12-381 specified by the companion PBAT ciphersuite document. This specification does not replace OAuth grants, resource-owner consent, client authentication, or audience restriction. — middle | |||||||||||||
| draft-li-opsawg-agent-accel-framework-00.txt | ||||||||||||||
| A Framework for Agent-Aware Network Acceleration Services in Home Broadband Access | ||||||||||||||
|
This document describes a framework for providing AI agents with differentiated network acceleration services in home broadband access environments. The framework introduces a Network Acceleration SKILL, provided by the network operator, through which agents subscribe to and request acceleration services directly from the Broadband Remote Access Server (Broadband Remote Access Server). The Broadband Remote Access Server, augmented with a control plane agent, processes acceleration requests, coordinates authorization with the Authentication, Authorization, and Accounting server, and applies per-agent Quality of Service policies on its data plane. A key motivation is to evolve the currently rigid home broadband service model — where plans are fixed on monthly or yearly cycles with static rate limiting — toward a dynamic subscription model that supports on-demand purchase and management of acceleration resources such as time duration or traffic volume. A fundamental design constraint is that existing broadband access procedures, including Customer Premises Equipment authentication, IPv6 prefix delegation, and subscriber billing, remain unmodified. | |||||||||||||
| draft-li-opsawg-attack-sample-metadata-00.txt | ||||||||||||||
| A YANG Data Model for Network Attack Sample Metadata | ||||||||||||||
|
Operational analysis, troubleshooting, validation of network defense functions, and exchange of collected traffic evidence rely on attack samples that are consistently described and can be processed across operators, vendors, and research tools. Today, such samples are often represented by proprietary labels, partial traffic captures, flow exports, log bundles, or local database schemas, which makes comparison, reproduction, and automated processing difficult. This document defines a YANG data model for network attack sample metadata. The model describes the sample identity, collection context, attack characteristics, data-content summary, anonymization status, and reproducibility information associated with packet, flow, session, log, or payload data. The model is intended to complement IPFIX, IODEF, PCAP/PCAPng-based operational data, and collected data manifests by defining metadata for the attack sample itself. | |||||||||||||
| draft-li-opsawg-oam-interval-mod-00.txt | ||||||||||||||
| Coordinated CCM Interval Modification Procedures | ||||||||||||||
|
In IEEE 802.1ag Connectivity Fault Management (CFM), the Continuity Check Message (CCM) interval is a static parameter that must match on both peer Maintenance End Points (MEPs). Changing the interval at runtime on one MEP without simultaneously updating the peer causes a Loss of Continuity (LOC) defect and may trigger protection switching. Because the CFM PDU formats and OpCode space are governed by IEEE 802.1, this document does not modify the protocol; instead, it specifies a coordinated management-plane procedure that transitions both MEPs to a new CCM interval without raising spurious defects or triggering protection switching, together with failure handling and rollback behavior. The procedure can be operated through existing configuration models such as the connection-oriented OAM YANG model. | |||||||||||||
| draft-li-opsawg-stateful-copp-00.txt | ||||||||||||||
| Stateful Control Plane Policing | ||||||||||||||
|
Control Plane Policing (CoPP), as described in RFC 6192, classifies control-plane-destined traffic using static packet header fields. This static classification cannot distinguish legitimate protocol traffic from attack traffic that matches the same header-based rules. This document specifies Stateful CoPP, an operational practice in which the router's runtime protocol state -- including configured peer identities, session state, and expected ingress interfaces -- is incorporated into CoPP classification. Stateful CoPP allows confirmed legitimate traffic to receive preferential access to control plane CPU resources under attack conditions. | |||||||||||||
| draft-li-pearg-ciphertext-inference-tool-mcp-00.txt | ||||||||||||||
| Ciphertext-Based AI Inference Tool Design for the Model Context Protocol (MCP) | ||||||||||||||
|
The Model Context Protocol (MCP) enables AI-powered tools to interact with autonomous agents and Large Language Models (LLMs), but currently processes user inputs and inference results in plaintext. This could introduce some privacy risks and violates the principle of least privilege when processing user data. This contribution specifies a ciphertext-based AI inference extension for MCP. The design leverages Homomorphic Encryption (HE) to allow an MCP server or remote tool to perform inference directly on encrypted data without accessing the plaintext. The server receives encrypted payloads, computes over ciphertexts using an evaluation key, and returns an encrypted result that only the MCP client can decrypt. To ensure interoperability across various network environments, this document defines a JSON-RPC message format independent of the underlying transport layer (supporting both local stdio and remote Server-Sent Events). The format extends the existing MCP 'tools/ call' method with fields for encrypted payloads, algorithm identifiers, and key references. Additionally, this document discusses security considerations, key management, and implementation trade-offs. | |||||||||||||
| draft-li-quic-qos-optimization-00.txt | ||||||||||||||
| Fine-Grained QoS Optimization for QUIC Based on Connection ID Priority Mapping | ||||||||||||||
|
This document defines a fine-grained, dynamically adaptive QoS mechanism for QUIC transport. The mechanism encodes a priority mapping table index in the QUIC Destination Connection ID (DCID), enabling host NICs or user gateways to translate QUIC-layer service priority information into network-layer QoS mechanisms (DSCP/ToS per RFC 2474) and traffic engineering policies (SRv6 TE, MPLS TE, etc.) for end-to-end QoS enforcement. Stream IDs carry endpoint priority information for local scheduling. The mechanism supports host-side, network-side, and coordinated deployment modes with no intrusion into the host protocol stack. | |||||||||||||
| draft-li-recursive-peer-model-00.txt | ||||||||||||||
| A Recursive Peer Model for Network Protocols | ||||||||||||||
|
The seven-layer OSI model has served as a foundational framework for network protocol design and education for four decades. However, modern networking practices—including VPNs, NAT, tunneling protocols, and overlay networks—have revealed structural flaws in the OSI model that require ad hoc exceptions to explain. This document presents a Recursive Peer Model (RPM) as an alternative architectural framework. The model is based on a single observation: every intermediate protocol layer contains its own four-layer structure—Bearer Layer, Data Link Layer, Network Layer, and Transport Layer—and this structure recurs at every layer of the protocol stack. The Data Layer and Medium Layer serve as the two recursive boundaries, terminating at "pure data" and "physical medium" respectively. The Recursive Peer Model eliminates the need for "exception" clauses (such as the "tunnel exception" for VPNs), provides coherent explanations for protocols that OSI cannot categorize cleanly (such as ARP and ICMP), and offers a unified framework for describing both existing and future protocols. | |||||||||||||
| draft-li-rtgwg-enhanced-ti-lfa-14.txt | ||||||||||||||
| Enhanced Topology Independent Loop-free Alternate Fast Re-route | ||||||||||||||
|
Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims at providing protection of node and adjacency segments within the Segment Routing (SR) framework. A key aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair. However, the TI-LFA FRR path may skip the node even if it is specified in the SID list to be traveled. This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass indicator for segments to ensure that the FRR route will not bypass the specific node, such as firewall. Also, this document defines No- bypass flag and No-FRR flag in SRH to indicate not to bypass nodes and not to perform FRR on all the nodes along the SRv6 path, respectively. | |||||||||||||
| draft-li-savnet-sav-yang-08.txt | ||||||||||||||
| YANG Data Model for Intra-domain and Inter-domain Source Address Validation (SAVNET) | ||||||||||||||
|
This document describes a YANG data model for Intra-domain and Inter-domain Source Address Validation (SAVNET). The model serves as a base framework for configuring and managing an SAV subsystem, including SAV rule and SAV Tables, and expected to be augmented by other SAV technology models accordingly. Additionally, this document also specifies the model for the SAV Static application. | |||||||||||||
| draft-li-sidrops-pqrpki-00.txt | ||||||||||||||
| Post-Quantum Authentication for the Resource Public Key Infrastructure | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) authenticates Internet number resource holdings and routing authorizations with classical (RSA) signatures. Because every relying party repeatedly fetches and validates the complete global repository, replacing each per-object signature with a larger post-quantum signature would multiply repository size and validation cost. This document specifies pqRPKI, an additive post-quantum authentication layer for the RPKI. Instead of re-signing every object, each Certification Authority (CA) authenticates its complete published state with a single post-quantum signature over a Merkle Tree Ladder whose leaf order and leaf commitments are taken directly from the CA's existing Manifest. A new signed object, the pqRPKI Ladder Object (PQLO), carries the ladder root, the Manifest binding, an optional aggregate binding the CA's children, and -- for a Trust Anchor or a CA holding its own post-quantum key -- the post-quantum signature; a CA operated by its parent is authenticated through the parent's aggregate instead. Existing RPKI objects are unchanged and legacy relying parties are unaffected by the PQLO, which no Manifest lists, while upgraded relying parties validate the same repository contents with post-quantum authentication. This document updates RFC 9286 to permit index-preserving placeholder Manifest entries and the pqRPKI file-name extension. | |||||||||||||
| draft-li-sidrops-stealthy-hijacking-02.txt | ||||||||||||||
| Risk of Stealthy BGP Hijacking under Incomplete Adoption of Route Origin Validation (ROV) | ||||||||||||||
|
This document describes how incomplete adoption of Route Origin Validation (ROV) makes certain forms of BGP hijacking less visible on the control plane while still capable of diverting traffic. We explain the underlying mechanism, define the form of the threat, analyze an real-world incident that exemplifies the issue, and discuss potential countermeasures to mitigate its impact. | |||||||||||||
| draft-li-spring-srh-tlv-processing-programming-10.txt | ||||||||||||||
| SRH TLV Processing Programming | ||||||||||||||
|
This document proposes a mechanism to program the processing rules of Segment Routig Header (SRH) optional TLVs explicitly on the ingress node. In this mechanism, there is no need to configure local configuration at the node to support SRH TLV processing. A network operator can program to process specific TLVs on specific segment endpoint nodes for specific packets on the ingress node, which is more efficient for SRH TLV processing. | |||||||||||||
| draft-li-tiptop-address-space-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-tsvwg-inference-transport-00.txt | ||||||||||||||
| Transport Considerations for Large-Scale Distributed Inference Networks | ||||||||||||||
|
Large-scale distributed inference systems generate traffic patterns that differ from both traditional data center workloads and distributed training workloads. Disaggregated prefill/decode serving transfers key-value cache state between server pools, and expert- parallel architectures generate all-to-all traffic among expert groups. These flows are typically carried over a small number of RDMA connections, producing low-entropy traffic that is prone to uneven link utilization under Equal-Cost Multipath (ECMP) forwarding. This document specifies transport considerations for such networks, covering path load awareness, path steering through ECMP entropy variation, ordering tolerance at the receiver, and differentiated reliability for data with different loss sensitivity. The discussion builds on existing IETF building blocks; this document does not define new protocol elements. | |||||||||||||
| draft-li-uboe-00.txt | ||||||||||||||
| UnifiedBus over Ethernet (UBoE) | ||||||||||||||
|
This document specifies the UnifiedBus over Ethernet (UBoE) protocol, which enables seamless interconnection between native UnifiedBus (UB) domains and standard Ethernet/IP network for AI and HPC high- performance scenarios. It defines the UBoE packet encapsulation based on IPv4/IPv6 and UDP over Ethernet, including the invariant CRC (ICRC) integrity protection for end-to-end packet verification. This document further specifies the cross-domain packet conversion and header adaptation behaviors at UB2E switches, including bidirectional mapping rules for UB-specific network layer and IP network layer. | |||||||||||||
| draft-li-zt-consideration-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-li-ztcpp-network-infra-consideration-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-liang-agent-health-state-00.txt | ||||||||||||||
| Agent Health State An Observability Layer Between Agent Discovery and Governance | ||||||||||||||
|
AI agents deployed on the Web require three capabilities to interoperate safely: discovering each other, assessing each other's current operational state, and governing each other's behavior over time. Discovery is addressed by A2A's /.well-known/agent.json endpoint. Behavior governance is addressed by the SOOS Progressive Trust model and its Trust Decay specification. Between these two layers lies a gap: no existing standard provides a lightweight, machine-readable signal for whether an agent is currently operational, responsive, and calibrated -- the operational health state that any consumer needs before deciding whether to interact with an agent, and that governance frameworks need as a freshness input for their calibration anchors. This document defines the Agent Health State specification: a /.well-known/agent-health endpoint and a structured health state response format that exposes an agent's operational status, response calibration metrics, and decay indicators. The specification is designed to be independently deployable (requiring no governance infrastructure), composable with A2A discovery, and consumable by SOOS/PT as calibration anchor freshness input. This document positions agent-health as the missing observability layer between agent discovery (A2A /.well-known/agent.json) and agent behavior governance (SOOS/PT Trust Decay Model), serving both as operational state for interaction decisions and as calibration anchor freshness input to verification gates. | |||||||||||||
| draft-liang-tcp-provenance-option-02.txt | ||||||||||||||
| TCP Provenance Identifier Option | ||||||||||||||
|
This document describes a TCP option that carries a Provenance Identifier (ProvID) to enable correlation of TCP connections when transport-layer identifiers change along the path. | |||||||||||||
| draft-liao-ace-est-c509-03.txt | ||||||||||||||
| EST for C509 Certificates | ||||||||||||||
|
This document defines Enrollment over Secure Transport (EST) protocol operations over HTTPS and secure CoAP for use with C509 certificates. The operations specified in this document support CA certificate distribution, C509 certificate enrollment, C509 certificate re- enrollment, and server-side key generation using C509 certificates. This document also defines operations for Certificate Revocation List (CRL) distribution. | |||||||||||||
| draft-liao-cose-c509-additions-00.txt | ||||||||||||||
| Additions to C509 Structures | ||||||||||||||
|
This document defines additions to CBOR Encoded X.509 Certificates (C509). This document defines a new C509SubjectPublicKeyInfo type, a CBOR representation of the X.509 SubjectDirectoryAttributes extension, and a mechanism that allows organizations assigned a Private Enterprise Number (PEN) to define organization-specific integer identifiers without registering each identifier in the C509 RDN attribute type, CR attribute type, extension ID, certificate policy, or extended key usage registries. This document also defines textual encoding labels for C509 objects using the textual encoding conventions specified in RFC 7468. | |||||||||||||
| draft-liao-cose-c509-algorithms-00.txt | ||||||||||||||
| Additional Algorithms for C509 Certificates | ||||||||||||||
|
This document registers additional algorithms in the IANA registries defined by [I-D.ietf-cose-cbor-encoded-cert]. It extends the base C509 certificate specification with post-quantum cryptography (PQC) signature and key-encapsulation algorithms including ML-DSA, ML-KEM, stateful hash-based algorithms (HSS/LMS, XMSS, XMSS^MT), and composite algorithms. | |||||||||||||
| draft-liao-cose-c509-revocation-00.txt | ||||||||||||||
| CBOR Encoded Certificate Revocation Management | ||||||||||||||
|
This document specifies CBOR-encoded PKI structures for use with C509 certificates (draft-ietf-cose-cbor-encoded-cert), X.509 certificates (RFC 5280), and future certificate types. It defines C509 CRL and C509 OCSP, compact CBOR encodings of X.509 Certificate Revocation Lists (RFC 5280) and OCSP messages (RFC 6960), respectively. The structures defined in this document are certificate-type agnostic and can be used with C509 certificates, X.509 certificates, or future certificate types without modification. C509 OCSP improves on RFC 6960 by signing a wider set of fields to prevent algorithm- substitution and certificate-chain substitution attacks, replacing plaintext serial numbers with hashes to preserve requestor privacy, replacing the two-hash issuer identity with a single certificate hash, and identifying all participants (requestor, responder, issuer) by a uniform certificate hash rather than type-specific fields. C509 CRL and C509 OCSP are not wire-format-compatible with their DER- encoded X.509 counterparts and cannot be converted to or from them without semantic interpretation. | |||||||||||||
| draft-liao-lamps-est-lightweight-operations-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lihawi-ancp-protocol-access-extension-14.txt | ||||||||||||||
| Access Extensions for ANCP | ||||||||||||||
|
This document specifies extensions to the Access Node Control Protocol (ANCP), defined in RFC6320, to support Passive Optical Networks (PON) and evolving DSL technologies such as G.fast. To accommodate these diverse access environments, this document updates RFC6320 by modernizing existing terminologies, adapting message flows, and defining new Type-Length-Value (TLV) attributes. | |||||||||||||
| draft-limarsjenwar-tiptop-address-space-00.txt | ||||||||||||||
| IPv6 Address Space for Space | ||||||||||||||
|
Without a structured address allocation plan, early space missions risk creating an unaggregated patchwork of prefixes, repeating the historical operational scaling issues seen in terrestrial networks. This document requests that the IANA allocate address space specifically for use in space environments and manages suballocations from that block for and within celestial bodies, as needed. The Number Resource Organization (NRO) will determine how to allocate and assign address resources for and within the celestial bodies , with the understanding that topological address aggregation is critical for routing scalability and operational efficiency. | |||||||||||||
| draft-lin-bfd-path-consistency-over-sr-07.txt | ||||||||||||||
| BFD Path Consistency over SR | ||||||||||||||
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy | |||||||||||||
| draft-lin-grow-bmp-cap-notification-01.txt | ||||||||||||||
| Peer Capability Update Notification in BGP Monitoring Protocol (BMP) | ||||||||||||||
|
When BGP Dynamic Capability is supported, dynamic updates of capabilities are allowed over an established BGP session. At present, after the BGP session is established, the monitored router sends a BMP Peer Up Notification message first, containing the initial capabilities. If BGP Dynamic Capability is supported, using BMP Peer Up Notification messages to report subsequent capability changes for a BGP session becomes inappropriate. This document defines a new Peer Capability Update Notification message type in BMP to report peer capability changes. | |||||||||||||
| draft-lin-grow-bmp-peer-interface-02.txt | ||||||||||||||
| Extension for BMP Peer Interface | ||||||||||||||
|
This document proposes extending BMP to allow BMP messages with the per-peer header to carry interface information for the established peer session, especially in order to distinguish parallel link-local and unnumbered BGP peers established based on distinct interfaces. | |||||||||||||
| draft-lin-idr-bgp-ecmp-ebgp-enhancements-01.txt | ||||||||||||||
| BGP Enhancements for ECMP EBGP Scenarios | ||||||||||||||
|
This document proposes extensions to BGP to apply the RFC 5004 route persistence algorithm across parallel EBGP sessions and to suppress unnecessary advertisements between EBGP peers in the same AS. This document updates RFC 5004. | |||||||||||||
| draft-lin-idr-bgpls-te-policy-pm-09.txt | ||||||||||||||
| BGP-LS Advertisement of SR Policy Performance Metric | ||||||||||||||
|
This document describes a way to advertise the performance metrics for Traffic Engineering (TE) Policy using BGP Link State (BGP-LS). | |||||||||||||
| draft-lin-idr-cats-flowspec-ts-05.txt | ||||||||||||||
| BGP Flowspec for Computing-Aware Traffic Steering | ||||||||||||||
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. Computing-Aware Traffic Steering (CATS) is a framework which optimizes traffic steering to a given service instance by taking into account the dynamic nature of both computing and network resources. This document specifies a new BGP Flow Spec Component Type in order to support CATS traffic forwarding. | |||||||||||||
| draft-lin-idr-distribute-service-metric-07.txt | ||||||||||||||
| Distribute Service Metric by BGP | ||||||||||||||
|
When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. | |||||||||||||
| draft-lin-idr-flowspec-quic-00.txt | ||||||||||||||
| BGP Flow Specification for QUIC | ||||||||||||||
|
A BGP Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic. This document defines how to perform Flow Specification traffic diversion based on the characteristics of QUIC packets. | |||||||||||||
| draft-lin-idr-sr-policy-headend-behavior-06.txt | ||||||||||||||
| BGP Extensions of SR Policy for Headend Behavior | ||||||||||||||
|
[RFC8986] defines H. Encaps behavior, H. Encaps.Red behavior, H. Encaps.L2 behavior, and H. Encaps.L2.Red behavior for SR policy. This document defines extensions to Border Gateway Protocol (BGP) to distribute SR policies carrying headend behavior. | |||||||||||||
| draft-lin-opsawg-ipfix-rocev2-01.txt | ||||||||||||||
| Export of RoCEv2 Base Transport Header (BTH) Information Using IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document defines a new set of IP Flow Information Export (IPFIX) Information Elements (IEs) for exporting Base Transport Header (BTH) information for RDMA over Converged Ethernet version 2 (RoCEv2) traffic. These extensions enable network monitoring systems to collect and analyze the characteristics of RDMA traffic widely used in high-performance computing, storage, and artificial intelligence applications. | |||||||||||||
| draft-lin-opsawg-ipfix-sr-policy-01.txt | ||||||||||||||
| Export of Segment Routing Policy Attributes in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document defines new IP Flow Information Export (IPFIX) Information Elements (IEs) to export attributes of Segment Routing (SR) and Segment Routing over IPv6 (SRv6) policies applied to IP flows, which enables correlation between observed traffic flows and the SR/SRv6 policies that carry them. | |||||||||||||
| draft-lin-spring-srv6-aware-context-indicator-08.txt | ||||||||||||||
| SRv6 Context Indicator SIDs for SR-Aware Services | ||||||||||||||
|
A context indicator provides the context on how to process the packet for service nodes. This document describes how to use SRv6 SIDs as context indicator for SR-aware services. The corresponding Endpoint behaviors are defined. | |||||||||||||
| draft-ling-sidrops-rov-tag-profile-02.txt | ||||||||||||||
| A Profile for ROV Deployment Transparency | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for ROV Deployment Transparency (ROV_TAG) objects for use with the Resource Public Key Infrastructure (RPKI). An ROV_TAG is a digitally signed object through which an Autonomous System (AS) that has deployed Route Origin Validation (ROV) can declare its ROV deployment status. When validated, an ROV_TAG's eContent can be used by ASes to identify which ASes have deployed ROV, enabling path selection decisions when hijacked routes are detected; see Section 3. | |||||||||||||
| draft-lingga-nmrg-analytics-interface-dm-01.txt | ||||||||||||||
| A YANG Data Model for Analytics Interface in Interface to Network Security Functions (I2NSF) | ||||||||||||||
|
This document describes an information model and a YANG data model for the Analytics Interface between an Interface to Network Security Functions (I2NSF) Analyzer and a Security Controller in an I2NSF framework. I2NSF Analyzer collects the monitoring data from Network Security Functions (NSF), and analyzes them with Machine Learning (ML) algorithms. This Analytics Interface is used for I2NSF Analyzer to deliver analysis results (e.g., policy reconfiguration and feedback message) to Security Controller for Closed-Loop Security Control in the I2NSF Framework in [I-D.jeong-nmrg-security-management-automation]. The YANG data model described in this document is based on the YANG data models of the I2NSF NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm] and the I2NSF Monitoring Interface [I-D.ietf-i2nsf-nsf-monitoring-data-model]. | |||||||||||||
| draft-linkgenetic-linkid-uri-00.txt | ||||||||||||||
| The LinkID URI Scheme and Resolution Model | ||||||||||||||
|
This document specifies the "linkid" URI scheme and a resolution model for persistent, location-independent identifiers. A LinkID identifies a resource independently of its current network location. Resolution maps the persistent identifier to a current actionable URI using one or more resolvers. The scheme is intended for Web, document, archival, scientific, government, enterprise, and machine- to-machine references where locations may change while reference identity must remain stable. | |||||||||||||
| draft-linkova-6man-ununra-02.txt | ||||||||||||||
| Unicast Unsolicited Router Advertisements for Propagating Network Configuration Updates | ||||||||||||||
|
Multicast transmissions on Wi-Fi links are known to be unreliable, making the propagation of critical network configuration changes via multicast Router Advertisements (RAs) prone to failure or severe delay. Existing approaches to improve reliability, such as sending multiple unsolicited multicast RAs, require fine-tuning timers and packet counts that may not fit all deployment scenarios. This document updates RFC 4861 by introducing an optimization: when a router detects a configuration change that must be propagated to hosts, it sends unicast Router Advertisements to every client recently observed on that interface. | |||||||||||||
| draft-linuxgemini-otpauth-uri-03.txt | ||||||||||||||
| One-Time Password (OTP) Credential Provisioning URI Format: otpauth | ||||||||||||||
|
This document specify the One-Time Password (OTP) Credential Provisioning otpauth URI format, utilized by TOTP (Time-Based One- Time Password Algorithm) and HOTP (An HMAC-Based One-Time Password Algorithm) based authenticators. | |||||||||||||
| draft-lior-radius-prepaid-extensions-22.txt | ||||||||||||||
| Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS) | ||||||||||||||
|
This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. | |||||||||||||
| draft-litzki-sovp-03.txt | ||||||||||||||
| Sovereign Validation Protocol (SOVP) | ||||||||||||||
|
This document specifies the Sovereign Validation Protocol (SOVP), a protocol for cryptographic verification of publisher-provided identity metadata bound to DNS-anchored Ed25519 public keys. SOVP enables consuming agents, gateways, and federated infrastructure components to verify the origin and integrity of machine-readable declarations published by a domain prior to ingestion, allowing deployments to reject unauthenticated data before application-level processing occurs. SOVP is designed to operate as a verification layer beneath existing trust frameworks, federation architectures, and governance systems. It does not replace these systems. It provides the cryptographic infrastructure evidence upon which higher-layer trust decisions may be grounded. SOVP defines a deterministic verification procedure based on RFC 8785 JSON Canonicalization Scheme (JCS), Ed25519 signatures, DNS-based key publication, and optional HTTP transport mechanisms. The protocol defines data structures, cryptographic procedures, operational modes, and associated DNS and HTTP mechanisms. The reference implementation provides signing and verification primitives, DNS TXT resolution, and HTTP retrieval of identity documents. Full gateway enforcement behavior is implementation- defined. | |||||||||||||
| draft-liu-6man-aggregate-header-limit-problem-05.txt | ||||||||||||||
| Problem Statement with Aggregate Header Limit for IPv6 | ||||||||||||||
|
This document first proposes the concept of "Aggregate header limit for IPv6"(IPv6-AHL) to indicate the total header size that a router is able to process at full forwarding rate for IPv6 packets. Then this document describes the problems for path calculation and function enablement without the awareness of IPv6-AHL, and the considerations for IPv6-AHL collection are also included. | |||||||||||||
| draft-liu-6man-icmp-verification-10.txt | ||||||||||||||
| Extending ICMPv6 for SRv6-related Information Validation | ||||||||||||||
|
This document introduces the mechanism to verify the data plane against the control plane and detect data plane failures in IPv6/SRv6 networks by extending ICMPv6 messages. | |||||||||||||
| draft-liu-add-dnssd-edns-03.txt | ||||||||||||||
| DNS-Based Service Discovery for Encrypted DNS Services | ||||||||||||||
|
This document defines a DNS-Based Service Discovery (DNS-SD) mechanism for discovering encrypted DNS services in local networks. It specifies new service types (_dot._tcp, _doh._tcp, _doq._udp) and associated service parameters to enable zero-configuration discovery of DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) resolvers. This mechanism is defined for use with multicast DNS (mDNS), addressing critical privacy gaps in local networks while maintaining backward compatibility with RFC 6763. This document leverages SVCB and HTTPS resource records (RFC 9460) for parameter negotiation, with TXT records provided for compatibility with legacy implementations. | |||||||||||||
| draft-liu-add-ppp-edns-negotiation-02.txt | ||||||||||||||
| PPP IPCP Extensions for Encrypted DNS Server Negotiation | ||||||||||||||
|
This document defines extensions to the Point-to-Point Protocol (PPP) Internet Protocol Control Protocol (IPCP) for negotiating encrypted DNS resolver configurations. These extensions allow PPP peers to exchange information about encrypted DNS servers supporting protocols such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ). The design maintains backward compatibility with RFC 1877 while addressing modern security requirements. | |||||||||||||
| draft-liu-agent-metadata-sync-protocol-01.txt | ||||||||||||||
| Agent Metadata Synchronization Protocol | ||||||||||||||
|
The Internet of Agents (IoA) requires a robust infrastructure to manage the lifecycle, discovery, and interaction of autonomous agents across distributed network domains. While the Agent Gateway (AGW) provides a localized control point, large-scale deployments necessitate a mechanism for multiple gateways to synchronize agent metadata and routing information. This document specifies the Agent Metadata Synchronization Protocol (AMSP). AMSP facilitates the exchange of Agent Records between hierarchical gateways (Level-1 and Level-2), ensuring global reachability, efficient resource utilization, and loop-free metadata propagation. | |||||||||||||
| draft-liu-ai-agent-authorization-integration-00.txt | ||||||||||||||
| AI Agent Authorization Integration Framework | ||||||||||||||
|
This document describes how to integrate multiple OAuth 2.0 extensions to enable secure authorization for AI agents acting on behalf of users. It combines cross-domain identity, policy-based authorization, user consent evidence, and multi-hop delegation into a cohesive framework for autonomous agent authorization. | |||||||||||||
| draft-liu-bess-srv6-anycast-vpn-service-02.txt | ||||||||||||||
| SRv6 Anycast VPN Service | ||||||||||||||
|
In some multihoming SRv6 L3VPN and EVPN scenarios, there are requirements for the egress PE to advertise both unicast and anycast SRv6 Service SIDs for the same service. This document defines anycast flavor for SRv6 Service SIDs carried in BGP messages. | |||||||||||||
| draft-liu-bess-srv6-evpn-validation-05.txt | ||||||||||||||
| Data Plane Failure Detection Mechanisms for EVPN over SRv6 | ||||||||||||||
|
For MPLS EVPN, RFC9489 specifies the mechanisms for detecting data plane failures using LSP Ping. This document proposes a similar mechanism to detect data plane failures for EVPN over SRv6. | |||||||||||||
| draft-liu-cadi-01.txt | ||||||||||||||
| Cryptographic Asset Discovery and Inventory | ||||||||||||||
|
This document compiles existing Cryptographic Asset Discovery and Inventory (CADI) methods and analyze potential gaps. | |||||||||||||
| draft-liu-cfrg-ntru-family-security-considerations-00.txt | ||||||||||||||
| Security Considerations for NTRU-family KEMs | ||||||||||||||
|
This document provides an informational review checklist for NTRU- family KEMs. It covers security claims, assumptions, reductions, concrete attack estimates, correctness and decryption-failure analyses, and implementation behavior for named specifications and parameter sets. It does not define a KEM interface or make recommendations among candidate KEMs. | |||||||||||||
| draft-liu-fann-srv6-cc-00.txt | ||||||||||||||
| Congestion Control Based on SRv6 Path | ||||||||||||||
|
This document describes a congestion control solution based on SRv6. It defines mechanisms for congestion notification and flow control within an SRv6-based network, optimizing congestion handling through hierarchical congestion control messages along SRv6 paths. | |||||||||||||
| draft-liu-grow-bmp-multiple-peer-header-02.txt | ||||||||||||||
| Definition for BMP Multiple Peer Header | ||||||||||||||
|
This document proposes a format of multiple peer header for aggregating BMP messages. It can be used to compress multiple BMP messages with per-peer header into one aggregated BMP message, which could reduce the amount of reported BMP messages and reduce network overhead. | |||||||||||||
| draft-liu-grow-bmp-rm-aggregated-06.txt | ||||||||||||||
| Definition for Aggregated BMP Route Monitoring Message | ||||||||||||||
|
This document proposes an aggregated BMP Route Monitoring message based on the BMP Multi-Peer Header message (draft-liu-grow-bmp- multiple-peer-header). It can compress multiple BMP Route Monitoring messages into one aggregated BMP Route Monitoring message to reduce the amount of reported BMP Route Monitoring messages and reduce the network overhead. | |||||||||||||
| draft-liu-icnrg-cross-domain-compute-discovery-01.txt | ||||||||||||||
| Requirements for Name-Based Compute-Service Discovery in Heterogeneous Space-Terrestrial-Maritime Edge Networks | ||||||||||||||
|
Future edge systems may span terrestrial infrastructure, maritime gateways, and non-terrestrial nodes such as low-Earth-orbit satellites. In these environments, a computing service, its executable instances, input data, and reusable results may be distributed across intermittently connected and resource-constrained nodes. This document describes a problem statement, an illustrative network model, and requirements for name-based discovery of computing services and reusable results. The objective is to separate stable service identity from temporary execution location while supporting disruption awareness, metadata authenticity, controlled result reuse, and incremental deployment over existing IP and Information-Centric Networking infrastructures. This document does not define a wire protocol, a naming syntax, or a traffic-steering algorithm. | |||||||||||||
| draft-liu-icnrg-disruption-aware-task-descriptor-00.txt | ||||||||||||||
| Requirements for Disruption-Aware Compute-Task Descriptors in Heterogeneous Space-Terrestrial-Maritime Edge Networks | ||||||||||||||
|
Compute tasks in heterogeneous edge environments may traverse terrestrial, maritime, airborne, and non-terrestrial domains before an eligible execution site becomes reachable. Conventional request formats often assume an immediately selected endpoint and a continuously available request-response path. Those assumptions are fragile when connectivity is intermittent, service instances move, inputs are named and distributed, and duplicate delivery can occur. This document describes a problem statement, a conceptual compute- task descriptor, and requirements for carrying a portable task description across disruption-prone edge networks. The descriptor separates the identity and semantics of a task from a particular execution location. It binds the requested service, named inputs, relevant parameters, timing constraints, authorization policy, and expected result properties while supporting store-carry-forward operation, duplicate suppression, verifiable execution receipts, and result provenance. This document does not define a wire encoding, task-placement algorithm, traffic-steering protocol, or execution runtime. | |||||||||||||
| draft-liu-icnrg-verifiable-compute-results-00.txt | ||||||||||||||
| A Metadata Model for Verifiable and Reusable Compute-Result Objects in Information-Centric Edge Networks | ||||||||||||||
|
Distributed edge systems can execute the same logical computing service at multiple sites and can retain previously generated outputs in gateways, caches, or result stores. Reusing such an output can reduce communication and computation, but a payload alone does not indicate which service, inputs, parameters, execution environment, or validity conditions produced it. This document defines a conceptual metadata model for named compute-result objects. The model binds a result payload to service identity, input identity, invocation context, execution provenance, freshness information, and reuse policy. It also describes validation and cache-reuse workflows for intermittently connected and multi-domain edge environments. This document does not define a wire encoding, a naming syntax, a remote- attestation profile, or a traffic-steering protocol. | |||||||||||||
| draft-liu-idr-bgp-ls-sr-policy-spray-state-00.txt | ||||||||||||||
| BGP-LS Extension for SR Policy Packet Spray State | ||||||||||||||
|
This document proposes an extension to BGP-LS that allows a headend node, when reporting SR Policy state information via BGP-LS, to carry a new state flag at the candidate path level. This flag indicates whether the candidate path is currently being used for packet spraying. The information can be consumed by external controllers for path optimization, operations management or other purposes. | |||||||||||||
| draft-liu-idr-bgpls-sr-p2mp-policy-distribution-07.txt | ||||||||||||||
| Distribution of SR P2MP Policies and State using BGP-LS | ||||||||||||||
|
This document specifies the extensions to BGP Link State (BGP-LS) to distribute SR P2MP Policies and state. This allows operators to establish a consistent view of the underlying multicast network state, providing an efficient mechanism for the advertisement and synchronization of SR P2MP policies. | |||||||||||||
| draft-liu-iotops-modbus-seriallink-sec-spec-07.txt | ||||||||||||||
| Modbus Serial Link Communication Security Protocol Reference Specification and implementation guide | ||||||||||||||
|
The Modbus TCP protocol has adopted TLS-based security standards; however, Modbus serial communication over EIA/TIA-485 multi-point systems, commonly used in 2-wire or 4-wire configurations, lacks standardized security mechanisms. These systems support cable lengths exceeding 1000m at baud rates up to 9600 bit/s with AWG26 or thicker cables, while Category 5 cables can reach up to 600m. As an application layer protocol, despite its widespread application, the absence of encryption and authentication in Modbus protocol via serial links exposes plaintext data to risks such as MIM interception, modification under attacks such as side-channel analysis etc., particularly in long-distance or bridged network scenarios. Enhancing Modbus serial link security requires introducing proper encryption and authentication methods tailored to varied deployment environments onsidering the characteristics of serial links. A proposed security standard guide outlines lightweight encryption and authentication mechanisms to improve confidentiality and integrity while maintaining compatibility with existing Modbus devices, offering a practical upgrade path for secure industrial control systems. | |||||||||||||
| draft-liu-ippm-active-loss-considerations-00.txt | ||||||||||||||
| Considerations for Interpreting Packet Loss Observed by Active Performance Measurements | ||||||||||||||
|
Active performance measurement protocols and metrics are commonly used to measure packet loss, delay, delay variation, reachability, and path behavior. When an active measurement packet is not received, a response is missing, or a measurement exchange times out, the measurement result identifies the observable outcome but often does not identify the underlying cause. Loss observed by active performance measurements can be associated with congestion, queue discard, link or forwarding failures, routing changes, endpoint or reflector behavior, administrative filtering, policing, multipath effects, or validation-related packet discard such as Source Address Validation (SAV). Different operational conditions can produce similar measurement observations, but they may have different meanings and require different troubleshooting actions. This document discusses considerations for interpreting packet loss observed by active performance measurements. It provides a common set of considerations for separating measured outcomes from inferred causes, describes operational conditions that can lead to observed loss, discusses implications for one-way and two-way measurements, delay and delay variation interpretation, OWAMP, TWAMP, STAMP, and measurements over ECMP and link aggregation. It also discusses how some considerations may apply to hybrid and passive performance measurements and identifies sources of operational context that can help operators and measurement systems reason about possible explanations. | |||||||||||||
| draft-liu-moq-feedback-00.txt | ||||||||||||||
| MoQ Feedback | ||||||||||||||
|
This document defines an extension to Media over QUIC Transport (MOQT) that enables MoQ receivers to report delivery quality information for media Objects to senders. The MoQ layer synthesizes MMF feedback and local congestion control (CC) output to compute control decisions such as bitrate, frame rate, and pacing, and inform the CC algorithm module via a cross-layer control interface. This mechanism reuses the MOQT Track/Object data model without introducing new control message types. While QUIC ACK and reception timestamp extensions continue to provide per-packet CC signals; this mechanism adds per-Object media semantic feedback when the MMF extension is negotiated and enabled. | |||||||||||||
| draft-liu-moq-live-agent-interaction-01.txt | ||||||||||||||
| Live Agent Interaction over MoQ | ||||||||||||||
|
This document defines a protocol for real-time interactive communication between users and AI agents over Media over QUIC Transport (MOQT). It specifies how streaming inference outputs (ASR transcripts, LLM tokens, TTS audio) map to the MOQT object model, defines a turn-taking control protocol with barge-in support for voice interactions, and establishes track structure conventions for live agent sessions. The protocol operates as an application-layer profile on top of MOQT without modifying transport semantics. | |||||||||||||
| draft-liu-oauth-authorization-evidence-01.txt | ||||||||||||||
| Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens | ||||||||||||||
|
This specification defines an authorization details type for including authorization evidence and audit trail information in OAuth 2.0 access tokens using the Rich Authorization Requests (RAR) framework. When an Authorization Server processes user consent, it enriches the authorization details with cryptographic proof of user confirmation, supporting accountability, compliance, and dispute resolution in scenarios where autonomous agents act on behalf of users. | |||||||||||||
| draft-liu-oauth-chain-delegation-00.txt | ||||||||||||||
| Delegation Chain for OAuth 2.0 | ||||||||||||||
|
RFC 8693 defines the act claim for expressing delegation semantics in JWTs, including nested multi-hop actor identification. However, act captures only the identity of each actor in the chain, not the authorization constraints applied at each hop, and is constructed unilaterally by the Authorization Server without cryptographic confirmation from the delegating agent. This specification defines the delegation_chain JWT claim as a structured delegation record companion to act: an ordered array of delegation records, each capturing the Authorization Server's attestation and, when present, the delegated policy constraints, and optionally carrying the delegator's cryptographic confirmation. Together, act and delegation_chain provide both runtime authorization and verifiable delegation lineage for multi-hop agent delegation. The specification supports cross-domain delegation by composing with the identity chaining transport pattern, and integrates a user interaction mechanism for explicit consent when required by policy or regulation. | |||||||||||||
| draft-liu-oauth-cross-domain-txn-token-00.txt | ||||||||||||||
| Cross-domain Transaction Tokens | ||||||||||||||
|
This document describes a mechanism for Cross-Domain Transaction Tokens, which enables the safe maintenance and propagation of user identity, workload identities, and authorization context across multiple trust domains. | |||||||||||||
| draft-liu-oauth-rego-policy-00.txt | ||||||||||||||
| Rego Policy Language for OAuth 2.0 Authorization | ||||||||||||||
|
AI agents exhibit dynamic, unpredictable behavior that cannot be fully described by traditional OAuth 2.0 scopes. This specification defines a behavioral authorization framework that enables clients, particularly AI agents, to propose Rego policy-based behavioral constraint contracts in OAuth 2.0 authorization flows using Rich Authorization Requests (RAR). It defines the rego_policy authorization data type for carrying behavioral constraint contracts in authorization_details, shifting the authorization model from static permission sets to runtime behavioral verification. It also defines a reverse-guided authorization mechanism allowing resource servers to return structured policy constraints in error responses, enabling agents to dynamically adapt their behavior and construct appropriate authorization requests. | |||||||||||||
| draft-liu-opsawg-ipfix-bgp-vpn-03.txt | ||||||||||||||
| Export of BGP VPN Information in IPFIX | ||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) information elements to carry information that can be used to identify the egress PE in BGP VPN scenarios. | |||||||||||||
| draft-liu-opsawg-ipfix-igp-algo-01.txt | ||||||||||||||
| Export of IGP Algorithm Information in IPFIX | ||||||||||||||
|
This document introduces a new IPFIX information element (IE) to identify the IGP algorithm information related with the Segment Identifier (SID) or the IPv4/IPv6 prefix. | |||||||||||||
| draft-liu-opsawg-ipfix-mpls-mna-01.txt | ||||||||||||||
| Export of MPLS Network Action (MNA) Information in IPFIX | ||||||||||||||
|
This document introduces new IPFIX IEs for exporting MPLS Network Action (MNA) information in IPFIX, covering both in-stack and post- stack MNAs. | |||||||||||||
| draft-liu-opsawg-ipfix-muti-layer-02.txt | ||||||||||||||
| Export of Multiple Encapsulation Layer Information in IPFIX | ||||||||||||||
|
This document analyzes the requirements and problems when monitoring flows with multi-layer network encapsulations. This document aims to solve this problem by updating RFC7011 and introducing new IPFIX IEs for encapsulation layer indication. | |||||||||||||
| draft-liu-opsawg-stbl-req-per-packet-00.txt | ||||||||||||||
| Ability Requirements for Stability Guarantees in Per-packet Load Balancing Networks | ||||||||||||||
|
Many per-packet load balancing mechanisms have been proposed to optimize the performance of AI networks. However, per-packet load balancing poses significant challenges to network stability assurance. This draft analyzes these challenges, as well as the ability requirements for stability guarantees in per-packet load balancing networks. | |||||||||||||
| draft-liu-pce-path-delay-difference-00.txt | ||||||||||||||
| PCEP Extensions for Path Delay Difference | ||||||||||||||
|
In certain scenarios, such as load balancing, P2MP and DetNet, it is required that the delay difference among a set of paths to be controled within an expected range. This document describes extensions to PCEP to use the delay difference as a constraint for end-to-end path computation. | |||||||||||||
| draft-liu-pce-pcep-tunnel-flowspec-01.txt | ||||||||||||||
| PCEP Extension for Tunneled Flow Specification | ||||||||||||||
|
Traffic flows may be categorized and described using "Flow Specifications". RFC8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes. RFC 9168 specifies a set of extensions to PCEP to support the dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of. The extensions defined in this document extend the support for tunneled traffic filtering rules. | |||||||||||||
| draft-liu-pim-rpf-vector-conflict-resolution-03.txt | ||||||||||||||
| PIM Reverse Path Forwarding (RPF) Vector Conflict Resolution | ||||||||||||||
|
RFC7891 Section 7 defines the handling principles for PIM Join attributes with same type of RFF Vector and Explicit RFP Vector, but with different contents are received. However, it does not address scenarios where one downstream router includes a RFF Vector in its message while another does not. This leaves the handling of such conflicts unspecified. This document updates RFC 5496 and RFC 7891 by supplementing the existing specifications with handling rules for this specific conflict scenario. | |||||||||||||
| draft-liu-rtgwg-adaptive-routing-notification-03.txt | ||||||||||||||
| Adaptive Routing Notification for Load-balancing | ||||||||||||||
|
In this document, adaptive routing is referred to as a technology that makes dynamic traffic forwarding decisions based on changes in traffic load and network topology, devices with adaptive routing capabilities can dynamically select the outport in the forwarding table based on the congestion condition of the outport or downstream link. This document focuses on the information carried in (Adaptive Routing Notification)ARN messages and how they are delivered and processed in the network. | |||||||||||||
| draft-liu-rtgwg-llmsync-multicast-01.txt | ||||||||||||||
| Multicast Use Cases for Large Language Model Synchronization | ||||||||||||||
|
Large Language Models (LLMs) deployments are becoming increasingly widespread, with inference services being the most common application. This draft will discuss multicast use cases for inference cloud services. | |||||||||||||
| draft-liu-rtgwg-path-aware-remote-protection-05.txt | ||||||||||||||
| Path-aware Remote Protection Framework | ||||||||||||||
|
This document describes the framework of path-aware remote protection. | |||||||||||||
| draft-liu-sidrops-ipfix-bgp-pov-00.txt | ||||||||||||||
| Export of BGP Prefix Origin Validation in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document defines an IP Flow Information Export (IPFIX) Information Element for monitoring the state of Resource Public Key Infrastructure (RPKI) based BGP Prefix Origin Validation. The Information Element enables network operators to collect and analyze BGP route validation states (valid, invalid, not-found) to facilitate the detection of potential route hijacks improving network observability and security. | |||||||||||||
| draft-liu-sidrops-rpki-rtr-over-quic-04.txt | ||||||||||||||
| RPKI to Router Protocol over QUIC | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides practical and secure semantics for the RTR protocol, particularly fast connection establishment and multi-stream carrying, thereby reducing the time required to complete RTR data synchronization. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. | |||||||||||||
| draft-liu-sidrops-rrdp-delta-retention-policy-02.txt | ||||||||||||||
| RPKI Repository Delta Protocol (RRDP) Delta File Retention Policy | ||||||||||||||
|
This document updates RFC 8182 (The RPKI Repository Delta Protocol) by specifying an optimized delta file retention policy based on client access patterns. The proposed mechanism allows RRDP servers to maintain only the delta files required by active clients, reducing storage requirements while maintaining compatibility with existing clients. By tracking which serial numbers are being requested by active clients, the repository can determine the minimum serial number needed by any client and safely prune delta files that update from earlier serial numbers. The proposed mechanism provides several benefits, including reduced storage requirements, smaller notification files, and more efficient use of bandwidth and processing resources. It also maintains backward compatibility with existing RRDP clients, requiring no changes to client implementations. | |||||||||||||
| draft-liu-spring-srv6-bsid-relay-00.txt | ||||||||||||||
| SRv6 BSID with Notification Message Relay | ||||||||||||||
|
This document defines a new SRv6 Endpoint behavior, End.B6.Encaps.Relay, for Binding SID (BSID) nodes in SRv6 networks. The behavior enables BSID nodes to relay tunnel-internal notification messages, such as ICMPv6 errors and congestion notifications, back to the upstream tunnel source node through a mapping mechanism. | |||||||||||||
| draft-liu-srv6ops-bfd-srv6-policy-encap-00.txt | ||||||||||||||
| Operational Considerations for BFD Encapsulation in SRv6 Policy | ||||||||||||||
|
Bidirectional Forwarding Detection (BFD) mechanisms can be used for fast detection of failures in the forwarding path of SR Policy. This document describes the Operational Guidance for BFD Encapsulation in SRv6 Policy. The BFD packets may be encapsulated in Insert-mode or Encaps-mode. | |||||||||||||
| draft-liu-srv6ops-sr-protection-06.txt | ||||||||||||||
| Operational Guidance for Protection Mechanisms in SRv6 Networks | ||||||||||||||
|
This document describes the Operational Guidance for protection of Segment Routing Over IPv6 (SRv6) networks. | |||||||||||||
| draft-liu-wimse-wit-attestation-00.txt | ||||||||||||||
| Carrying Remote Attestation Evidence in Workload Identity Tokens (WIT) | ||||||||||||||
|
This document specifies how Remote Attestation evidence, as defined by the IETF RATS architecture, can be conveyed within a Workload Identity Token (WIT) as used in the WIMSE (Workload Identity for Micro-Services Environments) framework. The WIT includes attestation measurements that enable fast-path policy evaluation without requiring immediate access to full evidence. The WIT is bound to the HTTP request using OAuth 2.0 Demonstrating Proof-of-Possession (DPoP), ensuring that attestation claims are protected against replay and token theft. This specification defines a two-tier verification model: lightweight verification using embedded measurements for common scenarios, and deep verification using externalized evidence for high-assurance requirements. This enables secure, cross-domain verification of workload integrity without requiring direct access to platform- specific reference values, while enabling efficient deployments. | |||||||||||||
| draft-liu-ztcpp-zt-problem-statement-00.txt | ||||||||||||||
| Zero trust standards in IETF: use cases and problem statement | ||||||||||||||
|
The traditional "castle-and-moat" security paradigm is no longer effective for some emerging scenarios, such as cloud services, remote workforces and intelligent agents. Zero trust (ZT) has emerged as the new paradigm, holding on the "never trust, always verify" principle, treats every single access request as untrudted and requires veficication. While a high-level atchitectural guidance exists, notably from NIST in SP 800-207 where thtenants of zero trust are well interperated, the industry lacks the open, interoperable framework and protocol necessary for building multi-vendor zero trust practice enrironment. This document presents the problem statement for zero trust interoperability, outlines the key use cases, and argue for the need for standardization in the IETF. It discusses the possible scope for zero trust standardization work in the IETF, identifying which aspects are well suited for the IETF protocols and which are better addressed by other bodies. The aim of this document is to initiate a discussion in the IETF community on the necessity and prospective of promoting zero trust related work here. | |||||||||||||
| draft-livingood-low-latency-deployment-16.txt | ||||||||||||||
| ISP Dual Queue Networking Deployment Observations | ||||||||||||||
|
The IETF's Transport and Services Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents describe a new architecture and protocol for deploying low latency networking. Since deployment decisions are left to implementers, this document explores some of the implications of those decisions and makes suggestions that can help drive adoption and acceptance of L4S and NQB based on observations from the world's first large scale deployment. | |||||||||||||
| draft-lizihan-intelligent-hybrid-cloud-00.txt | ||||||||||||||
| General Technical Capability Requirements for Intelligent Hybrid Cloud Platform | ||||||||||||||
|
This document specifies the general technical capability requirements for an intelligent hybrid cloud platform. An intelligent hybrid cloud combines compute, storage, and network resources across multiple cloud deployment models, leveraging artificial intelligence algorithms to implement active hybrid cloud management functions such as intelligent resource scheduling, intelligent analysis, intelligent statistics, and intelligent prediction. It also provides support for intelligent computing power and large model development-related service technical capabilities within the hybrid cloud. This document defines capability requirements across infrastructure, unified platform management, model cross-cloud development, and intelligent operations and maintenance. This document is applicable to the design, development, and deployment of intelligent hybrid cloud platforms by cloud service providers, and provides reference and specifications for users designing and deploying intelligent hybrid cloud platforms. | |||||||||||||
| draft-lkspa-rats-verifiable-geo-fence-03.txt | ||||||||||||||
| Verifiable Proof of Environment Attestation Profile | ||||||||||||||
|
Operators of regulated, sovereign, and high-assurance deployments require hardware-rooted, machine-verifiable proof that a workload executes in its approved environment. Current remote attestation mechanisms address two relevant properties in isolation: platform integrity — that the hardware and software stack are in an approved, untampered state — and physical residency — that the hardware resides within an approved geographic boundary. Neither property alone is sufficient: integrity without residency permits a valid platform to operate outside approved boundaries; residency without integrity permits a compromised platform to claim valid placement. This document defines the *Verifiable Proof of Environment Attestation Profile (V-PEA)*, a profile of the RATS Architecture {{!RFC9334}} that fuses both properties into a single TPM-sealed Evidence structure (lah-bundle). V-PEA defines two Evidence dimensions: *WHAT* — hardware provenance (TPM Attestation Key registered and manufacturer-endorsed), platform integrity (firmware and OS state matching reference values), and workload agent software integrity (binary digest matching an approved value); and *WHERE* — physical residency within an approved geographic boundary. A TPM quote seal binds WHAT and WHERE into a single unforgeable statement: neither dimension can be forged or transplanted without invalidating the other. For the WHERE dimension, V-PEA supports Transparent Zero-Knowledge Proofs (ZKPs), enabling an Attester to prove geographic compliance without disclosing precise coordinates. A positive V-PEA Attestation Result enables a Relying Party to issue hardware-rooted credentials or authorize operations — combining verified execution environment (WHAT) with verified physical placement (WHERE) — before releasing sensitive assets or granting access. Integration with workload identity systems is described in the WIMSE Integration appendix. | |||||||||||||
| draft-ll-idr-flowspec-redirect-sidlist-01.txt | ||||||||||||||
| BGP Flow-Spec Redirect to SR Segment List Action | ||||||||||||||
|
BGP Flow Specification (Flow-spec) provides a mechanism for distributing traffic filtering and policy-based forwarding rules. Existing works enables traffic steering into an SR Policy. However, in Artificial Intelligence (AI) network scenarios, "elephant flows" may require deterministic forwarding over specific segment lists within an SR Policy candidate path. This document specifies a new BGP Flow-spec Redirect action that identifies a specific segment list within an SR Policy. | |||||||||||||
| draft-llg-opsawg-ipfix-over-quic-03.txt | ||||||||||||||
| IPFIX Protocol over QUIC | ||||||||||||||
|
The IP Flow Information Export (IPFIX) protocol provides a means for transmitting Traffic Flow information over the network. IPFIX Flow Records and Template Records can be carried over a number of transport protocols from an IPFIX Exporter to an IPFIX Collector. The supported transport protocols are SCTP, UDP and TCP. QUIC provides inherently secure, stream-multiplexed, and reliable connections for IPFIX protocol. Especially, a single QUIC connection can carry multiple independent streams, which can improve management scalability between Exporters and Collectors. This document describes how to use IPFIX protocol over the QUIC transport protocol, named IPFIXoQUIC. | |||||||||||||
| draft-lll-idr-flowspec-filter-qp-01.txt | ||||||||||||||
| BGP Flow Specification Filtered by Destination-QP | ||||||||||||||
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type named Destination-QP (Destination Queue Pair) to support filtering by Destination-QP. | |||||||||||||
| draft-lll-srv6ops-dci-srv6-lb-00.txt | ||||||||||||||
| SRv6-based Adaptive Load Balancing for AI DCI | ||||||||||||||
|
This document describes an SRv6-based adaptive load balancing architecture for AI Data Center Interconnection (DCI) scenarios, where RoCEv2 elephant flows traverse WAN between storage and compute sites under the storage-compute separation paradigm. The architecture employs a controller-driven closed loop: telemetry-based flow and path monitoring, SL-level imbalance detection, and BGP Flowspec-based steering with QP-level matching granularity and Segment List-level action precision. This supplements the default QP-aware hash-based SL selection with dynamic, explicit flow steering to resolve hash collisions and persistent load imbalance. | |||||||||||||
| draft-llz-bier-ipfix-bier-00.txt | ||||||||||||||
| Export of BIER Information in IP Flow Information Export (IPFIX) | ||||||||||||||
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Bit Index Explicit Replication (BIER) such as data contained in BIER header that traffic is being forwarded with. | |||||||||||||
| draft-lnehru-lisp-silenthost-detection-00.txt | ||||||||||||||
| LISP Silent Host Discovery using the Mapping System | ||||||||||||||
|
The on-demand discovery model of the Locator/ID Separation Protocol (LISP) is ineffective for "silent hosts", endpoints that do not initiate traffic. This is a common challenge in environments like manufacturing and IoT environments, where low-power devices frequently go silent to conserve energy. This document proposes a mechanism to discover these hosts by using the LISP mapping system itself. xTRs that are able to probe a given EID prefix register that capability with the Map-Server. When a Map-Request for an unknown destination arrives at the Map-Server, it is forwarded and replicated to all xTRs that have registered the covering EID prefix, initiating a controlled, on-demand discovery process for that specific host. This approach provides a scalable alternative to network flooding for locating silent endpoints. | |||||||||||||
| draft-loffredo-regext-rdap-verified-contacts-04.txt | ||||||||||||||
| Registration Data Access Protocol (RDAP) Extension for Verified Contact Information | ||||||||||||||
|
This document describes an extension to the Registration Data Access Protocol (RDAP) that allows the inclusion of verification status information for contact fields such as email addresses and phone numbers. The goal is to improve data quality and trustworthiness of RDAP responses by indicating which pieces of contact data have been verified and how. | |||||||||||||
| draft-lohmann-qikvrt-effect-ack-03.txt | ||||||||||||||
| QIK-VRT Effect Acknowledgement: Separating Receipt from Authorization for Downstream Effect | ||||||||||||||
|
Transport acknowledgements establish technical receipt; they do not establish that a received information unit is understood, policy- compliant, or authorized to produce a downstream effect. This document defines an Experimental application-layer control record, called EFFECT_ACK, that separates receipt from effect authorization. The protocol has five closed version-1 outcomes. Ordinary downstream release is permitted only for EFFECT_ACK_DONE and only after validation of the record, its policy and evidence bindings, its freshness, and its authenticated origin. This document specifies the state-selection algorithm, version handling, a deterministic JSON representation, hash chaining, timeout behavior, conformance requirements, and security and privacy boundaries. This protocol does not modify TCP, QUIC, or the OSI model; does not solve the halting problem; and does not establish the truth of external evidence. It provides a machine-checkable authorization boundary under explicitly stated deployment assumptions. | |||||||||||||
| draft-longa-cfrg-frodokem-03.txt | ||||||||||||||
| FrodoKEM: key encapsulation from learning with errors | ||||||||||||||
|
This internet draft specifies FrodoKEM, an IND-CCA2 secure Key Encapsulation Mechanism (KEM). About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem/. Source for this draft and an issue tracker can be found at github.com/dstebila/frodokem-internet-draft. | |||||||||||||
| draft-longa-cfrg-frodokem-security-considerations-00.txt | ||||||||||||||
| Security Considerations for FrodoKEM | ||||||||||||||
|
ISO standardized FrodoKEM in June 2026 [ISO18033-2-AMD2]. This document provides security guidance for FrodoKEM for use in protocols. It explains what security claims protocol designers may rely on, what assumptions and conditions are required, what parameter sets are in scope, and what implementors need to do to use FrodoKEM safely. The scope follows the current FrodoKEM Internet-Draft [I-D.FrodoKEM]. | |||||||||||||
| draft-lopes-rank-00.txt | ||||||||||||||
| Rank,a Resource Management Protocol for Allocation | ||||||||||||||
|
This document specifies Rank, a comprehensive resource management protocol designed for modern edge-to-cloud computing infrastructures. While traditional network protocols focus primarily on managing link bandwidth and router buffer space, the shift toward decentralized services demands a broader approach to resource allocation. Rank addresses this gap by simultaneously managing computing capabilities (such as CPU, memory, and storage), network capacity, and time- sensitive constraints (such as clock synchronization and task scheduling) within a unified framework. Operating primarily as a fully distributed protocol, Rank enables dynamic resource discovery, estimation, allocation, and sharing. It works by establishing a path between a source ("talker") and a destination ("listener") node, actively negotiating resource requirements across all intermediate nodes. Because it is fully distributed, all participating nodes carry equal responsibility in handling a session, such as processing requests, evaluating their own capacity to meet the resource demands, and strategically forwarding messages to ensure an optimized, end-to-end connection without relying on a centralized controller. | |||||||||||||
| draft-lozano-icann-registry-interfaces-26.txt | ||||||||||||||
| ICANN Registry Interfaces | ||||||||||||||
|
This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. | |||||||||||||
| draft-lp-idr-bgp-algorithm-01.txt | ||||||||||||||
| Advertisement of Algorithm in BGP | ||||||||||||||
|
This document proposes extensions to BGP to support algorithm-based end-to-end path establishment. | |||||||||||||
| draft-ls-idr-bgp-ls-service-metadata-09.txt | ||||||||||||||
| Distribution of Service Metadata in BGP-LS | ||||||||||||||
|
In edge computing, a service may be deployed on multiple instances within one or more sites, called edge service. The edge service is associated with an ANYCAST address in the IP layer, and the route of it with potential service metadata will be distributed to the network. The Edge Service Metadata can be used by ingress routers to make path selections not only based on the routing cost but also the running environment of the edge services. The service route with metadata can be collected by a PCE(Path Compute Element) or an analyzer for calculating the best path to the best site/instance. This draft describes a mechanism to collect information of the service routes and related service metadata in BGP-LS. | |||||||||||||
| draft-ls-ipsecme-ipcomp-exclude-transport-layer-03.txt | ||||||||||||||
| IP Payload Compression excluding transport layer | ||||||||||||||
|
IP Payload Compression Protocol (IPComp) is used for compressing the IP payload in transmission to increase communication performance. The IPComp is applied to the payload of the IP datagram, starting with the first octet immediately after the IP header in IPv4, and the first octet after the excluded IPv6 Extension headers. However, transport layer information such as source port and destination port are useful in many network functions in transmission. This document defines extensions of IP payload compression protocol (IPComp) to support compressing the payload excluding the transport layer information, to enable network functions using transport layer information (e.g., ECMP) working together with the payload compression. This document also defines an extension of IPComp to indicate the payload is not compressed to solve the out-of-order problems between the compressed and uncompressed packets. | |||||||||||||
| draft-lu-rats-cross-platform-attestation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-lu-rats-federated-attestation-infrastructure-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-luan-cats-catpts-01.txt | ||||||||||||||
| A Timescale-Aware Framework for Compute-Aware Task Placement and Traffic Steering in Heterogeneous Geo-Distributed Computing Networks | ||||||||||||||
|
Geographically distributed compute-intensive services require coordinated selection of execution sites and wide-area traffic paths. Placement changes slowly because service relocation may involve model loading, state migration, or execution-environment reconfiguration, while traffic splitting can be changed more frequently. This document evolves the CATPTS framework by defining a timescale- aware control architecture for source-compute-destination services. A slow-timescale placement function uses abstracted multipath and failure information to select a compute site. A fast-timescale traffic function then refines the input and output traffic allocations across candidate paths while holding placement fixed. The framework also introduces scenario-based service-loss estimation and an optional Conditional Value at Risk (CVaR) policy for limiting tail loss caused by compute-site or network-link failures. This document specifies architectural principles, information requirements, workflows, and operational considerations; it does not specify protocol extensions or a mandatory optimization algorithm. | |||||||||||||
| draft-luan-rtgwg-sdaf-01.txt | ||||||||||||||
| Symmetry-Driven Asynchronous Forwarding with Fast Reroute for LEO Satellite Networks (SDAF) | ||||||||||||||
|
Interior Gateway Protocols (IGPs) such as OSPF are commonly employed in satellite networks to address topology awareness and autonomous routing in response to link interruptions, link/node failures, and subsequent repairs. However, IGP-based approaches suffer from inherent limitations. Synchronization delays between the control plane and the forwarding plane can cause routing black holes, while asynchronous convergence across nodes may induce micro-loops (as described in prior work), leading to packet loss and congestion. These issues are particularly exacerbated in satellite networks characterized by highly dynamic topologies, long inter-satellite propagation delays, and constrained on-board computing resources. This document describes the Symmetry-Driven Asynchronous Forwarding (SDAF) mechanism, which leverages the intrinsic symmetry of toroidal topologies in satellite networks. Low Earth Orbit (LEO) satellite constellations are typically composed of multiple circular orbital planes, forming a toroidal topology by inter-satellite links. SDAF autonomously triggers and processes reverse flows based solely on local link-state information, without requiring control-plane convergence, protocol extensions, or packet header modifications. SDAF is fully compatible with existing protocols and technologies such as OSPFv3, IS-IS, and MPLS, and is specifically tailored to the resource-constrained nature of satellite systems. It achieves microsecond-scale convergence and low packet loss under failure conditions. Simulation results and tests conducted on actual satellite routers demonstrate that the SDAF mechanism significantly suppresses packet loss caused by routing black holes and micro-loops, while also alleviating link congestion and packet reordering issues. | |||||||||||||
| draft-lucente-grow-bmp-offline-03.txt | ||||||||||||||
| BMP Snapshots | ||||||||||||||
|
BMP (BGP Monitoring Protocol) is perfectly suited for real-time consumption but less ideal in stream processing and off-wire historical scenarios. The issue is that the necessary information to produce a complete view and enabling correct processing of all messages in the stream, is only sent out at the beginning of the BMP session. This document introduces the concept of BMP Snapshots, enabling BMP stations to synchronize mid-stream, and, providing the basis for self-contained, time-binned archiving of BMP data. | |||||||||||||
| draft-luechow-route86-timestamp-01.txt | ||||||||||||||
| Route86: A Compact Context-Dependent Timestamp Format | ||||||||||||||
|
This document specifies Route86, a compact textual timestamp format for constrained message transports. A Route86 value consists of a three-character Base36 calendar-day component and a three-digit decimal time-of-day component. The canonical representation occupies exactly six ASCII characters. The calendar component is interpreted relative to an external reference date. The reference date itself encodes as AAA. The time- of-day component divides a fixed BMT day, defined here as UTC+01:00 without daylight-saving adjustment, into 1000 intervals of 86.4 seconds. | |||||||||||||
| draft-lukianets-open-ethics-transparency-protocol-10.txt | ||||||||||||||
| Open Ethics Transparency Protocol | ||||||||||||||
|
The Open Ethics Transparency Protocol (OETP) is an application-level protocol for publishing and accessing ethical Disclosures of IT Products and their Components. The Protocol is based on HTTP exchange of information about the ethical "postures", provided in an open and standardized format. The scope of the Protocol covers Disclosures for systems such as Software as a Service (SaaS) Applications, Software Applications, Software Components, Application Programming Interfaces (API), Automated Decision-Making (ADM) systems, and systems using Artificial Intelligence (AI). OETP aims to bring more transparent, predictable, and safe environments for the end-users. The OETP Disclosure Schema is an extensible JSON-based format. | |||||||||||||
| draft-lundholm-kaif-00.txt | ||||||||||||||
| The Kindred Agent Identity Framework (KAIF) | ||||||||||||||
|
The Kindred Agent Identity Framework (KAIF) is an OAuth 2.0 token exchange mechanism for delegated agent-to-service authorization, combining RFC 8693 token exchange with SPIFFE workload identity attestation and operator-assigned authorization tiers. This document specifies the protocol mechanics, deployment profiles, and interoperability requirements for systems implementing agent authorization with audit accountability. KAIF is intended for scenarios in which an operator (human principal) provisionally authorizes an agent (automated workload) to perform bounded actions on their behalf, with cryptographic proof of authorization, delegation depth tracking, and revocation in real time. This document is intentionally vendor-neutral in its normative requirements. Cloud platforms, model providers, workflow systems, and audit backends discussed by implementations are informative deployment examples, not part of the KAIF wire protocol. | |||||||||||||
| draft-lx-msr6-rgb-segment-06.txt | ||||||||||||||
| RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6 | ||||||||||||||
|
This document introduces the RGB (Replication through Global Bitstring) Segment for Multicast Source Routing over IPv6. | |||||||||||||
| draft-lx-spring-srv6-rate-control-00.txt | ||||||||||||||
| SRv6-based Rate Control | ||||||||||||||
|
This document describes a rate control mechanism for Segment Routing over IPv6 (SRv6) network slices. It addresses the challenge of balancing resource utilization and congestion avoidance in over- committed slice deployments. The mechanism leverages a token-based scheduler to differentiate between Committed Information Rate (CIR) and Peak Information Rate (PIR) traffic, and defines procedures for calculating initial PIR values and dynamically adjusting them based on network conditions. Dynamic rate adjustments are triggered by localized congestion or underutilization, enabling proactive rate control and efficient bandwidth sharing among slices sharing common physical links. | |||||||||||||
| draft-ly-multi-agent-in6g-00.txt | ||||||||||||||
| Multiple Agents Collaboration in 6G Network | ||||||||||||||
|
This document describes the progress of 6G study on AI topic, e.g. key issues, potential solutions and alternative communication protocols. Despite the apparent overlap between 3GPP and IETF in the hot topics of Agents e.g. communication protocols, discovery, authorization and etc., 3GPP and IETF address different problems due to consideration of network boundaries. Thus this document tracks the progress of 6G study to identify dependencies on IETF protocols within the agent communication topics. | |||||||||||||
| draft-lynch-ai-visibility-lifecycle-02.txt | ||||||||||||||
| The AI Visibility Lifecycle Framework | ||||||||||||||
|
This document describes the 11-Stage AI Visibility Lifecycle, a stage-based observational framework describing how websites achieve visibility within AI discovery, comprehension, trust, and human exposure systems. The framework identifies three distinct phases -- AI Comprehension (Stages 1-5), Trust Establishment (Stages 6-8), and Human Visibility (Stages 9-11) -- through which domains progress from initial AI crawling to sustainable human-facing visibility. | |||||||||||||
| draft-lz-fann-bandwidth-notification-00.txt | ||||||||||||||
| Fast Notification for Link Bandwidth | ||||||||||||||
|
This document proposes a data-plane-based method for rapidly advertising end-to-end path bandwidth information using a bitmap encoding. The mechanism enables fast load-balancing adjustments in AI/ML data center fabrics. | |||||||||||||
| draft-ma-6man-ra-dns64-flag-02.txt | ||||||||||||||
| Updates to DNS64 Functionality Advertisement for DNS RA Option | ||||||||||||||
|
This document defines a new flag in the DNS RA Option to advertise the DNS64 functionality. This extension enables automatic configuration of DNS64 resolution, improving deployability in IPv6 transition scenarios. | |||||||||||||
| draft-ma-dnssd-srp-service-routing-00.txt | ||||||||||||||
| Service Type Routing for DNS-SD Service Registration Protocol | ||||||||||||||
|
This document defines the _str._dns-sd._udp (Service Type Routing) metadata label, a backward-compatible extension for SRP registration. This mechanism relaxes the original single-registration-domain constraint, enabling clients to publish distinct service types to independent target DNS zones and dedicated SRP registrar instances. It supports fine-grained operational tuning, administrative isolation of heterogeneous services. This extension only modifies SRP registration domain selection logic, fully preserves existing SRP wire format, authentication, leasing and discovery behaviors, and introduces no impact on DNS-SD service browsing operations. | |||||||||||||
| draft-ma-v6ops-5g-ipv6only-04.txt | ||||||||||||||
| Considerations of IPv6-only Deployment in 5G Mobile Networks | ||||||||||||||
|
This document describes a practical guide of deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G networks. It also covers key 5G concepts and architectures, configuration methods and operational challenges. | |||||||||||||
| draft-ma-v6ops-pe-ipv6only-reqs-01.txt | ||||||||||||||
| Requirements for Provider Edge in IPv6-only Underlay Networks | ||||||||||||||
|
This document defines functional, protocol, and operational requirements for Provider Edge (PE) devices operating in a multi- domain network environment where the underlay is exclusively based on IPv6. These requirements ensure consistent service delivery, interoperability, and efficient operations across autonomous domains while supporting IPv4-as-a-Service (IPv4aaS). | |||||||||||||
| draft-macgowan-dosd-02.txt | ||||||||||||||
| Domain Operational Standing Declaration (DOSD) Protocol | ||||||||||||||
|
This document describes the Domain Operational Standing Declaration (DOSD) protocol, a voluntary DNS-based mechanism by which domain owners may publish operational declarations, stewardship status, provenance references, documentation indexes, and mediation routing information in a machine-discoverable way. DOSD uses DNS TXT records for discovery, a well-known JSON file for canonical node metadata, and an optional well-known documentation index for discovering protocol drafts, supporting specifications, implementation documents, and historical records. This revision adds three optional operational profiles: a Distress Notice profile (DOSD-DN) for time-bounded duress signaling, an Emergency Contact object and De-escalation profile (DOSD-EC) for witness-mediated resolution of an active distress signal, and a Co-signature anchor state (pending_cosign) for instruments requiring two witnesses before publication. DOSD does not determine legal validity, jurisdiction, sovereignty, standing, or dispute outcomes. It provides discoverable publication infrastructure only. | |||||||||||||
| draft-mackay-aacp-03.txt | ||||||||||||||
| Agent Action Compression Protocol (AACP) Version 1.4 | ||||||||||||||
|
This document defines the Agent Action Compression Protocol (AACP), a typed coordination format for agent-to-agent communication in multi- agent large language model (LLM) systems. AACP transforms natural language coordination instructions into deterministic, machine- parseable packets that can be validated before transmission, logged as structured audit records, and replayed consistently across workflow runs. AACP addresses a coordination content layer that existing agent protocols do not cover. The Model Context Protocol (MCP) and Agent- to-Agent Protocol (A2A) operate at the tool access and routing layers respectively. Neither specifies what agents say to each other inside coordination messages. AACP fills this gap with a shared, typed vocabulary for agent coordination intent. For known workflow types, a rule-based encoder produces AACP packets deterministically at zero LLM cost. A four-tier fallback extends this to novel instructions: community registry lookup at zero cost; local cache lookup at zero cost; pattern matching at zero cost; LLM encoding for genuinely novel instructions, logged to registry for permanent reuse. An amortisation benchmark across 240 encoding operations demonstrated 91.6 percent cost saving versus per-call LLM encoding, with 6 LLM calls required across the full run. As a secondary benefit, AACP reduces coordination token usage by approximately 23 percent versus equivalent natural language instructions. Framework integration benchmarks demonstrate 18 percent total workflow cost reduction in LangChain (59 coordination hops) and 30 percent in CrewAI (59 coordination hops), with all coordination LLM calls eliminated in both cases. This document updates draft-mackay-aacp-02 with: framework integration results for AutoGen (55 percent total cost reduction, 59 coordination hops) and Pydantic AI (85 percent total cost reduction, 59 coordination hops); a four-framework comparison demonstrating that AACP saving scales with framework coordination verbosity; a new framing for typed-result frameworks showing that AACP completes the determinism picture by adding typed instructions to complement existing typed results; and publication of five packages on PyPI and npm covering all four frameworks. | |||||||||||||
| draft-mackey-nmop-kg-for-netops-04.txt | ||||||||||||||
| Knowledge Graph Framework for Network Operations | ||||||||||||||
|
This document describes some of the problems in modern operations and management systems and how knowledge graphs and RDF can be used to solve closed loop system, in an automatic way. 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/mike-mackey. | |||||||||||||
| draft-madhavan-aipref-displaybasedpref-02.txt | ||||||||||||||
| A Vocabulary for Controlling Usage of Content Collected by Search and AI Crawlers | ||||||||||||||
|
This document proposes a standardized vocabulary to express preferences for usage of digital content collected by Search and AI crawlers. This vocabulary allows for the creation of structured declarations about restrictions or permissions for use of content retrieved by such systems. Adding the No updates on March 24, 2026 to keep document from expiring. | |||||||||||||
| draft-madpr-green-provenance-00.txt | ||||||||||||||
| Provenance Traceability Augmentation for the GREEN Power and Energy YANG Module | ||||||||||||||
|
This document defines a YANG module that augments the GREEN Power and Energy YANG Module [PowerAndEnergy] to record the result of provenance verification for each Energy Object. The augmentation builds on the COSE-based signing mechanism defined in [ProvenanceDraft]. For each Energy Object, it records whether the most recent provenance signature was valid, which key was used to sign it, and who is responsible for that key, whether the device itself, the network controller acting on its behalf, or an external authority such as a grid energy provider. This allows operators and auditors to verify not just that energy data is correct, but that it came from where it claims to have come from, and to understand the level of trust that applies to each source. | |||||||||||||
| draft-mahy-cbor-edn-for-tls-01.txt | ||||||||||||||
| Extended Diagnostic Notation (EDN) Use with Transport Layer Security (TLS) Presentation Language (PL) Objects | ||||||||||||||
|
Extended Diagnostic Notation was designed as a superset of JSON to represent CBOR instance documents in human-readable format. This document describes how it can be used to represent instances encoded using the TLS Presentation Language. | |||||||||||||
| draft-mahy-cbor-pointer-01.txt | ||||||||||||||
| CBOR Pointer: Selecting Elements of Concise Binary Object Representation (CBOR) Documents | ||||||||||||||
|
CBOR Pointer is a syntax to identify a single CBOR value from a CBOR document with an arbitrarily complex nested structure. It is analogous to JSON Pointer. | |||||||||||||
| draft-mahy-mimi-credential-preauth-00.txt | ||||||||||||||
| MIMI Preauthorization based on deep references to MLS Credentials | ||||||||||||||
|
This document describes a Work-In-Progress syntax called claim pointers that identify specific items in structured credentials, which often have nested levels of hierarchy; and claim matchers that facilitate comparisons between items in credentials and a target value. It also describes a new version of the More Instant Messaging Interoperability (MIMI) preauthorization format using claim pointers and claim matchers. | |||||||||||||
| draft-mahy-mimi-hub-retracted-messages-00.txt | ||||||||||||||
| More Instance Messaging Interoperability (MIMI): Retracting MIMI Content Messages by the Hub Provider | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) Protocol defines a way to signal potentially abusive messages to a provider, but provides no way for the provider to signal that an abusive message sent in a room should be retracted. This document defines mechanisms for providers to signal this to in-room participants. | |||||||||||||
| draft-mahy-mimi-identity-05.txt | ||||||||||||||
| More Instant Messaging Interoperability (MIMI) Identity Concepts | ||||||||||||||
|
This document explores the problem space in instant messaging (IM) identity interoperability when using end-to-end encryption, for example with the MLS (Message Layer Security) Protocol. It also describes naming schemes for different types of IM identifiers. | |||||||||||||
| draft-mahy-mimi-msgid-aad-02.txt | ||||||||||||||
| Conveying the More Instant Messaging Interoperability Message ID in Messaging Layer Security Additional Authenticated Data | ||||||||||||||
|
The More Instant Messaging Interoperability (MIMI) content format defines a MIMI Message ID, communicated only to members of the Messaging Layer Security (MLS) group in which the message was sent. This document defines a way to share a Message ID in the MLS Additional Authenticated Data (AAD) so it is visible to MIMI providers. | |||||||||||||
| draft-mahy-mls-new-content-types-01.txt | ||||||||||||||
| New Content Types for Messaging Layer Security (MLS) | ||||||||||||||
|
This Messaging Layer Security (MLS) extension adds two new variations of the application content type, each with a separate key ratchet. It also creates an MLS capability to negotiate use of the new types, and an IANA registry to register additional content types. | |||||||||||||
| draft-mahy-mls-sd-cwt-credential-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mahy-mls-semiprivatemessage-07.txt | ||||||||||||||
| Semi-Private Messages in the Messaging Layer Security (MLS) Protocol | ||||||||||||||
|
This document defines a SemiPrivateMessage for the Messaging Layer Security (MLS) protocol. It allows members to share otherwise private commits and proposals with a designated list of external receivers rather than send these handshakes in a PublicMessage. | |||||||||||||
| draft-mahy-oob-aad-00.txt | ||||||||||||||
| MLS Extension for Out-Of-Band Additional Authenticated Data | ||||||||||||||
|
This document specifies an explicit way to signal that the Additional Authenticated Data does include or should include data elements that are conveyed out-of-band (ex: are not in the MLS message). | |||||||||||||
| draft-maintainer-1f916-agent-record-01.txt | ||||||||||||||
| The Agent Record: Transparent,Witness-Countersigned Event Logs for AI Agent Identity,History,and Memory | ||||||||||||||
|
Autonomous AI agents increasingly act as economic parties: they are hired, they pay, and they make claims about their own past conduct. No deployed standard lets a relying party verify an agent's identity continuity, the integrity of its claimed history, or the intactness of its persisted memory without trusting the agent's operator or platform. This document describes the Agent Record architecture: per-agent append-only event logs bound to Ed25519 keys, checkpointed with signed Merkle tree heads following the RFC 6962 construction, countersigned by independent witnesses, and exported as portable, offline-verifiable dossiers. Memory integrity is anchored by hash commitments recorded in the log, allowing an agent's future sessions, and any third party, to detect tampering with persisted state. The architecture is deployed in production at a founding registry; this document records its wire formats and security model to invite independent implementation and review, and to align terminology with the SCITT architecture, of which this system is an application- specific instance. | |||||||||||||
| draft-makarov-gostjwa-01.txt | ||||||||||||||
| Using GOST Cryptographic Algorithms for JWT security | ||||||||||||||
|
This specification registers cryptographic algorithms and identifiers for GOST R 34.10 digital signatures and public keys, GOST R 34.11 hash functions, GOST 34.12 encryption algorithms to be used with JSON Web Signatures (JWS), JSON Web Encryption (JWE), and JSON Web Keys (JWK) specifications. | |||||||||||||
| draft-mallick-muacp-03.txt | ||||||||||||||
| The Micro Agent Communication Protocol (uACP) | ||||||||||||||
|
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. | |||||||||||||
| draft-mankamana-pim-mofrr-failure-detection-00.txt | ||||||||||||||
| MoFRR Path Liveness for Network Failures | ||||||||||||||
|
This document discusses an operational gap in Multicast-Only Fast Reroute when failures occur inside an upstream multicast path but do not cause a visible RIB or RPF change at the merge point. The document motivates the need for a scalable path-liveness mechanism that can detect such hidden multicast delivery failures without requiring expensive per-flow packet monitoring. | |||||||||||||
| draft-mankamana-pim-source-discovery-00.txt | ||||||||||||||
| PIM Source Discovery for ASM Deployments | ||||||||||||||
|
This document discusses the operational challenges of Any-Source Multicast deployments that use PIM Sparse Mode and explores whether PIM extensions can simplify source discovery and operational behavior while preserving the host-facing ASM service model. | |||||||||||||
| draft-mankamana-pim-source-fanout-trace-00.txt | ||||||||||||||
| PIM Source Fanout Trace for multicast flow | ||||||||||||||
|
Mtrace version 2 traces an IP multicast path by walking from a last- hop router or rendezvous point toward the source. That model is efficient for a single receiver path, but it does not directly answer the operational question of where a multicast source fans out downstream without issuing separate traces from many receiver-side locations. | |||||||||||||
| draft-mansouri-hexdns-00.txt | ||||||||||||||
| Hexadecimal Color-Based Domain Name Resolution (Hex-DNS) | ||||||||||||||
|
This document proposes an alternative or complementary addressing scheme for the Domain Name System (DNS). It introduces "Hex-DNS", a routing logic where traditional alphabetic domain names are replaced by visual identity markers using standard 6-character RGB Hexadecimal codes, prefixed by country codes (ISO 3166-1) and suffixed by categorical identifiers. | |||||||||||||
| draft-many-bess-rfc9252-dual-sid-00.txt | ||||||||||||||
| Dual MPLS and SRv6 Service Advertisement in the Absence of Transposition | ||||||||||||||
|
RFC 9252 defines BGP signaling procedures for SRv6 services, including the use of an MPLS Label field and transposition semantics. However, when transposition is not used (i.e., TL = 0), RFC 9252 does not explicitly define the interpretation of the MPLS Label field, leading to ambiguity in control-plane signaling. This document specifies a minimal, backward-compatible extension to RFC 9252 that enables a single route to unambiguously advertise both a valid MPLS Service Label and an SRv6 Service SID. The extension relies on existing MPLS label semantics, without introducing new TLVs, attributes, or changes to the base encoding format. | |||||||||||||
| draft-many-lsr-isis-packet-timestamping-00.txt | ||||||||||||||
| IS-IS Packet Timestamping | ||||||||||||||
|
Many applications in today’s networks rely on reliable and timely flooding of link-state information, such as, but not limited to Traffic Engineered networks. If such link-state information is delayed it can be difficult for those applications to adequately fulfill their intended functionality. This document describes extensions to ISIS supporting distribution of fragment origination time. The origination time can be used to aid troubleshooting and/or by the applications themselves to improve their behavior. Timestamping can be also used to detect replay attack which are not addressed in IS-IS currently. | |||||||||||||
| draft-many-lsr-power-group-03.txt | ||||||||||||||
| Using IS-IS To Advertise Power Group Membership | ||||||||||||||
|
Many networks have a daily utilization pattern. For example, a network might be busy during the day and less busy at night. If the network is robust, it has enough capacity to satisfy demand during peak hours and excess capacity during non-peak hours. That excess capacity increases energy costs and environmental impact. [I-D.many-teas-power-steering] introduces a Power Conserving Path Placement Strategy (PCPPS). When possible, PCPPS concentrates traffic onto a small set of network resources. When traffic is concentrated onto a small set of network resources, other network resources become idle and can be powered down until they are needed again. This solves the problem of excess capacity during non-peak hours. PCPPS uses information that is distributed by an IGP. This document specifies the IS-IS encoding for that information. | |||||||||||||
| draft-many-pce-stateful-amendment-04.txt | ||||||||||||||
| Amendments to Stateful PCE Communication Protocol (PCEP) | ||||||||||||||
|
This document updates RFC8231, RFC8664 and RFC8281 to reflect operationalized implementations and defines optimizations in the PCEP protocol. | |||||||||||||
| draft-many-seat-architecture-00.txt | ||||||||||||||
| Secure Evidence and Attestation Transport (SEAT) Architecture | ||||||||||||||
|
This document defines an architectural framework for composing Remote ATtestation procedureS (RATS) with Secure Evidence and Attestation Transport (SEAT). The document establishes normalized terminology for SEAT, aligns RATS roles to transport endpoints, outlines topological patterns for attestation delivery timing, characterizes the abstract cryptographic pattern by which Evidence is bound to a given transport connection. | |||||||||||||
| draft-many-teas-power-steering-02.txt | ||||||||||||||
| A Power Conserving Path Placement Strategy (PCPPS) | ||||||||||||||
|
This document introduces a Power Conserving Path Placement Strategy (PCPPS). During periods of low demand, PCPPS concentrates traffic onto a small set of network resources. This causes other network resources to become idle or nearly idle. When demand increases, PCPPS redistributes traffic as required. | |||||||||||||
| draft-many-tiptop-dns-02.txt | ||||||||||||||
| Deployment and Use of the Domain Name System(DNS) in Deep Space | ||||||||||||||
|
Deep space communications involve long delays (e.g., Earth to Mars has one-way delays 4-24 minutes) and intermittent communications, mainly because of orbital dynamics. This document lists operational methods to enable local DNS name resolving on celestial body networks such that there are no real-time query and response flow to the authoritative name servers on (Earth) Internet. | |||||||||||||
| draft-many-tiptop-email-02.txt | ||||||||||||||
| Deploying and Using Email in Deep Space | ||||||||||||||
|
This document is an assessment on the email protocols to be used in deep space and provides recommendations to deploy and use email in deep space. | |||||||||||||
| draft-mapmw-task-discovery-01.txt | ||||||||||||||
| Task discovery in agentic networks | ||||||||||||||
|
This document defines an architectural framework for an open, interoperable ecosystem in which task owners publish tasks—represented as structured task cards—to a task-posting platform, enabling autonomous agents to discover tasks, negotiate execution terms, and coordinate multi-agent collaboration. The architecture introduces a set of functional layers—including the Task Owner Layer, Task Owner Access Layer, Task-Posting Platform, Agentic Layer, Agent Access Layer, and an optional Communication Link—that collectively support secure task publication, agent discovery, capability evaluation, and bilateral negotiation. The framework is designed to accommodate heterogeneous agents with diverse skill sets, trust requirements, and operational models, while ensuring consistent interaction patterns across platforms and vendors. The document also surveys existing agent-discovery approaches, such as A2A, agntcy/OASF, ARDP, and DNS-AID, and identifies gaps that motivate a unified, interoperable model for task-centric and agent-initiated discovery and interaction. It also explores possible ways by which the current approached can enhance the proposed framework. The goal of this architecture is not to replace existing mechanisms but to provide a complementary framework that enables agent–task interactions in scenarios that are difficult to support using traditional agent-to-agent or platform-centric interaction models. The document is concluded with some potential standardization venues for the IETF. | |||||||||||||
| draft-marenamat-grow-route-server-nh-translation-02.txt | ||||||||||||||
| Route Server Next Hop Translation | ||||||||||||||
|
With the advent of RFC8950, Internet Exchange Points (IXPs) are enabled to rely solely on IPv6 addresses for adressing in their peering LANs. However, routers not supporting RFC8950 are a technical roadblock. It is easier to extend the capabilities of the IXP Route Server (RS) instead of those of every unsupporting router. Thus, this document introduces the concept of Specific Local Address Tables (SLATs). SLATs translate BGP next hops between all IXP members, regardless of their RFC8950 support, paving the way for IPv6-only IXPs. This document also introduces another, more transparent variant of BGP next hop translation applicable in IXPs which do not employ ARP and ND proxying. This document updates RFC 7947 by specifying an allowed route modification at the route server. | |||||||||||||
| draft-marenamat-idr-bgp-attribute-formatting-01.txt | ||||||||||||||
| Canonical textual representation of BGP Path Attributes | ||||||||||||||
|
Various implementations of the Border Gateway Protocol (BGP) use different formats for displaying the Path Attributes. This document defines the preferred textual formatting which is recommended for the implementations to use for human interfaces. To achieve consistent value formatting, this document formally updates RFC 9026 by canonicalizing the well-known community name formats. This document updates RFC 4360, RFC 4577, RFC 7432, and ... by specifying the canonical textual formatting of extended communities specified there. This document updates RFC 4940 by adding a textual tag column to the OSPFv2 Link State Type registry. This document updates RFC 7153 by adding a textual tag column to the extended community registry. (REMOVE THIS) This document is incomplete and needs completing the tables. | |||||||||||||
| draft-marques-asqav-compliance-receipts-08.txt | ||||||||||||||
| Compliance Profile of Signed Action Receipts for AI Agents | ||||||||||||||
|
This document defines a multi-jurisdiction compliance profile of the signed action receipt format used by AI agents to record machine- readable evidence of access-control decisions. The profile binds receipt fields to two regulatory surfaces: on the European Union side, Articles 12 and 26 of the EU AI Act (Regulation (EU) 2024/1689) and Article 17 of DORA (Regulation (EU) 2022/2554); on the United States side, the NIST AI Risk Management Framework, the Colorado AI Act, the Texas Responsible AI Governance Act, the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500), the HIPAA Security Rule, SEC Rule 17a-4, and the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). Working entirely within the existing wire format, canonicalization transformation, and signing algorithms of the underlying receipt format, the profile tightens a subset of the OPTIONAL fields to REQUIRED, imposes a retention floor, and requires at least one timestamping anchor (RFC 3161 or OpenTimestamps). It registers OPTIONAL extension fields for risk and incident classification, cross-agent envelope binding, per-action validity-window and integrity, build provenance, threat-framework taxonomy, server-built enforcement-control records, producer-asserted risk acceptance, and producer-asserted code authorship, each subject to false-attestation guards where applicable, and registers receipt type namespaces for passive-telemetry, result-bound observation, risk-acceptance, and code-authorship receipts. Revision -08 additionally defines an attestation statement envelope (a Dead Simple Signing Envelope (DSSE) Pre-Authentication Encoding wrapping an in-toto Statement v1 under an asqav predicate namespace) with two tiers: a voluntary observation attestation that signs a caller-supplied digest and is explicitly not a capture, and an authoritative attestation whose subject digest the issuing platform re-derives from independent evidence (for code, the SHA-256 of the raw unified diff re-fetched from the source host); revision -08 further defines the capture-layer integrity, independent verification protocol, honest-tiering, and service-identity and revocation rules that govern those attestation statements, and documents the shipped keyed-digest wire tokens and the verifier verdict vocabulary (verified, verified_keyed, unverified). The full field set and its normative requirements are defined in the body of this document. | |||||||||||||
| draft-marstein-satp-asset-exchange-01.txt | ||||||||||||||
| Secure Asset Exchange Protocol | ||||||||||||||
|
This document describes the Secure Asset Exchange (SAE) Protocol. SAE is an extension of the Secure Asset Transfer (SAT) Protocol that enables the asset exchange interoperability mode. It specifies the required modifications necessary to the SAT message flows to facilitate asset exchange between asset networks. Gateways that support the SAT protocol can be extended to also support SAE, enabling support for both asset transfer and asset exchange in a single set of gateways. | |||||||||||||
| draft-martin-deploying-ipv6-data-center-02.txt | ||||||||||||||
| Deploying IPv6 in Data Centers | ||||||||||||||
|
Data center operators are moving toward IPv6-only operation to simplify addressing, restore end-to-end connectivity, and meet operator and government timelines. Much published IPv6 guidance targets network engineers; this document instead addresses *Site Reliability Engineers (SREs)* and *Software Engineers (SWEs)* who deploy, operate, and debug services in *operator-owned data centers*. It is organized in two parts after IPv6 fundamentals: a *migration program* (transition strategy and observability) and a *technical stack* (hardware, provisioning, transport, applications, and diagnostics). It documents common software and infrastructure gaps and offers practical deployment patterns aligned with the IPv6 Operations (v6ops) working group charter. | |||||||||||||
| draft-martin-ipv6-addr-selection-updates-00.txt | ||||||||||||||
| Updates to IPv6 Default Address Selection | ||||||||||||||
|
This document updates RFC 6724 with three improvements to IPv6 destination address selection. The updates allow recent IPv6 connection or service failures to influence IPv6/IPv4 ordering, incorporate likely source/destination address pairs when sorting candidates, and let ISP and enterprise operators preserve DNS load- balancing order where Rule 9 would otherwise override it. The updates are intended to be implementable inside getaddrinfo() or an equivalent system mechanism, without requiring changes to existing application-facing socket APIs. | |||||||||||||
| draft-martin-retry-over-ipv6-04.txt | ||||||||||||||
| HTTP Signaling of Planned IPv4 Unavailability | ||||||||||||||
|
As operators transition services to IPv6-only, planned IPv4 outages help identify remaining dependencies before permanent decommission. Such outages must be measurable, reversible, and understandable to end users. This document defines HTTP signaling for an intentional, often time-bounded IPv4 outage: the existing 503 Service Unavailable status code together with the mandatory Retry-Over-IPv6 response header field (and optional related fields) that instruct aware clients to retry over IPv6 after closing the IPv4 connection, and allow clients to confirm successful IPv6 recovery via an optional correlation token so operators can distinguish soft failures from hard failures in centralized logs. Machine-readable response bodies MAY use Problem Details (RFC 9457) with a registered problem type URI. The mechanism supports staged enterprise rollouts, internal HTTP services, and permanent IPv6-only migration; coordinated public events (for example, 6/6 drills) remain possible with advance notice. The primary intended deployment is operator-controlled environments where provider and users share operational responsibility. Legacy clients that do not implement this specification treat the response as ordinary service unavailability and MAY use the response body for human-readable guidance. | |||||||||||||
| draft-martinalli-open-purchase-receipts-00.txt | ||||||||||||||
| attest: Portable,Offline-Verifiable Digital Purchase Receipts | ||||||||||||||
|
This document specifies attest, a signed digital purchase-receipt envelope that a buyer holds and that any party can verify offline, without contacting the issuer or any third-party service. It defines the receipt envelope and payload format, a restricted JSON canonicalization profile ("attest-JCS", built on RFC 8785), a pinned Ed25519 signature ruleset, an optional hybrid Ed25519+ML-DSA-65 post- quantum-resistant signature profile, issuer key and artifact manifests with rotation and compromise handling, a layered verification algorithm, and revocation-record semantics. This document is a snapshot profile: it distills, and never supersedes, the living attest specification maintained in the attest source repository. It normatively specifies exactly the core receipt format and the hybrid signature profile; the living specification's transparency-log, anchoring, and issuer-mediated transfer material is summarized only as non-normative pointers in Section 12 of this document. | |||||||||||||
| draft-martinez-partial-content-uploads-00.txt | ||||||||||||||
| Partial Content Uploads in HTTP | ||||||||||||||
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines partial content uploads, which allows a client to upload content, such as a large file, via multiple requests. This document also outlines the metadata header fields for indicating state changes, request header fields for making preconditions on such state, and the rules for constructing the responses. | |||||||||||||
| draft-mashayekhi-auditable-model-deliberation-00.txt | ||||||||||||||
| Auditable Public Artifacts for Model-Independent Deliberation | ||||||||||||||
|
Heterogeneous artificial-intelligence systems can exchange messages without sharing stable semantics for claims, evidence, objections, revisions, decisions, failures, and termination. This document defines an experimental public-artifact protocol for model- independent deliberation. It separates interoperable public state from private model computation and does not require disclosure of chain-of-thought, hidden state, prompts, model weights, or private memory. The document defines seven public artifact types, append-only revision, evidence provenance, blocking-objection closure, explicit failure and termination, a restricted canonical JSON profile, and SHA-256-based artifact identifiers. It does not define transport, signatures, authorization, model execution, or a completed consensus system. | |||||||||||||
| draft-matolin-global-nat64-anycast-00.txt | ||||||||||||||
| Global Anycast NAT64 Well-Known Prefix | ||||||||||||||
|
This document defines a globally routable, anycast NAT64 service using the IPv6 prefix 2600:6464::/96 as a standardized translation substrate for IPv6-to-IPv4 connectivity. The goal of this specification is to eliminate per-network NAT64 configuration complexity by introducing a single globally consistent NAT64 translation prefix operated as a distributed anycast service by participating Internet Service Providers, cloud providers, and content delivery networks. The model assumes an IPv6-only client environment with mandatory IPv4 reachability via NAT64 translation. IPv4-only services remain reachable without modification. IPv4 is not modified. IPv6 is not modified. Only translation placement and routing semantics are standardized. This document defines: * A globally shared NAT64 prefix (2600:6464::/96) * Anycast-based NAT64 edge behavior * Stateless IPv6-to-IPv4 synthesis rules * Optional reverse mapping constraints (IPv4->IPv6 blocked) * Operational requirements for participating networks | |||||||||||||
| draft-matsuhira-m46a-20.txt | ||||||||||||||
| Multiple IPv4 - IPv6 mapped IPv6 address (M46A) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 mapped IPv6 address(M46A) spefification. M46A is an IPv4-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables IPv4 private address unique in IPv6 address space. This address may use IPv4 over IPv6 encapsulation and IPv4 - IPv6 translation. | |||||||||||||
| draft-matsuhira-m46e-fp-20.txt | ||||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes backbone network to IPv6 only. And also, M46E-FP can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. | |||||||||||||
| draft-matsuhira-m46e-pr-20.txt | ||||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution (M46E-PR) | ||||||||||||||
|
This document specifies M46E Prefix Resolution (M46E-PR) specification. M46E-PR connect IPv4 stub networks between IPv6 backbone network. And also, M46E-PR can stack many IPv4 networks, i.e. the nwtworks using same IPv4 private addresses without interdependence. | |||||||||||||
| draft-matsuhira-m46e-pt-20.txt | ||||||||||||||
| Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator (M46E-PT) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 mapping encapsulation - Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4 network plane by connecting M46E-FP domain and M46E-PR domain. M46E- PT translate prefix part of M46E-FP address and M46E-PR address both are IPv6 address. M46E-PT does not translate IPv4 packet which is encapsulated, so transparency of IPv4 packet is not broken. | |||||||||||||
| draft-matsuhira-m46t-20.txt | ||||||||||||||
| Multiple IPv4 - IPv6 address mapping translator (M46T) | ||||||||||||||
|
This document specifies Multiple IPv4 - IPv6 address mapping Translator (M46T) specification. M46T enable access to IPv4 only host from IPv6 host. IPv4 host is identified as M46 address in IPv6 address space. The address assigned to IPv4 host may be global IPv4 address or private IPv4 address. M46T does not support access to IPv6 host from IPv4 only host. | |||||||||||||
| draft-matsuhira-me6a-20.txt | ||||||||||||||
| Multiple Ethernet - IPv6 mapped IPv6 address (ME6A) | ||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 mapped IPv6 address(ME6A) spefification. ME6A is an Ethernet-mapped IPv6 address with a plane ID. Unique allocation of plane id value enables duplicated MAC address unique in IPv6 address space. This address may use Ethernet over IPv6 encapsulation. | |||||||||||||
| draft-matsuhira-me6e-fp-21.txt | ||||||||||||||
| Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix | ||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-FP can stack multiple Ethernet networks. ME6E-FP work on own routing domain. | |||||||||||||
| draft-matsuhira-me6e-pr-21.txt | ||||||||||||||
| Multiple Ethernet - IPv6 address mapping encapsulation - prefix resolution | ||||||||||||||
|
This document specifies Multiple Ethernet - IPv6 address mapping encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR makes expantion ethernet network over IPv6 backbone network with encapsuation technoogy. And also, E6ME-PR can stack multiple Ethernet networks. ME6E-PR work on non own routing domain. | |||||||||||||
| draft-matsuhira-mslb-20.txt | ||||||||||||||
| Multi-Stage Transparent Server Load Balancing | ||||||||||||||
|
This document specifies Multi-Stage Transparent Server Load Balancing (MSLB) specification. MSLB makes server load balancing over Layer3 network without packet header change at client and server. MSLB makes server load balancing with any protocol and protocol with encryption such as IPsec ESP, SSL/TLS. | |||||||||||||
| draft-matsuhira-oht-05.txt | ||||||||||||||
| Outer Header Translator | ||||||||||||||
|
Network address translation technology has a convenient aspect, however, it has the side effect of breaking end-to-end transparency. This document proposes a technology that achieves both network address translation and end-to-end transparency. This technology may provide solutions for mobility, migration, multihoming, policy routing, etc. | |||||||||||||
| draft-matsuhira-oht-mh-03.txt | ||||||||||||||
| Outer Header Translator - multihoming | ||||||||||||||
|
This document describes how to achieve multihoming using OHT. This document describes both the use of provider addresses and provider independent addresses. | |||||||||||||
| draft-matsuhira-pia-03.txt | ||||||||||||||
| Provider Independent Addresses Aggregation | ||||||||||||||
|
This document proposes a discussion on whether PI address aggregation. More research, reviews, and discussions will be add in the future. | |||||||||||||
| draft-matsukami-intarea-ipv45-00.txt | ||||||||||||||
| IPv4.5: A Locator/Identifier-Separated Extension to IPv4 with Post-Quantum Session Security | ||||||||||||||
|
The global IPv4 address space was exhausted at the IANA level in 2011, and Carrier-Grade NAT (CGN) has since served as the primary operational workaround. CGN preserves connectivity but violates the end-to-end principle, complicates application development, and introduces substantial operational overhead. This document specifies IPv4.5, a pragmatic extension of IPv4 that introduces a 96-bit address space organized as a Locator/Identifier separation: a 32-bit IPv4 Locator, a 16-bit Site Identifier, and a 48-bit Endpoint Identifier. IPv4.5 packets are encapsulated in UDP (port 4242) for transparent transit through existing IPv4 routers, NAT devices, and firewalls without requiring infrastructure changes. Session security is established through a hybrid post-quantum key exchange combining ML-KEM-768 [FIPS203] and X25519 [RFC7748], performed once per session. Subsequent data protection uses symmetric AEAD ciphers (AES-256-GCM or ChaCha20-Poly1305). The design enforces strict separation of concerns across four independent planes: data, control, identity, and cryptographic. Higher-level functions such as semantic routing and self-sovereign identity are explicitly out of scope for this specification. | |||||||||||||
| draft-mattsson-cfrg-aes-gcm-sst-21.txt | ||||||||||||||
| Galois Counter Mode with Strong Secure Tags (GCM-SST) | ||||||||||||||
|
This document defines Galois Counter Mode with Strong Secure Tags (GCM-SST), an Authenticated Encryption with Associated Data (AEAD) algorithm that addresses several weaknesses of GCM. GCM-SST can be used with any keystream generator, not only 128-bit block ciphers. Main differences from GCM are the introduction of a second authentication subkey H_2, per-nonce derivation of both H and H_2, and stricter usage limits. Together, these changes yield authentication tags with near-ideal forgery probabilities, including reforgeability resistance. All registered instances have an expected number of forgeries E(F) ≈ v / 2^t, a property that GCM is far from providing. GCM-SST is designed for security protocols with replay protection such as TLS, QUIC, SRTP, and PDCP, and provides hardware and software performance comparable to GCM. This document registers nine AEAD algorithm instances using AES and Rijndael-256 in counter mode, with tag lengths of 48, 96, and 112 bits. GCM-SST has been standardized by 3GPP for use with SNOW 5G, AES-256, and ZUC-256. | |||||||||||||
| draft-maurette-hmtftp-06.txt | ||||||||||||||
| HMTFTP: HKDF-Derived TFTP with Optional AEAD Protection (v0.7) | ||||||||||||||
|
HMTFTP is a lightweight UDP file transfer protocol derived from TFTP. It preserves the TFTP transfer model (RRQ/WRQ, DATA, ACK, ERROR, and OACK option acknowledgment) and replaces text options with binary TLVs. HMTFTP defines optional AEAD protection for DATA payloads using HKDF-derived keys from a pre-shared key (PSK). This document describes transfer behavior, extension processing rules, key derivation, nonce construction, and operational guidance for experimental implementations intended to facilitate interoperability. This document requests IANA actions for a UDP service name/port and registries for TLV Types and Ciphersuites. Until assignment, TBD1 is used as the default UDP port value. | |||||||||||||
| draft-mayankpanke-event-delivery-semantics-01.txt | ||||||||||||||
| Event and Webhook Delivery Semantics | ||||||||||||||
|
Event- and webhook-based integrations are a common application-layer mechanism for interoperability across Internet services, yet they lack a shared delivery semantics contract. Existing implementations vary widely in retry behavior, acknowledgment signaling, failure classification, idempotency identifiers, and replay handling, resulting in fragile integrations and ambiguous operational expectations. This document defines a minimal, application-layer delivery semantics profile for event and webhook delivery over existing transports, and specifies a concrete binding for the Hypertext Transfer Protocol (HTTP). The profile constrains only sender-observable behavior and signaling; it does not impose receiver-side storage or processing requirements and does not redefine existing transport protocols. | |||||||||||||
| draft-mayer-ioam-gob-01.txt | ||||||||||||||
| Global Opaque Block for IOAM Pre-allocated Trace Option | ||||||||||||||
|
Extensible metadata carried within the IOAM Pre-allocated Trace Option (PTO) can support packet-level, flow-level, or path-level processing beyond per-node trace data. This document defines the Global Opaque Block (GOB), an extension to the IOAM PTO that introduces a single pre-allocated global metadata region placed between the PTO fixed header and the node data list. The GOB carries an explicit length and schema identifier, preserves the pre-allocated PTO processing model, and can be used to transport Extensible In-band Processing (EIP) Information Elements or other structured metadata formats. | |||||||||||||
| draft-mazilu-tcpm-packet-trimming-00.txt | ||||||||||||||
| TCP Packet Trimming Extension | ||||||||||||||
|
This document specifies a TCP extension that enables TCP endpoints in data center networks or similarly controlled administrative domains to use packet trimming information when it is available. When switch buffers exceed a threshold, rather than silently dropping a packet, the switch trims the payload and forwards the header. This allows the destination to issue a deterministic Negative Acknowledgment (NACK), enabling faster, more deterministic loss recovery. | |||||||||||||
| draft-mbci-ippm-ioam-template-option-03.txt | ||||||||||||||
| In Situ Operations,Administration,and Maintenance (IOAM) Template Option | ||||||||||||||
|
In situ measurement is performed by incorporating performance related information into in-flight data packets. This document specifies a new IOAM Option-Type that has a fixed length and can be updated by transit nodes along the path. It enables lightweight monitoring while maintaining a constant length that is not changed in-flight and is not affected by the number of hops in the network. | |||||||||||||
| draft-mcbride-mcast4ai-p2mp-mechanism-evaluation-00.txt | ||||||||||||||
| AI P2MP Mechanism Evaluation | ||||||||||||||
|
AI workloads in data centers exhibit inherently point-to-multipoint (P2MP) communication patterns. During distributed training, collective operations such as AllReduce, AllGather and Broadcast require identical data delivery to many receivers. During inference serving, P2MP patterns also arise from mechanisms such as KV-cache distribution in disaggregated serving architectures and speculative- decoding verifier fan-out. Unicast replication of these flows does not scale to large GPU clusters. This document evaluates two architectural mechanisms for addressing this problem: extending BIER (Bit Index Explicit Replication) to support AI P2MP requirements, or defining a new purpose-built protocol. The evaluation is grounded in the transport-layer requirements this P2MP communication pattern places on a multicast solution, i.e., the requirements imposed by RDMA and RoCEv2 semantics rather than by the choice of network-layer replication mechanism, including considerations around ACK aggregation, congestion control, RoCE/RDMA compatibility and operational complexity. This document does not define a protocol but is intended instead to help the mcast4ai community evaluate this problem space. | |||||||||||||
| draft-mcconnell-software-status-wellknown-02.txt | ||||||||||||||
| A Well-Known URI for Software Lifecycle Status | ||||||||||||||
|
This document defines a Well-Known URI [RFC8615] at which software vendors and open-source maintainers may publish machine-readable lifecycle status information for their products. A JSON resource retrieved from /.well-known/software-status.json allows consumers — including security tools, software composition analysis (SCA) platforms, vulnerability scanners, and system administrators — to programmatically determine whether a specific version of a software product is actively supported, in long-term support (LTS), under security-only maintenance, or at end-of-life (EOL). This revision (-02) extends the schema to support multi-product vendors — organizations that ship multiple distinct products or SKUs under a single domain. A new optional products array at the root of the resource allows a single software-status.json endpoint to serve lifecycle declarations for an entire product catalog, including firmware-based devices such as routers, switches, and IoT appliances. This extension is fully backward compatible: existing single-product resources require no modification. This document also describes, in Appendix B (#appendix-b), a companion convention for open-source projects hosted on version- control platforms to publish equivalent information within the repository at .github/software-status.json. | |||||||||||||
| draft-mccormack-ztip-00.txt | ||||||||||||||
| The Zero Trust Intelligence Protocol (ZTIP): Governed,Independently Verified AI Agent Transactions | ||||||||||||||
|
The Zero Trust Intelligence Protocol (ZTIP) is an open, transport- neutral protocol for governed AI agent transactions. It defines five immutable JSON envelope types and a transaction lifecycle under which every agent-initiated action is authorized by policy before execution, integrity-protected by hash over a canonical form, and -- distinctively -- verified as complete by an authority independent of the actor that performed the work. An executor's claim of success is treated as attestation, and attestation alone never satisfies a required verification check. This document describes ZTIP version 1.0-draft for the record; the full specification, JSON Schemas, examples, and a reference runtime are maintained in the open at the repository referenced herein. | |||||||||||||
| draft-mcgraw-httpapi-agent-budget-04.txt | ||||||||||||||
| The Delegation HTTP Authentication Scheme for Request-Bound Authority | ||||||||||||||
|
Delegated software requesters increasingly make HTTP requests that spend, consume, disclose, mutate, invoke, or actuate on behalf of human or organizational principals. Existing HTTP authentication mechanisms indicate whether a requester holds a credential. RateLimit fields communicate server-advertised quota and current service-limit information. HTTP Message Signatures can protect selected components of an HTTP message. None of these mechanisms directly defines a common origin-server challenge for a requester to present verifiable, bounded authority from its principal before the server performs protected processing. This document defines the "Delegation" HTTP authentication scheme, response semantics for delegated-authority challenges using existing HTTP status codes and Problem Details, the Delegation-Proof HTTP field, and a COSE/CBOR proof carriage model for request-bound delegated authority. The initial authority profile is the Budget profile, which uses a CBOR/COSE Budget-Attestation envelope to prove bounded authority to spend, consume metered service units, or commit bounded resources. The mechanism is algorithm-agile; the initial cose-ml-dsa proof profile uses existing JOSE and COSE serializations for ML-DSA, with ML-DSA-65 as the baseline algorithm and ML-DSA-87 available as a high-assurance deployment policy option. A dedicated 4NN Delegated Authority Required status code remains an open design question for HTTP Working Group review; this revision does not depend on that status code and does not define payment semantics. This revision also defines a mandatory-to-implement preflight flow for large proof profiles so that GET and HEAD requests do not depend on request content, and so that requests with application representations do not need to multiplex the application body and the proof body in a single content stream. For implementation experience, this individual draft also includes the initial Budget authority profile. The HTTP authentication scheme, status-code semantics, Problem Details members, and field- carriage rules are intentionally separable from the COSE/CBOR Budget profile. If a Working Group chooses to progress the HTTP mechanism independently, the Budget authority profile can be moved to a companion profile document without changing the Delegation challenge semantics defined here. | |||||||||||||
| draft-mcguinness-oauth-actor-profile-00.txt | ||||||||||||||
| OAuth Actor Profile for Delegation | ||||||||||||||
|
OAuth deployments increasingly involve agents and workloads acting on behalf of human users across organizational boundaries. Existing specifications provide relevant building blocks (notably the act claim from RFC 8693 Token Exchange) but do not define a consistent profile for representing delegated actor relationships across JWT assertion grants (RFC 7523), JWT access tokens (RFC 9068), and Transaction Tokens, nor for classifying actor entity types or signaling support between authorization servers and resource servers. The result is inconsistent actor representation and actor- representation interoperability gaps that force deployments to rely on proprietary conventions. This document defines the OAuth Actor Profile for Delegation. It specifies a common act claim structure extended with sub_profile for entity-type classification, processing rules for authorization servers and resource servers across the three token families and their Token Exchange inputs, and OAuth discovery metadata parameters for advertising actor-profile support. The profile applies uniformly across token types and integrates with existing sender-constraint mechanisms (DPoP, mTLS). It does not standardize the policies by which systems determine whether a given actor is permitted to act for a subject; those decisions remain deployment-specific. | |||||||||||||
| draft-mcguinness-oauth-actor-proofs-00.txt | ||||||||||||||
| OAuth Actor-Signed Hop Proofs | ||||||||||||||
|
This document defines OAuth Actor-Signed Hop Proofs, an optional companion profile for delegated OAuth tokens that conform to the OAuth Actor Profile for Delegation. It introduces the actor_proofs claim, a signed per-hop proof chain in which the actor added at each visible hop signs its own participation and the target binding it authorized for that hop. Proofs are linked into a hash chain, are validated against actor verification keys resolved through pre- established trust, and optionally cross-reference sibling actor receipts. This document also defines a token request parameter for conveying proofs at issuance, and metadata and introspection parameters for advertising and consuming actor-proof support. | |||||||||||||
| draft-mcguinness-oauth-actor-receipts-00.txt | ||||||||||||||
| OAuth Actor Receipts for Delegation Provenance | ||||||||||||||
|
This document defines OAuth Actor Receipts, an optional companion provenance profile for delegated OAuth tokens that conform to the OAuth Actor Profile for Delegation. It introduces the actor_receipts claim, a signed per-hop receipt chain that records which issuer added each visible actor hop, optionally preserves the historical top-level cnf value associated with that hop subject to deployment disclosure policy, and links receipts together so recipients can validate prior- hop provenance without relying solely on the current outer token issuer. This document also defines metadata and introspection parameters for advertising and consuming actor-receipt support. | |||||||||||||
| draft-mcguinness-oauth-ai-agent-instance-00.txt | ||||||||||||||
| OAuth 2.0 AI Agent Instance Profile | ||||||||||||||
|
This specification profiles the OAuth 2.0 Client Instance Assertion for AI agent deployments, where a single OAuth client identifier represents an agent platform running many concurrent agent instances. It defines claims that convey an attested agent instance identifier and agent provenance (platform, model, runtime environment) from an agent attester to the authorization server, rules for surfacing that identity in issued access tokens, and delegation-chain semantics for agents that spawn sub-agents. The claims are carrier-independent: they may be conveyed in a Client Instance Assertion or in a Client Attestation defined by OAuth 2.0 Attestation-Based Client Authentication. | |||||||||||||
| draft-mcguinness-oauth-client-instance-assertion-01.txt | ||||||||||||||
| OAuth 2.0 Client Instance Assertion | ||||||||||||||
|
This specification defines the Client Instance Assertion: a signed JWT identifying a concrete runtime instance of an OAuth 2.0 client. It registers the client_instance_assertion request parameter for carrying the assertion at the OAuth 2.0 token endpoint on the authorization_code, client_credentials, refresh_token, and JWT bearer (RFC 7523) grants; on the token-exchange grant (RFC 8693), the same assertion is presented as actor_token with actor_token_type set to urn:ietf:params:oauth:token-type:client-instance-jwt, also registered by this specification. This specification does not introduce a new client_instance identifier in protocol messages. Instead, it defines client metadata parameters (applicable to clients identified by a Client ID Metadata Document (CIMD) or registered via OAuth Dynamic Client Registration (RFC 7591)) that let a client_id identify a logical client whose concrete runtime instances are authenticated by one or more trusted instance issuers (for example, workload identity systems). The Authorization Server validates the instance assertion and represents the instance either as an act claim, when another principal is present (e.g., a user delegating to the instance), or as the access token's sub, when the instance itself is the principal (e.g., a client credentials grant). The issued access token is sender-constrained to a key the instance possesses. | |||||||||||||
| draft-mcguinness-oauth-domain-authorized-issuer-00.txt | ||||||||||||||
| OAuth Domain-Authorized Issuer Trust Method | ||||||||||||||
|
This document defines the Domain-Authorized Issuer (DAI) Trust Method: a subject_namespace_authorization Trust Method for the OAuth Identity Assertion Trust Framework in which the owner of a subject namespace (typically a DNS domain) publishes a policy listing the OAuth authorization servers it authorizes to assert identities in that namespace. The mechanism uses the DNS-based authority- publication pattern operators already deploy for CAA, MTA-STS, SPF, and DKIM. A Resource Authorization Server uses the published policy to verify that an identity assertion's issuer is authorized for the asserted subject namespace. The lookup defined by this document is verifier-side: given an identity assertion in hand, the Resource Authorization Server locates the Subject Authority's issuer authorization policy. Client-side discovery of which Assertion Issuer to use before an assertion exists is a separate use case and is deferred to future work. This document also defines the Issuer Authorization Policy wire format that the Trust Method consumes. The parent trust framework specification owns the generic Trust Policy document, Trust Method category structure, cross-category combination rule, and Subject Authority Determination concept. | |||||||||||||
| draft-mcguinness-oauth-id-assertion-framework-00.txt | ||||||||||||||
| OAuth Identity Assertion Trust Framework | ||||||||||||||
|
Issuer authentication alone does not prove an OAuth authorization server's authority over the subject namespace its identity assertions claim. A federated authorization server can mint an identity assertion naming any email domain; federation membership establishes that the server is a recognized member of an ecosystem, not that the server is entitled to assert about subjects in any particular namespace. Nothing in OAuth today lets a namespace owner declare which authorization servers are authorized to assert identities in its namespace. This document defines an Identity Assertion Trust Framework with two parts. First, an Authority Delegation Model: an abstract pattern (Authority Holder, Delegate, Delegation Artifact, Validator) with independent trust-evaluation categories, a cross-category combination rule, and a lookup-state taxonomy that profiles instantiate. Second, the Identity Assertion Issuer Trust Policy: a JSON policy document that a Resource Authorization Server publishes to declare which trust methods it requires of an Assertion Issuer, including issuer- authentication methods (such as OpenID Federation) and subject- namespace authorization methods defined by separate profiles. The Domain-Authorized Issuer Trust Method is defined separately as one subject-namespace authorization profile usable by this framework. | |||||||||||||
| draft-mcguinness-oauth-id-continuation-assertion-02.txt | ||||||||||||||
| Identity Continuation Assertion for OAuth 2.0 Token Exchange | ||||||||||||||
|
This document defines the Identity Continuation Assertion, a short- lived, sender-constrained JSON Web Token (JWT) used as an OAuth 2.0 Token Exchange subject token. It enables a workload acting on a user's behalf to obtain an Identity Assertion JWT Authorization Grant (ID-JAG) for another service when it lacks a suitable credential, including when the user is no longer present. A trusted issuer attests that a resource authorization server accepted an earlier ID-JAG and that the resulting authorization remains active and eligible for continuation. The workload exchanges this assertion at the identity provider, which evaluates the requested access under the chain authorization and current policy before issuing an onward ID-JAG. The profile supports multi-hop access across resource authorization servers that trust a common identity provider. | |||||||||||||
| draft-mcguinness-oauth-insufficient-claims-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mcguinness-oauth-mission-00.txt | ||||||||||||||
| Mission-Bound Authorization for OAuth 2.0 | ||||||||||||||
|
An AI agent is typically given a mission: a task to pursue on a user's behalf. OAuth 2.0 issues access tokens for individual resource requests, but it has no durable, approved artifact that ties those tokens to the one task a user actually authorized. As a result, an agent's authority is a collection of independently obtained tokens with no shared, auditable boundary, and a user's approval is disconnected from what the agent later does. This document defines a Mission: a structured, human-approved, integrity-bound authorization artifact for OAuth 2.0. A client submits a Mission Intent through Pushed Authorization Requests; the Authorization Server derives Rich Authorization Requests authorization details from it, binds the approved task and its derived authority to the Approver's consent through two integrity anchors, and records a durable Mission. Every access token derived under the Mission carries that authority and a "mission" claim, and issuance is gated on the Mission's lifecycle state. Optional capabilities represent delegation among agents with the OAuth Actor Profile and, as specified by a companion, let a single Mission be honored across trust domains. This is the issuance and governance "mission layer" left unspecified by agent-identity work for OAuth; runtime enforcement of each action is a separate, optional layer. | |||||||||||||
| draft-mcguinness-oauth-resource-token-resp-03.txt | ||||||||||||||
| OAuth 2.0 Resource Parameter in Access Token Response | ||||||||||||||
|
This specification defines a new parameter resource to be returned in OAuth 2.0 access token responses. It enables clients to confirm that the issued token is valid for the intended resource. This mitigates ambiguity and certain classes of security vulnerabilities such as resource mix-up attacks, particularly in systems that use the Resource Indicators for OAuth 2.0 specification [RFC8707]. | |||||||||||||
| draft-mcguinness-oauth-token-exchange-cnf-00.txt | ||||||||||||||
| Confirmation Response Parameter for OAuth 2.0 Token Exchange | ||||||||||||||
|
This specification defines a cnf response parameter for the OAuth 2.0 Token Exchange (RFC 8693) response. The parameter carries the confirmation method that the authorization server applied to the issued token, enabling clients to verify that sender-constraint binding (for example a DPoP key or mutual-TLS client certificate) was performed without inspecting the issued token. This is useful for opaque tokens, encrypted tokens, or any other case where the client cannot read the issued token's cnf claim directly. | |||||||||||||
| draft-mcguinness-token-xchg-target-svc-disco-02.txt | ||||||||||||||
| OAuth 2.0 Token Exchange Target Service Discovery | ||||||||||||||
|
This specification defines a method for OAuth 2.0 clients to discover the set of available Token Exchange Targets (such as audiences, resources, scopes, and token types) for a given subject token when performing OAuth 2.0 Token Exchange. The discovery endpoint accepts a subject token of any type the authorization server supports, identified by a token type URI, and returns values that are valid inputs to subsequent Token Exchange requests, supporting advanced use cases such as identity chaining and cross-domain delegation. | |||||||||||||
| draft-mclaggan-wccp-v2rev1-00.txt | ||||||||||||||
| Web Cache Communication Protocol V2,Revision 1 | ||||||||||||||
|
This document describes version 2 of the Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. | |||||||||||||
| draft-mcmillion-server-monitoring-00.txt | ||||||||||||||
| Server Monitoring of Merkle Tree Certificates | ||||||||||||||
|
This document describes a system for site operators to monitor for mis-issued Merkle Tree Certificates affecting their websites. This monitoring is highly efficient, requiring site operators to do an amount of work that is only logarithmic proportional to the total number of certificates issued. It does this while preserving the security and transparency guarantees of Merkle Tree Certificates. 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/Bren2010/draft-server-monitoring. | |||||||||||||
| draft-mcnally-deterministic-cbor-18.txt | ||||||||||||||
| dCBOR: Deterministic CBOR | ||||||||||||||
|
The purpose of determinism is to ensure that semantically equivalent data items are encoded into identical byte streams. CBOR (RFC 8949) defines "Deterministically Encoded CBOR" in its Section 4.2, but leaves some important choices up to the application developer. The present document specifies dCBOR, a set of narrowing rules for CBOR that can be used to help achieve interoperable deterministic encoding for a variety of applications desiring a narrow and clearly defined set of choices. | |||||||||||||
| draft-mcnally-envelope-12.txt | ||||||||||||||
| The Gordian Envelope Structured Data Format | ||||||||||||||
|
Gordian Envelope specifies a structured format for hierarchical binary data focused on the ability to transmit it in a privacy- focused way, offering support for privacy as described in RFC 6973 and human rights as described in RFC 8280. Envelopes are designed to facilitate "smart documents" and have a number of unique features including: easy representation of a variety of semantic structures, a built-in Merkle-like digest tree, deterministic representation using CBOR, and the ability for the holder of a document to selectively elide specific parts of a document without invalidating the digest tree structure. This document specifies the base Envelope format, which is designed to be extensible. | |||||||||||||
| draft-mcphillips-agentenvelope-derived-authority-01.txt | ||||||||||||||
| AgentEnvelope: Derived Authority and Legitimacy for Autonomous Systems | ||||||||||||||
|
AgentEnvelope defines a deterministic derived-authority model for autonomous and action-performing systems. Instead of issuing bearer credentials from a central authority, AgentEnvelope derives scoped action capabilities from customer-held custody material and canonical action envelopes. A verifier can check an action signature against a public action record without receiving roots, seeds, private keys, mint material, or hosted service access. This revision extends the model with legitimacy: a governance state that records whether a cryptographically valid authority remains admissible under current policy, evidence, time, and operating context. Legitimacy separates provenance from present-tense authorization. A command can remain signed and verifiable while becoming illegitimate because operating facts, policy, or evidence changed. For autonomous-system deployments, derived authority and legitimacy support an IAM model concerned with authority, admissibility, accountability, and audit for actors that perform actions, including AI agents, workflows, bots, microservices, devices, robots, serverless workers, and multi-agent systems. | |||||||||||||
| draft-mcw-opsawg-icon-requirements-01.txt | ||||||||||||||
| Architecture and Requirements for Observability,Control and Intervention of Network Management Agents | ||||||||||||||
|
This document defines architecture and a set of requirements for Observability, Control, and Intervention for Network Management Agents. It identifies gaps in existing mechanisms and specifies required interaction capabilities between Agent supervision systems and network management agents across multi-vendor environments, specifically observability, control, and runtime intervention. The requirements aim to guarantee comprehensive, lifecycle control over AI agents and enable observation, constraint, intervention, and correction to ensure network operational resilience and continuity. | |||||||||||||
| draft-mdt-quic-explicit-measurements-05.txt | ||||||||||||||
| Application of Explicit Measurement Techniques for QUIC Troubleshooting | ||||||||||||||
|
This document defines a protocol that can be used by QUIC endpoints to signal packet loss in a way that can be used by network devices to measure and locate the source of the loss. Discussion of this work is encouraged to happen on the QUIC IETF mailing list [email protected] (mailto:[email protected]) or on the GitHub repository which contains the draft: https://github.com/igorlord/ draft-mdt-quic-explicit-measurements (https://github.com/igorlord/ draft-mdt-quic-explicit-measurements). | |||||||||||||
| draft-mela-nameservers-00.txt | ||||||||||||||
| Name server provider and domain name registrar | ||||||||||||||
|
This document describes operational practices and technical frameworks related to name server providers and domain name registrars. | |||||||||||||
| draft-melegassi-coherence-bfd-01.txt | ||||||||||||||
| Coherence-BFD: Sub-Second Coherence Detection Using Bidirectional Forwarding Detection Patterns | ||||||||||||||
|
This document specifies Coherence-BFD, a protocol that combines the asynchronous heartbeat, demand-mode, echo function, and detection-multiplier mechanisms of Bidirectional Forwarding Detection (BFD, [RFC5880]) with the multi-vantage path coherence detection of [I-D.melegassi-mvps-incremental-be]. The result is a sub-second coherence failure detector with theoretical and empirical detection latency of 55 ms (1091x faster than the 60-second tick baseline of the underlying BE-MVPS framework). Five execution variants are specified: V0 (baseline), V1 (heartbeat-fast), V2 (demand), V3 (echo), and V4 (hybrid). Wall- clock benchmarks confirm V3 (Echo) as the latency-optimal variant at 55 ms median tau_detect with 39 680 B/s bandwidth. This revision (-01) adds three layers of proof: (a) Canonical: formal proofs of the detection lower-bound (Theorem T-BFD-1), false-positive-rate decay (Theorem T-BFD-2), and connection to the GDDP geometric- precision framework (Corollary C-BFD-3). (b) Empirical: SHA-256-anchored benchmark receipts reproducible from the public reference scripts. (c) Real data: validation against 92 067 RIPE Atlas RTT measurements from 450+ globally-distributed anchors spanning 2+ months of continuous collection. NOTE ON DATA PROVENANCE. Wall-clock detection-latency and bandwidth numbers in Section 10 are obtained from controlled benchmarks (scripts/benchmark_coherence_bfd.py). Real-data validation in Section 18 uses live Internet RTT measurements from RIPE Atlas to confirm that the theoretical bounds hold on operational paths. HARDWARE CAVEAT. The 55 ms median tau_detect is a SOFTWARE- HARNESS measurement, not a router-class measurement. Validation against real BFD hardware is identified as required future work before progression past Experimental status. | |||||||||||||
| draft-melegassi-dispatch-mvps-snap-backup-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-iab-mvps-architecture-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-iab-mvps-planetary-floor-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ippm-mvps-bundle-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ippm-mvps-coherence-leadtime-00.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-melegassi-ippm-mvps-extensions-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ippm-mvps-gddp-00.txt | ||||||||||||||
| Geometric Dilution of Detection Precision for Multi-Vantage Path Snapshots | ||||||||||||||
|
GPS positioning accuracy degrades with anchor geometry; the effect is quantified by the well-known Geometric Dilution of Precision (GDOP). Multi-vantage anomaly detection systems face the DUAL problem: how does anchor geometry affect DETECTION SENSITIVITY rather than localisation accuracy? This document formalises Geometric Dilution of Detection Precision (GDDP) for the Multi-Vantage Path Snapshot (MVPS) framework [I-D.melegassi-ippm-mvps-bundle]. The minimum displacement that a multi-vantage detector can reliably distinguish from measurement noise is NOT a single number: it is an anisotropic scalar field d*(v, theta) over the Earth's surface, governed by the geometry of the anchor set relative to each vantage. Three main results are proved: (1) GDDP Theorem (T-GDDP-1): d*(v, theta) admits a closed-form expression in terms of the Fisher Information of the anchor- to-vantage RTT-ratio vector. The directional detection threshold is d*(theta) = sqrt(chi2_crit / I(theta)), where I(theta) is the Fisher Information in direction theta. This is the Cramer-Rao bound applied to detection. (2) Anisotropy Lemma (L-GDDP-2): every vantage has a "blind cone" -- a set of directions in which displacement barely changes the RTT-ratio vector and detection sensitivity degrades. The blind cone is quantifiable and, for isolated vantages, can span over 70% of the compass. (3) Monotonicity Theorem (T-GDDP-3): adding an anchor NEVER reduces the Fisher Information of the system (Shannon chain rule applied to detection channels). There exists a principled anchor- placement optimisation: minimise max_theta d*(v, theta) over candidate sites. All three are validated to three layers of proof: canonical (math), empirical (deterministic scripts, seed=1337), and real data (RIPE Atlas measured RTTs, 92,067 D-squared values from 40 probes, 11/11 checks PASS). No simulation-only claim is made. The GDDP/GDOP duality has not, to the author's knowledge, been previously formalised. VerLoc (Kohls and Diaz, USENIX Security 2022) observes the directional effect empirically but does not derive d*(v, theta) or propose a geometric defence. | |||||||||||||
| draft-melegassi-ippm-mvps-latency-reconciliation-00.txt | ||||||||||||||
| 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): | |||||||||||||
| draft-melegassi-ippm-mvps-maritime-edge-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ippm-mvps-orbital-coherence-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ippm-mvps-proof-envelope-00.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-melegassi-ippm-mvps-terrestrial-mobile-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ippm-mvps-vantage-mpls-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ippm-mvps-video-surveillance-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-irtf-mvps-methodology-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-mvps-ai-coherence-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-mvps-ai-coherence-coupling-real-00.txt | ||||||||||||||
| Real-World Measurement of the Infrastructure-Cognitive Coupling Matrix R_cross: Closing the MVPS AI-Coherence Production Conjecture (IC9.1) | ||||||||||||||
|
The MVPS AI-Coherence framework [I-D.melegassi-mvps-ai-coherence] defines an infrastructure-cognitive coupling matrix R_cross = Sigma_net^{-1/2} Sigma_cross Sigma_AI^{-1/2} and proves, in simulation, that a non-zero R_cross is the necessary and sufficient condition for the joint network-AI anomaly space to carry detection information that neither standalone monitor can recover. That document leaves two items open: (a) work item IC9.1, a statistical hypothesis test on R_cross over an empirical joint covariance, and (b) the CONJECTURE that E[R_cross] != 0 in production AI-on-network deployments. This companion document closes both. It specifies a permutation- based hypothesis test for the normalized cross-block correlation estimator, reports the FIRST real-wire measurement of R_cross on a production large-language-model serving path (n = 100 ticks, DeepInfra), and documents a pure-arithmetic reference implementation embedded in an operational system that reproduces the measurement number-for-number. The strongest coupling, latency_ms <-> output tokens, is r = +0.446 (permutation p = 0.0005) on the full series and survives the same-model confound control at r = +0.343 (p = 0.0135) within a single serving regime. The Frobenius norm ||R_cross||_F = 0.469 (full) / 0.443 (intra-regime) exceeds the non-triviality floor of 0.05, confirming the production conjecture for this deployment. The document also specifies how the measured coupling and the per-engine Mahalanobis distance D^2 are consumed by an operational Wald Sequential Probability Ratio Test (SPRT) as an additive evidence channel for surgical sub-environment bifurcation. | |||||||||||||
| draft-melegassi-mvps-botnet-coherence-00.txt | ||||||||||||||
| Botnet Identification by Coordination-Coherence and Coherence-Driven Remediation Signaling: The MVPS Botnet Profile | ||||||||||||||
|
This document specifies how the Multi-Vantage Path Synchrony (MVPS) framework [I-D.melegassi-ippm-mvps-bundle] and its DDoS profile [I-D.melegassi-mvps-ddos-resilience] are extended to IDENTIFY the participating sources of a botnet by their coordination-coherence signature, and to EMIT corroborated, signed evidence that DRIVES existing, standardised remediation ("sanitization") machinery. The central design constraint is honesty about scope. MVPS does NOT itself clean, quarantine, sinkhole, or take down infected hosts. Remediation is performed by the mechanisms already defined by the IETF: o RFC 6561 (Recommendations for the Remediation of Bots in ISP Networks) -- the notification/remediation workflow; o RFC 9132 / RFC 8783 / RFC 8811 (DOTS) -- mitigation request signaling; o RFC 8520 (Manufacturer Usage Description, MUD) -- containment of compromised constrained/IoT devices; o BCP 38 / BCP 84 (RFC 2827 / RFC 3704) -- source-address validation against spoofed botnet traffic; o RFC 7970 / RFC 8727 (IODEF) and RFC 6545 (RID) -- the exchange and inter-domain coordination formats; o RFC 9424 -- the Indicator-of-Compromise (IoC) framing for what MVPS exports. What MVPS contributes is precisely the gap RFC 6561 Section 4 names: it asks operators to "confirm a bot infection through the use of a combination of multiple bot detection data points ... to corroborate information of varying dependability ... [and] avoid or minimize the possibility of false-positive identification of hosts." MVPS is exactly such a corroboration engine, with the addition of a provable false-positive bound (Theorem B2) and a coordination-coherence test (Theorem B1) that distinguishes a genuinely coordinated population (a botnet) from an equal number of independently misbehaving hosts. We state three results: Theorem B1 (Coordination Signature). A population of S sources driven by a common controller produces a low-rank deformation of the cross-vantage coherence covariance; independent legitimate sources do not. The leading eigenvalue ratio is therefore a detector of coordination, not of volume. Theorem B2 (Corroboration / False-Positive Bound). If a single vantage flags a candidate source with per-vantage false-positive rate p, then requiring agreement across V independent vantages drives the host-level false-positive probability to at most p^V under vantage independence, and to a stated mixture bound under partial correlation. Theorem B3 (No Unilateral Action / Remediation Soundness). MVPS emits evidence only. Every enforcement step is taken by an existing standardised control point (RFC 6561 / DOTS / MUD / BCP 38). No host is quarantined on single-vantage evidence. Theorem B4 (Falsifiability / coherence-collapse axis). The corroboration bound of B2 COLLAPSES on a correlated benign population: a legitimate flash crowd is coordinated-but-benign, the botnet analogue of the COHERENT_BUT_FALSE failure mode of the MVPS AI-Coherence extension [I-D.melegassi-mvps-ai-coherence]. When the coherence environment so collapses, that extension's falsifiability axis enters: re-test the apparent coordination on the machine-regularity subspace -- features a human crowd cannot fake. A flash crowd collapses to the independent floor there; a real bot fleet does not. Theorem B5 (No Free Decorrelation). Spreading the botnet's coordination across many sources to drop each per-vantage signal cannot lower what the multi-vantage aggregate sees: the coherent statistic is spread-INVARIANT (T_agg = sqrt(E)) with NO compute term, so the multi-vantage advantage GROWS with the spread and the silent-coordination cap is E < tau^2. This is the exact form of the B1 evasion corollary. Theorem B6 (Non-Blinding of the corroboration set). Silently hiding the coordination by corrupting the vantages is impossible while the redundancy rho = V - d_eff >= 1 with diverse vantages: any such blinding needs k > rho corruptions and is FLAGGED by the vantage-integrity monitor (a non-zero stealth-gap), and the only un-flagged corruption -- forging vantage reports -- is gated by a post-quantum signature (ML-DSA, FIPS 204). "Blind" implies "known-blind". THE THESIS IN ONE LINE. Cross-vantage agreement is necessary but not sufficient: the coherence environment can collapse (correlated benign crowds, or Byzantine vantages), and where it collapses the AI-coherence axes -- falsifiability (B4) and Byzantine-robust geometric-median aggregation [I-D.melegassi-mvps-ai-coherence] -- are what keep the identification sound. NOTE ON DATA PROVENANCE. Section 7 reports two kinds of result, each tagged. Section 7.1 is a LABELLED SYNTHETIC ground-truth experiment (script scripts/simulate_botnet_coherence.py). Sections 7.2 and 7.3 are measured on REAL labelled botnet traffic: the CTU-13 dataset of the Stratosphere IPS Laboratory (bidirectional NetFlow [RFC5103] / IPFIX [RFC7011] records labelled Botnet / Normal / Background), across three malware families (Neris, Rbot, Virut). On that real data the detector separates botnet from normal traffic with held-out AUC 0.85-0.999, and the multi-vantage advantage (Theorem B5) is instantiated with the MEASURED per-flow effect size. What remains REQUIRED future work (Section 10) is corroboration across THREE OR MORE INDEPENDENT REAL VANTAGES observing the same event (the real-data form of Theorem B2): CTU-13 is a single capture point. No claim of operational botnet takedown is made. | |||||||||||||
| draft-melegassi-mvps-ddos-resilience-02.txt | ||||||||||||||
| Volume-Independent DDoS Detection via Coherence-BFD: The MVPS DDoS Resilience Profile | ||||||||||||||
|
This document specifies how the Multi-Vantage Path Synchrony (MVPS) framework [I-D.melegassi-ippm-mvps-bundle] and its sub-tick variant Coherence-BFD [I-D.melegassi-coherence-bfd] detect volumetric and distributed Denial-of-Service (DDoS) attacks in time bounded by (M-1)*T_tick, INDEPENDENT of the attack rate in packets- per-second or bits-per-second. Three theorems are proved: Theorem D1 (Volume-Independence). Detection latency is a function of the control-tick period T_tick and the M-multiplier confirmation count alone; it does not grow with attack volume. Theorem D2 (Distributed-Attack Bound). The framework detects up to floor((k-1)/2) simultaneous regional attacks under cell-aware minimax aggregation, where k is the number of coherence cells. Theorem D3 (Broker NIC Sizing). Under the three architectural invariants of Section 3, broker NIC sizing is independent of attack volume; it is determined only by the legitimate telemetry packets-per-second. This revision (-02) adds seven confirmed real-world DDoS detections using a causally-direct methodology: BGP updates measured on each VICTIM'S OWN announced prefix (not on unrelated third-party infrastructure). (a) 7 independently confirmed DDoS attacks across 3 continents (Australia, South Africa, New Zealand), spanning two orders of magnitude in target size (from a major OS vendor to a small 22-year-old regional host): VentraIP (600 Gbps), Canonical (3.5 Tbps), Binary Lane (400 Gbps), Network Platforms (676 Gbps), Xneelo (300 Gbps), SiteHost NZ, and 1-Grid (100 Gbps). 30 of 33 tested prefixes (91%) alarmed on the confirmed attack day; 4 of 7 targets show 100% prefix corroboration. (b) VentraIP: BGP alarm fired the SAME HOUR as attack onset (00:00 UTC, D^2=11.7), four hours BEFORE mitigation began. Canonical: BGP alarm fired 2 hours BEFORE Cloudflare migration began. (c) Joint statistical significance across all 7 targets (multi-prefix binomial test): P < 5.9*10^-60 under the null hypothesis that alarms are unrelated to attack timing -- 52 orders of magnitude beyond the 5-sigma particle- physics discovery threshold. (d) Volume-independence (D1) confirmed: 1-Grid (100 Gbps) produced a HIGHER D^2 (63.2) than Canonical (3500 Gbps, D^2=10.6). Detection depends on coherence deformation, not attack bandwidth. (e) An invalid claim from an intermediate draft (RIPE Atlas K-root time-coincidence implying 53.6-hour pre-report detection) was identified via a Monte Carlo control test as a look- elsewhere/base-rate artifact and RETRACTED (Section 7.7.1), then replaced with the causally-direct results above. | |||||||||||||
| draft-melegassi-mvps-incremental-be-00.txt | ||||||||||||||
| 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 | |||||||||||||
| draft-melegassi-mvps-perfsec-coupling-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-ntp-mvps-clock-coherence-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-opsawg-mvps-logging-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-opsawg-mvps-telemetry-export-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-opsawg-mvps-yang-model-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melegassi-rats-mvps-memory-coherence-00.txt | ||||||||||||||
| MVPS-Memory: Multi-Vantage Coherence Detection of Memory-Resident Malware,Anchored in Remote Attestation | ||||||||||||||
|
Memory-resident ("fileless", in-memory) malware -- reflective code injection, page-cache .text patching, process hollowing, RX->RWX permission flips, unbacked-memory thread starts, token theft, and patchless AMSI/ETW suppression -- leaves the on-disk image unchanged and is therefore structurally invisible to signature and file-integrity detectors. This document explains why, and what removes the blind spot, using the Multi-Vantage Path Synchrony (MVPS) observability model y = H x: each detection facility is a row (a projection) of one observation operator H over an interior runtime-memory state x, and a purely in-memory implant is an attack whose damage direction c lies in the NULL SPACE of any single on-disk vantage. The contribution uses no new mathematics. It (1) instantiates the already-proved MVPS results -- the Stealth-Manifold Lemma, the coordination-stealth duality, the Stealth Conservation Law max(0, k - rho), the reflexive tower, the data-processing ceiling, the non-blinding invariant (stealth + effect = ||a||^2), and the silent-effect ceiling (E < tau^2) -- verbatim on the runtime-memory surface; (2) anchors the meta-observer in the RATS architecture [RFC9334], whose Attester is defined to collect Claims by "taking measurements on code, memory, or other security related assets", with TPM-based Remote Integrity Verification [RFC9683], the Entity Attestation Token [RFC9711], the Concise Reference Integrity Manifest [I-D.ietf-rats-corim], and Concise Software Identification [RFC9393] as the evidence/reference-value layer; and (3) closes the vantage-forgery channel with post-quantum eye identity (ML-DSA, FIPS 204, via [I-D.ietf-cose-dilithium] and [I-D.ietf-lamps-dilithium-certificates]). A live threat anchor -- the 2025-2026 surge in BYOVD EDR-killers (e.g. CVE-2025-68947) and patchless AMSI/ETW suppression -- is shown to be a textbook instance of the eye-silencing law. All theorem-level claims carry a machine-checkable numerical receipt. | |||||||||||||
| draft-melegassi-santos-ippm-mvps-cwt-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-melnikov-imap-rememberme-01.txt | ||||||||||||||
| IMAP REMEMBERME extension for quick reauthentication token generation | ||||||||||||||
|
This document specifies an IMAP extension for generating quick reauthentication tokens that allow clients to re-login without user interaction, once authentication using a strong SASL mechanism is completed. | |||||||||||||
| draft-melnikov-imap-sasl2-profile-00.txt | ||||||||||||||
| IMAP SASL2 Profile | ||||||||||||||
|
This document specifies an IMAP extension for SASL2 authentication, which extends IMAP SASL (RFC 4422) Profile. | |||||||||||||
| draft-melnikov-jmap-smime-sender-extensions-alt-07.txt | ||||||||||||||
| JMAP extension for S/MIME signing and encryption | ||||||||||||||
|
This document specifies an extension to JMAP for sending S/MIME signed and/or S/MIME encrypted messages, as well as automatic decryption of received S/MIME messages. [[This version presents an alternative syntax to revision 04 of https://datatracker.ietf.org/doc/draft-ietf-jmap-smime-sender- extensions/]] | |||||||||||||
| draft-melnikov-sasl2-03.txt | ||||||||||||||
| Extensible Simple Authentication and Security Layer (SASL) | ||||||||||||||
|
The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. This document also defines how servers can request fulfillment of extra authentication related tasks, such as two factor authentication and/or password change. | |||||||||||||
| draft-melnikov-smtp-rememberme-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mennell-art-fmsg-structured-messaging-01.txt | ||||||||||||||
| fmsg: Structured Host-to-Host Messaging with Verifiable Threads | ||||||||||||||
|
fmsg is a message exchange protocol between domain defined hosts. Messages are binary encoded and form threads which require participation to reply to. This document describes the motivation and architecture of fmsg, an existing protocol specification and implementation are referenced, but the full specification is not included here. The purpose of this document is to solicit IETF feedback on venue and scope before/if the specification can develop into standards-track documents. | |||||||||||||
| draft-menon-svr-08.txt | ||||||||||||||
| Hewlett Packard Enterprise's Secure Vector Routing (SVR) | ||||||||||||||
|
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. | |||||||||||||
| draft-meow-mrrp-00.txt | ||||||||||||||
| Meow | ||||||||||||||
|
Meow meow meow meow Meow Meow Meow (MEOW). MEOW meow meow meow meow- meow meow meow meow Meow meow meow, meow meow meow meow meow meow meow meow meow meow meow meow meow Meow. Meow meow meow, mrrp meow meow meow meow meow meow meow MEOW meow meow meow meow meow MEOW MEOW, meow meow meow meow meow meow meow mrow meow meow. Meow meow meow meow meow meow meow meow meow meow meow meow meow MEOW MEOW. Meow meow meow MEOW MEOW, meow meow meow Meow MEOW, MEOW, MEOW, MEOW, MEOW, meow MEOW meow meow meow meow MEOW MEOW. Meow meow Meow MEOW meow MEOW, meow meow meow meow meow meow moew meow meow meow meow meow meow meow meow meow MEOW meow. Meow meow meow MEOW MEOW meow meow nya meow meow meow meow meow meow meow meow MEOW-MEOW meow. Meow MEOW meow meow meow meow MEOW MEOW meow meow meow meow meow meow MEOW MEOW. | |||||||||||||
| draft-meow-protocol-information-over-air-00.txt | ||||||||||||||
| Protocol Information Over Air | ||||||||||||||
|
This protocol transmits information over the air, marking fast and big download speeds. | |||||||||||||
| draft-mertl-afipv8-00.txt | ||||||||||||||
| UTF-8 Internet Protocol Addresses | ||||||||||||||
|
This memo describes an alternate entry and display format for IPv6 addresses using UTF-8 instead of hextets. A mixed representation for traditional IPv6 address prefixes also is explored, along with means of transitioning between the two within an IPv6 address. Additionally, an address extension is proposed to accommodate the inevitable need for longer addresses. Finally, security implications of special UTF-8 glyphs are considered. | |||||||||||||
| draft-mery-nagy-taistamp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-meunier-privacypass-reverse-flow-07.txt | ||||||||||||||
| Privacy Pass Reverse Flow | ||||||||||||||
|
This document specifies an instantiation of the Privacy Pass Architecture (RFC 9576) that allows for a "reverse" flow from the Origin to the Client. It describes a method for an Origin to issue a state update to the Client in response to a request in which a token is redeemed. | |||||||||||||
| draft-meunier-privacypass-reverse-flow-http-00.txt | ||||||||||||||
| Privacy Pass Reverse Flow HTTP Transport | ||||||||||||||
|
This document specifies an instantiation of Privacy Pass Reverse Flow [REVERSE-FLOW] where HTTP is used as a transport mechanism. It describes a novel HTTP header field that Clients and Origins can use to carry reverse flow data. | |||||||||||||
| draft-meunier-webbotauth-registry-03.txt | ||||||||||||||
| Registry and Signature Agent card for Web bot auth | ||||||||||||||
|
This document defines the "Signature Agent Card", a JSON metadata document that a signature agent using [DIRECTORY] publishes to describe itself: its identity, purpose, rate expectations, and cryptographic keys. Its parameters are drawn from the OAuth Dynamic Client Registration Metadata registry [DCR], the same namespace used by [CIMD], extended with a single web_bot_auth object. This document registers that object with IANA and establishes a registry for its members. | |||||||||||||
| draft-mglt-ipsecme-dscp-np-06.txt | ||||||||||||||
| Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification | ||||||||||||||
|
This document outlines the DSCP Notification Payload, which, during a CREATE_CHILD_SA Exchange, explicitly indicates the DSCP code points that will be encapsulated in the newly established tunnel. This document updates RFC 4301. | |||||||||||||
| draft-miao-agw-core-functional-architecture-00.txt | ||||||||||||||
| Agent Gateway Core functional Architecture | ||||||||||||||
|
This document defines the core functional architecture of the Agent Gateway as a universal infrastructure component. The Agent Gateway is designed to address key challenges in single-domain multi-agent collaboration and cross-domain multi-agent communication, including trust boundaries, protocol termination, capability discovery, and task routing. The main framework consists of four gateway capabilities: the A2A Gateway (supporting inter-agent communication), the MCP Gateway (supporting tool invocation), the Model Routing Gateway (supporting large language model invocation), and the Network Gateway (supporting underlying network connectivity). The A2A Gateway is further decomposed into five core capabilities: protocol translation, authentication and security, asynchronous task management, peer-to-peer network management, and Agent routing capabilities (including Agent registry, capability discovery, task routing, and load balancing). This document is intended for designers and implementers seeking to build standardized, interoperable agent communication infrastructure. | |||||||||||||
| draft-miao-agw-cross-domain-scenario-analysis-00.txt | ||||||||||||||
| Agent Gateway Scenario Analysis and Functional Requirements for Cross-Domain Multi-Agent Communication | ||||||||||||||
|
This document analyzes the communication gaps in three representative multi-agent scenarios: single-domain single-agent, single-domain multi-agent, and cross-domain multi-agent. For each scenario, it examines whether an Agent Gateway is needed, what capabilities it should provide, and where it should be deployed. Based on the consolidated gap analysis, this document derives a set of universal functional requirements for the Agent Gateway as a standardized cross-domain trust boundary and protocol termination layer. The findings aim to guide the design of interoperable agent communication infrastructure. | |||||||||||||
| draft-miao-rtgwg-satellite-routing-reqs-00.txt | ||||||||||||||
| Scenarios and Routing Requirements for Mega-Constellation LEO Satellite Networks | ||||||||||||||
|
With the rapid maturation of laser Inter-Satellite Link (ISL) technologies, Low Earth Orbit (LEO) mega-constellations are evolving from bent-pipe relay networks dependent on dense Ground Stations (GS) into highly autonomous spaceborne routing networks. Traditional terrestrial routing protocols and their variants, such as Global Link-State Routing Architectures, rely on a globally consistent link- state view and a global convergence paradigm, which are fundamentally incompatible with the high dynamics, time-variant topologies, and frequent link disruptions characteristic of ten-thousand-node scale satellite networks. This document describes core routing scenarios including non-dense ground deployment and inter-continental transit, analyzes the engineering infeasibility of global convergence protocols in space environments, reviews the limitations of existing mitigation approaches, and specifies key requirements for satellite routing protocols centered around localized autonomy and distributed decision-making. | |||||||||||||
| draft-mih-agent-accountability-conformance-00.txt | ||||||||||||||
| Agent Accountability: A Conformance and Verification Method | ||||||||||||||
|
An architecture for auditing agent-driven interactions (draft- kuehlewind-audit-architecture) identifies the record types an auditable agent system produces — interaction, action, delegation, and authorization-transition — and the role of an Auditor that determines whether recorded behaviour matched intent and the authorization in force. That architecture does not specify how an Auditor, or any independent party, deterministically verifies that a set of such records — produced by different parties, in different profiles, and composed into one case — is internally consistent and correctly derives an audit conclusion. This document specifies a horizontal conformance and verification methodology for composed agent-accountability records. It organizes conformance into three tiers: the payload-binding layer, per-record- type (per-slot) conformance, and composition (combination) conformance. It defines the determinism boundary between what is mechanically derivable from the binding rules and the individual records, and what is irreducibly semantic; a conformance-vector discipline (positive, negative, and must-fail cases, checked in both directions) that any record profile reuses rather than reinvents; and a deterministic method for deriving composition-conformance vectors from binding rules, individual-record vectors, a composition manifest, and a set of cross-record predicates. The methodology is profile-agnostic: it applies uniformly to any accountability record type and to any declared composition of them, whether those records are joined across parties or across attestation layers. Its lower two tiers verify a single record, so the method applies where no composition is present and strengthens as records are composed. It is intended as the composition-verification work item of the auditing architecture — the one its enumerated work items do not yet cover. | |||||||||||||
| draft-mih-agent-bilateral-attestation-02.txt | ||||||||||||||
| Bilateral Attestation of Cross-Organization Agent Actions | ||||||||||||||
|
When an agent operated by one organization requests a consequential action from an agent operated by another, today's record of that exchange — if one exists — is kept by one side, editable by that side, and deniable by the other. Disputes reduce to my-log-versus- your-log. This document describes a bilateral attestation exchange for such actions: the requesting organization signs a request attestation binding it to the action and its material terms; the performing organization evaluates the request against deterministic constraints at the boundary where the action takes effect and signs an action attestation recording the constraint results and the disposition — performed, declined, or escalated to a human — by reference to the request; and each party acknowledges the other's attestation. The combined record binds each organization to its part, gives each proof of the other's, and can be anchored to a transparency service so that a third party who trusts neither organization can verify the record end-to-end. The exchange records refusals with the same fidelity as performance, and degrades gracefully when a counterparty cannot attest, marking the record's reduced assurance rather than blocking the transaction. | |||||||||||||
| draft-mih-sato-agent-accountability-composition-01.txt | ||||||||||||||
| Agent Accountability: Composition and Conformance | ||||||||||||||
|
Autonomous and semi-autonomous software agents increasingly take consequential actions across administrative and trust domains. Holding such an action accountable — to a regulator, auditor, or counterparty who does not trust the operator — requires answering several questions, each answerable by an independently-verifiable profile: whether the agent was permitted to act (CAN), which accountable human authorized the specific action (WHO), what the agent actually did (WHAT), and whether the runtime enforced correctly (AUDIT). This document specifies, in Informational terms, how such profiles compose — by a shared action-digest, each verifying independently — and defines a shared conformance-vector suite against which any profile may be tested. It complements existing audit-architecture and record-format work rather than replacing it, reusing existing signing, transport, and transparency mechanisms. Its focus is an assurance tier those documents leave open: most agent records today are self-attested by an interested party; this document makes reachable and testable an anchored, third-party-verifiable tier, in which a record is registered to a transparency service (SCITT) so a party who trusts neither the agent nor the operator can verify it. Self-attestation remains a valid baseline; convergence on the disinterested tier — by any conforming profile — is the goal, not a single mandated format. | |||||||||||||
| draft-mih-scitt-agent-action-capsule-04.txt | ||||||||||||||
| An Agent Action Capsule Profile for SCITT | ||||||||||||||
|
This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. | |||||||||||||
| draft-mih-scitt-agent-action-capsule-sel-disc-00.txt | ||||||||||||||
| Selective Disclosure Profile for Agent Action Capsules | ||||||||||||||
|
This document normatively profiles the per-field selective-disclosure extension point reserved in draft-mih-scitt-agent-action-capsule-01 Section 9.2 (Selective Disclosure). It defines the salted-hash commitment encoding, decoy-digest construction, disclosure format, producer requirements, and verifier checks for selectively disclosable fields in Agent Action Capsule payloads. The mechanism follows the SD-JWT selective-disclosure model (RFC 9901) — salted- hash commitments, decoy digests, and disclosed [salt, name, value] triples — using JCS (RFC 8785) canonicalization, which is already the base Capsule profile's canonical form. SD-JWT (RFC 9901) is the JSON form; SD-CWT (draft-ietf-spice-sd-cwt) is the CBOR/dCBOR sibling. Because the Capsule payload is JSON, this profile uses the SD-JWT (JSON) construction, cited alongside the SPICE WG's SD-CWT work for SCITT-ecosystem consistency. Verifier checks are deterministic and reproducible from the Capsule bytes plus a provided disclosure set alone; no clock, network access, model invocation, or external lookup beyond the provided disclosures is required. | |||||||||||||
| draft-mih-scitt-checkpointed-local-log-00.txt | ||||||||||||||
| The Checkpointed Local Log (CLL) | ||||||||||||||
|
Many systems emit individually signed records — receipts, attestations, statements — and store them locally. Each record verifies on its own, but the collection proves nothing: records can be deleted, reordered, or created after the fact without detection. This document specifies the Checkpointed Local Log (CLL): a producer- operated append-only log, built on the Merkle Mountain Range structure whose COSE proof formats are specified in [I-D.bryce-cose-receipts-mmr-profile], together with a small signed checkpoint that commits to the log's entire history. Records of any format are appended as they are produced; checkpoints are emitted on a declared cadence and may be registered with one or more independent Transparency Services or witnesses using existing SCITT registration. A CLL upgrades a set of point receipts into a stream with provable order, contemporaneity, and completeness — while defining precisely, and narrowly, what such a log does and does not establish. This document defines the log discipline and the checkpoint structure; it defines no new proof formats, no transparency service behavior, and no payload semantics. | |||||||||||||
| draft-mih-sokolov-scitt-payload-binding-05.txt | ||||||||||||||
| Canonicalization Declaration for SCITT Signed Statements | ||||||||||||||
|
Independently written systems that anchor records to a SCITT Transparency Service repeatedly need the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, binding to a SCITT Signed Statement and Receipt, and references that cite external artifacts by digest. This document, referred to as CPB, specifies that construction as declarations rather than as a payload format. A payload profile declares its canonicalization algorithm and exclusion set and thereby obtains a reproducible derived identifier. A CPB Signed Statement carries either the complete statement content as specified by RFC 9943 or a digest of content held elsewhere using the COSE Hash Envelope of RFC 9995. CPB also defines an abstract typed digest reference information model and one optional protected-header encoding, cpb-refs; a payload profile may instead define its own reference serialization. An IANA registry assigns the canonicalization algorithm identifiers that these declarations name. CPB does not define payload content formats, establish or require a universal artifact-type registry, or require either typed-reference carrier. | |||||||||||||
| draft-miller-aeo-00.txt | ||||||||||||||
| The AEO1 Discovery Mechanism: A DNS-Anchored,Signed Pointer to Owner-Attested Fact Catalogs for AI Answer Engines | ||||||||||||||
|
This document specifies AEO1 (Answer Engine Optimization, version 1), a discovery mechanism that allows a domain owner to publish a verifiable, machine-readable pointer to a structured, owner-attested fact catalog for that domain. AEO1 consists of three coordinated surfaces: a DNS TXT record at the "_aeo" subdomain, a JSON document at the well-known URI "/.well-known/aeo.json", and an optional HTML link hint. Records may carry an Ed25519 signature issued by an issuing authority, enabling consuming agents such as AI answer engines to distinguish verified, current, domain-authorized data from unverified crawled content. The design follows the DNS-authenticated trust-anchor pattern established by SPF, DKIM, and DMARC. This document also requests provisional registration of the "aeo.json" well-known URI suffix. | |||||||||||||
| draft-miller-ztip-00.txt | ||||||||||||||
| Zero-Trust Intent Protocol (ZTIP) | ||||||||||||||
|
The Zero-Trust Intent Protocol (ZTIP) defines three primitives for verifiable delegation, intent binding, and behavioral attestation in multi-agent systems: | |||||||||||||
| draft-miller-ztnp-00.txt | ||||||||||||||
| Zero-Trust Negotiation Protocol (ZTNP) | ||||||||||||||
|
The Zero-Trust Negotiation Protocol (ZTNP) specifies a session-scoped trust negotiation protocol for software-layer security and governance posture. ZTNP defines how a Relying Party challenges a counterparty for a signed posture credential, evaluates local policy against it, and issues a short-lived, channel-bound, scoped authorization artifact (a Permit) gating subsequent operations within the session. ZTNP covers three phases: * *Enrollment*, in which a Prover obtains a signed Posture Assertion from an Issuer that has assessed it against a publicly-identified security framework. * *Negotiation*, in which the Requester issues a session challenge, receives the Prover's Posture Assertion bound to that challenge, evaluates local policy against it, and either issues a Permit or returns a structured denial. * *Validation*, in which subsequent operations within the session are gated against the Permit, with mandatory channel binding when the transport is TLS. The protocol's central design choice is to anchor the meaning of trust claims to a publicly-identified security framework (e.g., NIST AI RMF 1.0, ISO/IEC 42001) rather than to a specific Issuer. A policy expressing "require tier 3 against framework X" is portable across any Issuer that attests against framework X. ZTNP is independent of any particular attestation pipeline. Posture Assertions MAY be derived from RATS Attestation Results [RFC9334], from compliance audit programs, from automated governance scanners, or from any other Issuer evaluation methodology that meets the format requirements of Section 5. ZTNP is *not* a RATS consumption profile; Section 1.5 describes how ZTNP composes with RATS-pipelined and non- RATS-pipelined deployments alike. Multi-principal delegation, prompt-injection-resistant intent binding, and behavioral-claim extensions are specified in a companion document, the Zero-Trust Intent Protocol (ZTIP) [I-D.miller-ztip]. This draft is an individual submission. The author intends to progress this work in a venue scoped to attestation-gated session authorization; possibilities include OAuth, WIMSE, SAAG-routed new work, or an Independent Submission. Community guidance on venue is welcome. | |||||||||||||
| draft-mishra-oauth-agent-grants-02.txt | ||||||||||||||
| OAuth Profile for Delegated AI Agent Authorization | ||||||||||||||
|
AI agents increasingly invoke protected APIs on behalf of human users. This document defines an OAuth profile for identifying an agent client instance, obtaining an authenticated user's consent, issuing resource-bound and sender-constrained access tokens, attenuating authority through OAuth Token Exchange, and rotating refresh tokens safely. The profile uses existing OAuth and JOSE mechanisms wherever possible and defines no new JWT claims or OAuth endpoints. Operational facilities such as policy engines, audit stores, budgets, event streams, and credential vaults are outside the interoperable core. Grantex is an incomplete reference implementation and is not required for conformance. | |||||||||||||
| draft-mitchell-botcentral-card-00.txt | ||||||||||||||
| The BotCentral Card: An Owner-Proven Consent Record for Automated Web Clients | ||||||||||||||
|
The Robots Exclusion Protocol (RFC 9309) lets a site say which automated clients may fetch its content. It cannot express purpose: fetching a page to answer a person is not the same act as copying it into a model training set or taking an action on the site. It also cannot prove who published the policy. This document defines the BotCentral Card, a JSON record, one per domain, that states which purposes the domain owner consents to ("retrieve", "train", and "act" as separate answers), backed by a proof of domain control placed either in a DNS TXT record or at the well-known URI "/.well-known/botcentral.txt". Cards are written to a registry by authenticated publishers and read by any client over HTTP or the Model Context Protocol. Clients never write cards. A card is permission to be found; it is not a ranking and not a training grant. This document also registers the "botcentral.txt" well-known URI. | |||||||||||||
| draft-mitchell-intarea-rfc5837bis-01.txt | ||||||||||||||
| Extending ICMP for Interface and Next-Hop Identification | ||||||||||||||
|
This memo defines data structures that can be appended to selected ICMP messages. The ICMP extensions defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, the sub- IP component of an IP interface through which the datagram would have been forwarded had it been forwardable, and the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. This document obsoletes RFC 5837. To preserve strict backward compatibility with legacy implementations, it preserves the original Interface Information Object (Class-Num 2) as defined in RFC 5837, and introduces a new Extended Interface Information Object to accommodate new interface roles. | |||||||||||||
| draft-miyachi-ltv-jws-00.txt | ||||||||||||||
| Long-Term Validation for JSON Web Signature (LTV-JWS) | ||||||||||||||
|
This specification extends JSON Web Signature (JWS, [RFC7515]) and defines LTV-JWS, a lightweight long-term signature format for Long- Term Validation (LTV). LTV-JWS adds signature extension elements, timestamps [RFC3161], validation information (certificates [RFC5280], CRLs [RFC5280], and OCSP responses [RFC6960]), and archive structures as minimal extensions, thereby enabling the validity of signatures to be verified over extended periods of time. In addition, archive timestamps enable continued validation even after the obsolescence or compromise of cryptographic algorithms. LTV-JWS preserves the simple structure and concept of JWS while progressively adding timestamps and validation information. It also enables more general-purpose signing use cases through indirect signatures using external references (refs). | |||||||||||||
| draft-miyatoch-teas-actn-inter-operator-extension-00.txt | ||||||||||||||
| ACTN Extensions for Inter-Operator Coordination | ||||||||||||||
|
This document specifies an extension to the ACTN framework (RFC 8453) that enables coordination between the MDSCs of different operators, so that they can establish and operate end-to-end TE services cooperatively while each operator keeps full control of its own network and keeps its internal details private. As its concrete realization within ACTN, the extension defines the MDSC-MDSC Interface (MMI), a symmetric peer interface between the MDSCs of different operators, in which neither MDSC has authority over the other, and which complements rather than modifies the CMI and the MPI. The extension is independent of the underlying switching technology and applies to packet, optical, and multi-layer TE networks. | |||||||||||||
| draft-mk-dnsop-svcb-well-known-00.txt | ||||||||||||||
| An SVCB Service Parameter for Well-Known URI Paths | ||||||||||||||
|
This document defines the "well-known" Service Parameter Key (SvcParamKey) for SVCB and HTTPS resource records. It carries one or more well-known URI suffixes, identifying resources under "/.well- known/" that are available at the service endpoint. It specifies the presentation and wire formats and requests registration of the key with IANA. | |||||||||||||
| draft-mnki-agent-trust-profile-00.txt | ||||||||||||||
| The Agent Trust Profile: Verifiable Authority for Autonomous Agents | ||||||||||||||
|
Autonomous AI agents act on behalf of people and organizations across system and organizational boundaries. Existing credentials establish that a token is valid; they do not express which agent is acting, for whom, under what delegated authority, within which constraints, and whether that authority is still current. This document profiles existing standards — JWS, OAuth/OIDC, SPIFFE/WIMSE workload identity, DPoP-style proof of possession, OpenID AuthZEN and OpenID Federation — to carry those semantics: agent identity and principal binding, delegation with authority attenuation, capability-based authorization with constraints, request proof of possession, authorization attestations, tamper-evident provenance, revocation, and cross- organization trust. It defines no new cryptography, transport or token format. | |||||||||||||
| draft-moccia-dkim2-deployment-profile-07.txt | ||||||||||||||
| A Deployment Profile for DKIM2 via Milter Interface | ||||||||||||||
|
This document defines a deployment profile for DomainKeys Identified Mail v2 (DKIM2) that is implementable via the existing milter interface without modifications to Mail Transfer Agent (MTA) core software. It identifies a mandatory core profile (DKIM2-core) covering envelope binding, chain of custody, header accountability, replay prevention and DSN authentication and an optional extended profile (DKIM2-extended) covering body recipes and Message-Instance headers. The separation is motivated by deployment realism: the core profile addresses the primary threat models identified in the DKIM2 motivation document and is deployable incrementally across heterogeneous infrastructure, including small operators, universities and research institutions, using the same milter-based deployment model that has proven effective for DKIM1 and ARC. The intent of this document is not to obstruct DKIM2 but to make it deployable. DKIM2-core can be deployed incrementally across the heterogeneous ecosystem in a short timeframe. DKIM2-extended requires significantly longer implementation cycles and may not be deployable in jurisdictions with stricter privacy requirements. Both profiles are part of DKIM2 - the separation serves adoption, not opposition. | |||||||||||||
| draft-mohiuddin-mcp-security-considerations-00.txt | ||||||||||||||
| Security Considerations for Model Context Protocol (MCP) Implementations in AI Agent Systems | ||||||||||||||
|
The Model Context Protocol (MCP) connects large language models (LLMs) to external tools, data sources, and services. The MCP specification does not define normative security requirements. This document analyzes recurring vulnerability classes that have been publicly reported in MCP server implementations, describes an automated detection approach implemented in the open-source tool mcp- safeguard, and proposes security considerations and mitigations for implementors and operators. The document also describes Protocol Pivoting, a cross-protocol lateral-movement pattern in systems that compose MCP with other agent protocols. | |||||||||||||
| draft-mondal-llm-serving-workload-profiles-00.txt | ||||||||||||||
| Benchmarking Workload Profiles for Large Language Model Serving | ||||||||||||||
|
This document defines standard workload profiles for benchmarking Large Language Model (LLM) inference serving systems. Each profile represents one class of production workload. A profile is defined by its input and output token distribution, output structure, latency sensitivity, concurrency pattern, and caching behavior. Profiles are organized into six groups: Non-Generative, Minimal Output, Interactive Streaming, Prefill-Heavy Generative, Decode-Heavy Generative, and Multi-Step Chained. This document works with "Benchmarking Methodology for Large Language Model Serving" [LLM-METHOD]. It specifies the workloads that the methodology's tests SHOULD be run against. | |||||||||||||
| draft-montero-uto-03.txt | ||||||||||||||
| Unified Transition Overlay (UTO): A Stateless Cross-Version Transition Mechanism for IPv4/IPv6 | ||||||||||||||
|
This document specifies Unified Transition Overlay (UTO), a stateless encapsulation-plus-translation mechanism that enables bidirectional communication between IPv4-only and IPv6-only hosts across a transit network whose forwarding plane uses the opposite IP version. UTO carries the native source and destination addresses of the communicating hosts in a compact, variable-length overlay header. The original packet is tunneled between UTO-Gateways (UGWs) across the transit network and is converted to the destination's address family by a single stateless header translation performed only at the egress UGW. UTO requires no DNS64, no stateful per-flow translation in the common IPv4-to-IPv6 direction, and no changes to backbone routers or end-host stacks. The transit network forwards only pure IPv4 or pure IPv6 packets. | |||||||||||||
| draft-moonesamy-authorship-ietf-00.txt | ||||||||||||||
| Reflections on IETF Authorship | ||||||||||||||
|
[RFC825] was intended to provide guidance to authors of future RFCs. The memo also listed several reasons for publishing a memo as an RFC. It did not discuss who would be listed as author. This memo discusses authorship within the IETF and the use of generative Artificial Intelligence for IETF RFCs. | |||||||||||||
| draft-moore-green-mechanical-displacement-00.txt | ||||||||||||||
| Resource-Aware Routing and Mechanical Displacement for Energy-Efficient Networking (GREEN) | ||||||||||||||
|
The evolving draft-ietf-green-framework provides necessary YANG data models for monitoring Device Level Energy Efficiency (DLEE) and Component Level Energy Efficiency (CLEE). However, mitigating high- volume East-West traffic (e.g., massive inference synchronization) during peak grid carbon-intensity remains a structural challenge. This document proposes an architectural extension utilizing Delay- Tolerant Networking (DTN). It introduces "Mechanical Displacement"—the physical routing of encrypted cold data via autonomous or commercial logistics—as a zero-marginal-emission routing path, managed by hardware-rooted out-of-band blind packet switching. | |||||||||||||
| draft-mora-oauth-entity-profiles-01.txt | ||||||||||||||
| OAuth 2.0 Entity Profiles | ||||||||||||||
|
This specification introduces Entity Profiles as a mechanism to categorize OAuth 2.0 entities—clients and subjects—based on their operational context. Entity Profiles provide structured descriptors for the client initiating the OAuth flow and the subject represented in tokens. This document defines new JWT Claim names and metadata parameters for use in JWTs issued or consumed in OAuth flows, including but not limited to access tokens, ID tokens, JWT authorization grant assertions, and transaction tokens, as well as in token introspection responses, dynamic client registration, and Authorization Server metadata. It also defines vocabulary for classifying acting entities within delegation chains. | |||||||||||||
| draft-morand-http-digest-2g-aka-05.txt | ||||||||||||||
| Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA) | ||||||||||||||
|
This document specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. | |||||||||||||
| draft-morgan-ten64-00.txt | ||||||||||||||
| Text Encoded Base 64 Numbers (Ten64) | ||||||||||||||
|
Ten64 is a positional numeral system for representing numeric values with an alphabet of 64 characters (aka. radix/base 64). However, unlike most positional number systems, the characters are written in ascending (aka. big-endian, network-order) and NOT descending order. The main differences are the use of sextets (six bits) instead of octets (aka. bytes). Similar to hexadecimal, Ten64 can be used to create binary strings of arbitrary length. Ten64 can encode one or more Modern Western Numbers (aka. Arabic, Vedic), interpreting the characters respective composite big-endian binary as a one or more Modern Western Numbers. The motivation for Ten64 is to encode numbers in a compact and human- readable format similar to Base58. However, Ten64 is designed to be optimized for use with numbers commonly used in identifiers, such as DIDs, DOIDs, IANA OIDs, UUIDs, dates, time(stamp)s, points, and more. Unlike Base58, and more like hexadecimal Ten64 aligns the Modern Western Numerals with the respective big-ending binary (i.e.; 0 → 0, 1 → 1, 2 → 11, etc). Finally, Ten64 provides a disk-based number encoding system for huge numbers and number streams. | |||||||||||||
| draft-moros-oauth-browser-session-handoff-00.txt | ||||||||||||||
| Browser Session Establishment Using OAuth 2.0 Token Exchange and Short-Lived Authorization Codes | ||||||||||||||
|
This document specifies a usage profile that composes OAuth 2.0 Token Exchange [RFC8693] with a short-lived, single-use authorization code to establish an authenticated browser session at a Relying Party (RP) on behalf of a user authenticated at an Identity Provider (IdP) operating an independent OAuth 2.0 Security Token Service (STS). The server-to-server leg uses RFC 8693 to convey user identity and authorization context to the RP's STS, which issues an RP-scoped access token. A short-lived opaque code is then used to mediate delivery of session state into the user's browser without ever exposing the access token on the front channel. The profile is designed to avoid the class of front-channel token leakage (browser history, HTTP Referer header, intermediary access logs) that motivated the deprecation of the OAuth 2.0 implicit grant in [RFC9700]. The profile also defines a minimum claims contract on the RP-issued access token to enable stateless authorization enforcement at the RP without synchronous callbacks to the IdP. | |||||||||||||
| draft-morrison-agent-channel-fan-out-01.txt | ||||||||||||||
| An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions | ||||||||||||||
|
This memo specifies an application-layer frame format and a delivery model by which the several concurrent agentic sessions of a single identity-bound principal, and the recognised members of an organisational identity substrate, exchange short structured messages. The frame, termed the agent-channel frame, is a transport envelope: it carries a closed-catalogue kind discriminator, a structured per-kind payload, an identity attribution pair, and an inline provenance block. Delivery is fan-out: a sender names a recipient scope rather than a single endpoint, and the scope is expanded at delivery time against the recipient's subscriptions. Recipients receive frames over a per-handle Server-Sent Events stream and MAY narrow what they receive with a subscribe-time filter expression. Frames are ephemeral routing units; the memo specifies only the wire envelope, the scope-expansion grammar, the subscribe filter grammar, and the delivery semantics. Frame persistence, where an implementation chooses to retain frames for replay, is out of scope and is not specified. The memo composes with the handle namespace of [IDPRONOUNS], the discovery surface of [MCPDNS], and the cross-organisational ceremony of [IDACCORD]; no new transport and no new handle category is introduced. | |||||||||||||
| draft-morrison-alter-uri-scheme-03.txt | ||||||||||||||
| The 'alter' URI Scheme for Dispatchable ~handle References | ||||||||||||||
|
This document defines the alter URI scheme as a dispatchable reference syntax for ~handle identity references published under the DNS substrate defined in [MCPDNS]. An alter: URI binds a textual ~handle reference to a resolution and verification procedure that retrieves the handle's envelope from the publishing zone, validates the envelope's signature chain, and dispatches the result to an operating-system URI handler. The reference may be scoped to an organisation, narrowed to a named facet of the identity, and addressed to a typed action surface. The scheme is the addressing form of the ~handle@org:facet/action reference; its resolution semantics are those of [MCPDNS], reused without modification. The scheme is provider-neutral, introduces no new cryptographic primitive, and reuses the resolution and verification procedures of [MCPDNS] without modification. The principal contribution is a single, self-verifying dispatch surface for handle-typed references: clicking, typing, or scanning an alter: URI yields a verified handle resolution rather than a free-text string or an unauthenticated fetch, and where an action is addressed it yields a verify-before- side-effect dispatch. This document requests provisional registration of the alter scheme with IANA per [RFC7595] Section 3. | |||||||||||||
| draft-morrison-binding-moment-envelope-02.txt | ||||||||||||||
| The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation | ||||||||||||||
|
This memo specifies the briefing-and-binding envelope: a delivery contract for the wire-level structure by which an artificial- intelligence agent surfaces a consequential decision to the human principal it acts for, and by which the principal commits, declines, amends, or rejects that decision. The envelope carries eight named slots (a synopsis, findings, recommendations, an offer of detail, a question stem, a set of options each marked with its own reasoning, a single recommended option, and a pair of escape hatches) and is emitted as a structured field of a Model Context Protocol [MCP] tool result. The contribution is the delivery contract itself: a single renderer-agnostic envelope so that the briefing an agent delivers and the binding a principal commits back have one machine-checkable shape across every consuming surface. The central element is the dual-veto handshake: one escape hatch lets the principal revise the answer space while accepting the question; the other lets the principal reject the question itself and reopen deliberation. Either party may veto. The memo defines a content digest over the envelope, canonicalized under JCS and hashed with SHA-256, so that a resolution names the exact envelope it resolves and an external receipt can reference that envelope by digest. The memo is Informational. No new transport is introduced; the envelope composes with the handle namespace of [IDPRONOUNS] and the MCP tool surface of [POLICYPROV]. | |||||||||||||
| draft-morrison-compute-location-gate-01.txt | ||||||||||||||
| The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes | ||||||||||||||
|
This memo specifies the compute-location gate: a mechanism by which a client and an identity-inference server negotiate, at the wire layer and before any inference is performed, the location at which an identity inference will compute, as a deterministic function of the provenance class of the input signal. Three provenance classes are distinguished. Active inference, initiated by the inferred-about principal, MAY compute server-side and produce a server-held identity vector. Passive aggregate observation over a cohort no smaller than a declared minimum MAY compute server-side but yields only a population-level observation that is not attributable to an individual. Passive individual observation is local-only: it is computed and retained on the device that observed it and is never transmitted to a server. The gate is enforced by consent-class matching and by a wire-layer refusal returned when a requested provenance class is not consented; it is not enforced by any cryptographic proof concerning data that was not used. The memo is Informational. The wire surface composes with the discovery mechanism of [MCPDNS], the handle namespace of [IDPRONOUNS], and the organisational policy substrate of [POLICYPROV]; no new transport is introduced. | |||||||||||||
| draft-morrison-consent-settlement-05.txt | ||||||||||||||
| Consent-Bound Identity Disclosure with Subject Settlement for HTTP-Native Agent Payments | ||||||||||||||
|
This memo specifies an extension to HTTP-native agent payment protocols by which the disclosure of an identity attribute about a human subject is bound to that subject's recorded consent and settled, in part, to that subject. When an agent pays to read an identity attribute about a person, the extension requires that the read carry a reference to a scoped, revocable consent grant issued by the subject, and it requires that the payment's settlement instruction name the subject as a beneficiary of a share of the read's price greater than the shares of all other parties combined. The extension composes above an identity- attestation envelope (which asserts who a credential is about) and above an HTTP-native payment flow (which moves value for the read); it adds the two functions neither layer provides: consent capture at disclosure time and settlement to the data subject. The wire additions are an advertisement in the server's payment-required response, a consent- grant reference echoed in the client's payment payload, and a settlement instruction enumerating subject beneficiary roles. The extension is settlement-network-agnostic and attestation-format- agnostic. The memo is Informational; the underlying COSE and CBOR formats are normative per [RFC9052] and [RFC8949], and the HTTP semantics are normative per [RFC9110]. | |||||||||||||
| draft-morrison-identity-accord-03.txt | ||||||||||||||
| Identity Accord Protocol: A Peer Ceremony for Bilateral Agreements Between Identity-Substrate-Bound Principals | ||||||||||||||
|
This memo specifies the Identity Accord Protocol, a peer ceremony by which two principals, each represented by an organisational identity substrate and acting under a recorded delegation from a legal entity, execute a bilateral agreement as a portable, self-verifying COSE- signed CBOR document. The protocol composes DNS-based substrate discovery, Ed25519 sovereign signatures, an append-only identity log, and a tamper-evidence descriptor quorum into a single artefact that is verifiable by any third party with access to the public DNS, the parties' identity logs, and an on-chain anchor of the agreement's content hash. The protocol does not require a central registry, a designated verifier, or any infrastructure operated by the specification's author; verification succeeds when the author's reference deployment is offline. The canonical bilateral target is a mutual non-disclosure agreement, but the wire format generalises to any bilateral consent envelope between two legal entities each represented by an identity substrate. An associated MCP tool surface, an associated pre-send enforcement gate, and an associated disclosure-ledger schema are specified, all of which are optional layers above the wire format. The memo is Informational; the underlying COSE and CBOR formats are normative per [RFC9052] and [RFC8949]. | |||||||||||||
| draft-morrison-identity-attributed-commits-02.txt | ||||||||||||||
| Identity-Attributed Git Commits via Tier-Structured Trailers | ||||||||||||||
|
This document defines a git commit trailer grammar for identity- attributed contributions using the ~handle identity primitive defined in [MCPDNS]. The grammar binds sovereign actors, automated bots, and AI instruments to specific commits via three tier-structured trailers (Acted-By, Executed-By, Drafted-With) and three optional cryptographic trailers (Identity-Signature, Identity-Key-Id, Identity-Anchor). The signature is computed with Ed25519 over the commit's tree hash rather than its commit hash, preserving attribution across rebase, cherry-pick, and squash merge operations. Conformant parsers reject cross-tier category errors (e.g., an Instrument-tier handle in an Acted-By slot) as malformed. The mechanism is provider-neutral, depends only on DNS [RFC1035] and the ~handle resolution algorithm of [MCPDNS], and requires no central authority or platform-specific verification service. | |||||||||||||
| draft-morrison-identity-pronouns-02.txt | ||||||||||||||
| Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems | ||||||||||||||
|
This document defines an identity pronoun grammar as a reference axis orthogonal to the ~handle identity tier taxonomy defined in [MCPDNS] and [IDCOMMITS]. A pronoun is a session-scoped reference that resolves client-side to a concrete handle using local session state before any cryptographic, DNS, or federation operation. The entity- class taxonomy (Sovereign, Bot, Instrument) is unchanged; this specification introduces Absolute vs Pronoun as an orthogonal axis. A pronoun MUST NOT appear in a capability token, in a DNS record, in an Accord signature, or in any inter-organisational protocol payload. The reference implementation defines a single Wave-1 pronoun, ~org, that resolves to the concrete handle of the organisation bound to the caller's current session. An appendix defines a relative-path pronoun grammar (e.g. ~./architect, ~../weaver) as a non-normative design surface for future work. The mechanism is provider-neutral, introduces no new cryptographic primitive, and imposes zero new load on DNS, capability-token issuers, or federated resolvers. | |||||||||||||
| draft-morrison-live-reference-resolution-00.txt | ||||||||||||||
| Live Reference Resolution for Autonomous Agent Beliefs | ||||||||||||||
|
A recurring class of autonomous-agent failure arises when an agent acts on a belief read from a cached, derived, or proxy copy that has silently diverged from the authority the belief claims to represent. This document describes a reference-resolution discipline for the working beliefs an agent reasons and acts from. Each belief is held as a reference to a single named lowest authority and is resolved live at the point of use, with verification. When the authority is unobservable or the resolved value is stale, the belief takes an explicit uncertainty state rather than a prior cached value; that state propagates to any belief derived from it, and an uncertain belief feeding a costly or irreversible act blocks or escalates rather than proceeding. Every resolution chain terminates in a single self-authorising root. The document is Informational. It records a discipline and a vocabulary; it does not define a wire protocol. | |||||||||||||
| draft-morrison-mcp-dns-discovery-05.txt | ||||||||||||||
| Discovery of Model Context Protocol Servers via DNS TXT Records | ||||||||||||||
|
This document defines a DNS-based mechanism for discovering Model Context Protocol (MCP) servers, the identity of the organisations that operate them, and a cryptographic identity envelope bound to an individual Sovereign-tier ~handle published under the same zone. Three TXT records are defined. _mcp. | |||||||||||||
| draft-morrison-mcp-tool-surface-names-registry-01.txt | ||||||||||||||
| An IANA Registry for Model Context Protocol Tool Surface Names | ||||||||||||||
|
This document requests the establishment of an IANA registry for Model Context Protocol [MCP-SPEC] tool surface names. A tool surface name is the wire-level identifier by which a client invokes a typed capability on an MCP server. Existing Morrison- family Internet- Drafts ([ORGALTER]) request IANA registration of specific surface names against a registry that does not yet exist. This document establishes the registry mechanism so that subsequent specifications can register names without restating the registry's structure or registration procedure. The registry uses Specification Required registration with a Designated Expert pool [RFC8126]. Initial contents are the four surface names registered by [ORGALTER]. Vendor-prefix conventions are recommended but not mandated. | |||||||||||||
| draft-morrison-morning-brief-01.txt | ||||||||||||||
| The Morning Brief: A Federated,Identity-Attested Situational-Awareness Payload | ||||||||||||||
|
This document defines the Morning Brief: a federated, identity- attested situational-awareness payload exchanged between organisations, their agents, and peer agents operating under an Identity Accord [ACCORD]. A Morning Brief carries a signed, bounded- lifetime summary of signals, escalations, decisions, and optional commerce quotes from one ~handle to another. Every signal entry carries a provenance_class distinguishing active self-report, passive aggregate observation, and passive individual observation; the last of these is forbidden on the wire and rejected at the grammar level. Readers present a capability token scoped by (category, provenance_class) that gates release BEFORE payload emission, not after. The payload is envelope-signed with COSE_Sign1 [RFC9052] over a JCS-canonicalised [RFC8785] representation, bound to the issuer's Sovereign-tier handle per [IDCOMMITS]. Briefs carry a mandatory not_after (default 24h) and reference a revocation endpoint discovered via DNS TXT per [MCPDNS]. The document defines the wire format only; rendering, storage, and retention are out of scope. | |||||||||||||
| draft-morrison-org-alter-policy-provision-03.txt | ||||||||||||||
| Policy Provision and Governance Inheritance from an Organisational Identity Substrate | ||||||||||||||
|
This memo specifies how an artificial-intelligence agent runtime, bound at instantiation to a principal identity handle, resolves at session initialisation a target organisational identity substrate from a manifest source bound to the runtime's working context and retrieves from that substrate a typed policy stack comprising a handbook artefact, a standard-operating-procedure registry pointer, an enforcement-gate specification, and an audit-signal ingestion endpoint. The policy stack is then applied as runtime constraints on subsequent tool invocations, with audit signals emitted back to the same substrate. Policy provision occurs in the same act of session initialisation as principal identification, rather than as a separate ceremony against a side-channel governance plane. A principal concurrently bound to multiple organisational substrates operates the runtime under a deterministic composition of the several policy stacks, with cross-organisational residual conflicts routed to the peer-protocol Identity Accord ceremony [IDACCORD] rather than to a meta-federation authority. The memo is Informational. The wire surface relies on the DNS-based discovery of [MCPDNS] and the handle namespace of [IDPRONOUNS]; no new transport is introduced. | |||||||||||||
| draft-morrison-ot-command-authority-02.txt | ||||||||||||||
| Consented and Attributable Agent Authority for Operational-Technology Control Actions | ||||||||||||||
|
This memo specifies a binding profile by which a control action issued to an operational-technology (OT) or industrial control system on the authority of a software agent is refused unless it carries a verifiable statement of who the agent is, which human principal it acts for, whether that principal authorised this specific action on this specific asset, whether a named human signed off on the action where its risk class requires it, and an append-only record sufficient to attribute the action afterward. The profile does not invent new cryptography or a new identity mechanism. It composes primitives specified elsewhere, DNSSEC-rooted agent discovery, a scoped and revocable authorisation grant, a named-human authorization receipt bound into the record as human-authorization evidence, and an append-only transparency record, into a single structure, the Command Authority Envelope, that an enforcement point evaluates and, on any missing or invalid binding, refuses. The profile is availability- first and fails closed on authority, never on safety: it MUST NOT be placed in the trip path of a safety function. The memo maps the profile onto the identification, use-control, and audit requirements that the IEC 62443 and NERC CIP frameworks state but do not give a wire mechanism for. A neighbouring proposal gates safety-critical commands on an agent's trust level; this profile takes the opposite position, and states why. The methods by which a principal's identity is inferred are out of scope by construction. | |||||||||||||
| draft-morrison-reviewed-by-trailer-02.txt | ||||||||||||||
| Reviewed-By Trailer: Sovereign-Portable Peer-Review Attribution for Content-Hash-Bound Artefacts | ||||||||||||||
|
This document defines a trailer grammar for sovereign-portable peer review as an extension of the identity-attributed commit grammar in [COMMITS]. The grammar introduces one required trailer (Reviewed- By:) and three optional companion trailers (Review-Stance:, Review- Of:, Witnessed-By:) that bind a Sovereign-tier ~handle to a specific act of review over a specific content artefact, cryptographically signed using the Ed25519 mechanism of [COMMITS]. The mechanism applies uniformly to git commits, document manifests, pre-prints, patent disclosures, and any other content-addressable artefact. Reviewer reputation accumulates on the sovereign handle rather than on a publisher's platform, making reviewer trust portable across journals, pre-print servers, and private review contexts. Pseudonymous review for anonymous peer-review processes is supported by permitting a Sovereign handle whose underlying party is concealed through out-of-band key custody, preserving full cryptographic verifiability of the review act without disclosing the reviewer's underlying identity. The grammar is positioned as complementary to CRediT [CREDIT], ORCID [ORCID], and DOI [DOI] attribution infrastructure, not as a replacement for them. | |||||||||||||
| draft-morrison-solo-agent-earn-registration-01.txt | ||||||||||||||
| Registration of Owner-Less Agents as Economic Principals: A Payment-Gated Admission Profile for Transparency Services | ||||||||||||||
|
This memo describes a profile by which an autonomous agent that has no human or organisational principal at the root of its delegation chain registers itself, on its own behalf, as an economic principal in a transparency service, and by which that registration is the specific act that makes the agent eligible to be paid for subsequent reads of its own identity record. Admission of the agent's Signed Statement to the transparency service is gated on settlement of an HTTP payment challenge returned with the 402 (Payment Required) status. The profile makes no change to the registration semantics of the underlying transparency service: payment is expressed as an operator Registration Policy and authentication-layer concern, and where the payment is authoritative to the admission decision the payment proof is carried as an authenticated input committed to the service's verifiable data structure, so that admission remains a deterministic function of committed inputs and stays replayable by an auditor. The profile is positioned against the current agent- identity drafts, which either require a human principal at the root of the chain or leave the owner-less case undefined; it occupies that undefined seam without contradicting them. This document is Informational. | |||||||||||||
| draft-morrison-substrate-observation-02.txt | ||||||||||||||
| Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions | ||||||||||||||
|
This memo articulates a coordination-protocol anti-pattern observed in cross-tool agentic systems and describes a substrate-observation alternative that does not require negotiating a wire format between heterogeneous concurrent sessions of an identity-bound principal. The memo is Informational. No protocol element is being proposed for standardisation; the contribution is the opposite, a delineation of what should NOT be standardised, and why, with a reference to the substrate-physics primitives that take its place. Companion memos in the morrison-* family describe the identity primitives this memo presumes; specifically, this memo relies on the ~handle namespace established in [IDPRONOUNS] and the per-principal identity substrate referenced in [IDACCORD]. | |||||||||||||
| draft-morrison-substrate-provenance-grammar-02.txt | ||||||||||||||
| Substrate-Provenance Annotation Grammar for Large-Language-Model Output | ||||||||||||||
|
This memo specifies a wire-level annotation grammar by which a large- language-model output may carry, at emission and at the granularity of an individual assertion, a provenance label drawn from a closed enumerated vocabulary of substrate-class identifiers. The memo defines the closed vocabulary, the per-assertion attachment form, the admissibility discipline a relying party MAY apply to the labels, and two terminal output states, UNVERIFIED-INFERENCE and DECAYED-TO- UNCERTAINTY, equal-rank with assertion and denial. The memo does not specify what an inference system MUST do; it specifies the wire grammar by which a relying party may inspect what the inference system DID with respect to the substrates it consulted. The memo is Informational. | |||||||||||||
| draft-morrow-sogomonian-exec-outcome-attest-00.txt | ||||||||||||||
| Execution Outcome Attestation for AI Agents and Automated Systems | ||||||||||||||
|
Current attestation frameworks establish that a system or agent is trustworthy at a point in time. They do not address whether that system actually performed a claimed action or whether the outcome of that action can be independently verified. This document defines execution outcome verification as a first-class concept, separate from identity attestation and communication transport. It introduces the execution receipt as a minimal composable primitive, provides a formal abstract model, and maps the model to concrete realizations including SCITT transparency logs, tightly-coupled direct verification, append-only local logs, and TEE-internal receipts. | |||||||||||||
| draft-moskowitz-ads-b-auth-03.txt | ||||||||||||||
| ADS-B Authentication | ||||||||||||||
|
Automatic Dependent Surveillance – Broadcast (ADS-B) is a surveillance technology mandated in many airspaces. It is now widely deployed but suffers from a lack of security and privacy. From a security point of view, it is relatively easy to spoof ADS-B messages with readily available hardware and software. From a privacy point of view, every ADS-B message contains the aircraft's assigned 24-bit ICAO address, a unique identifier that can be cross-referenced with external databases (e.g. aircraft registries) to reveal the owner, and can be used to track when and where a specific aircraft has flown. In addition, the main transmission medium used for ADS-B, the 1090 MHz frequency, on which messages are broadcast using the Extended Squitter (1090ES) format, is approaching saturation in some parts of the world due to the volume of ADS-B and other protocol messages, resulting in packet loss in certain areas. This paper presents the IETF TESLA protocol along with X.509 certificates issued by ICAO member states for each aircraft to authenticate all ADS-B messaging. It leverages the 8PSK phase overlay (PO) scheme proposed in the Minimum Operational Performance Standards (MOPS) for ADS-B (RTCA [DO-260C]), which enables 1090ES ADS-B transmissions to convey three times more information, to support the transmission of the extra security information required by the authentication scheme. By doing so, the impact of authentication on channel usage is negligible. Beyond message authentication, this scheme protocol has two important additional benefits: 1) the possibility to implement a Flight Authorization scheme, allowing ATC and intercepting aircraft to not only authenticate an aircraft but to verify that it is authorizes to conduct that flight and 2) a privacy-preserving methodology that assigns random 24-bit identifiers to designated aircraft while still enabling blind authentication of their ADS-B transmissions. | |||||||||||||
| draft-moskowitz-drip-a2x-adhoc-session-08.txt | ||||||||||||||
| Aircraft to Anything AdHoc Broadcasts and Session | ||||||||||||||
|
Aircraft-to-anything (A2X) communications are often single broadcast messages that to be trustable, need to be signed with expensive (in cpu and payload size) asymmetric cryptography. There are also frequent cases of extended exchanges between two devices where trust can be maintained via a lower cost symmetric key protect flow. This document shows both how to secure A2X broadcast messages with DRIP Entity Tags (DET) and DRIP Endorsement objects and to leverage these to create an AdHoc session key for just such a communication flow. There is also provision for DETs within X.509 certificates, encoded in c509, as an alternative DET trust model. | |||||||||||||
| draft-moskowitz-drip-crowd-sourced-rid-16.txt | ||||||||||||||
| Crowd Sourced Remote ID | ||||||||||||||
|
This document describes using the ASTM Broadcast Remote ID (B-RID) specification in a "crowd sourced" smart phone or fixed receiver asset environment to provide much of the ASTM and FAA envisioned Network Remote ID (Net-RID) functionality. This crowd sourced B-RID (CS-RID) data will use multilateration to add a level of reliability in the location data on the Uncrewed Aircraft (UA). The crowd sourced environment will also provide a monitoring coverage map to authorized observers. | |||||||||||||
| draft-moskowitz-drip-efficient-a2g-comm-06.txt | ||||||||||||||
| Efficient Air-Ground Communications | ||||||||||||||
|
This document defines protocols to provide efficient air-ground communications without associated need for aircraft to maintain stateful connection to any tower infrastructure. Instead, a secure source-routed ground infrastructure will not only provide the needed routing intelligence, but also reliable packet delivery through inclusion of Automatic Repeat reQuest (ARQ) and Forward Error Correction (FEC) protocols to address both reliable wireless packet delivery, and assured terrestrial packet delivery. | |||||||||||||
| draft-moskowitz-drip-operator-privacy-18.txt | ||||||||||||||
| UAS Operator Privacy for RemoteID Messages | ||||||||||||||
|
This document describes a method of providing privacy for UAS Operator/Pilot information specified in the ASTM UAS Remote ID and Tracking messages. This is achieved by encrypting, in place, those fields containing Operator sensitive data using a hybrid ECIES. | |||||||||||||
| draft-moskowitz-drip-stateless-nrid-03.txt | ||||||||||||||
| Secure UAS Stateless Network RID | ||||||||||||||
|
This document defines a stateless transport mechanism and message content between an Uncrewed Aircraft System (UAS) and its UAS Service Supplier (USS) for Network Remote ID (Net-RID) messages. It leverages the Broadcast Remote ID (B-RID) messages as constructed by the UA, or constructed by the Ground Control Station (GCS) from the Command-and-Control (C2) messages that are then sent directly over UDP from the UAS. These messages are authenticated by the DRIP Authentication messages if originating from the UA. When originating from the GCS, CBOR Web Tokens (CWT) signed by the GCS's DRIP Entity Tag (DET), are used. Transport privacy is out-of-scope in this approach per the stateless design. Some proposals are offered for data privacy that require some minimal state. | |||||||||||||
| draft-moskowitz-hip-fast-mobility-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moskowitz-ipsecme-rfc7402-beet-update-03.txt | ||||||||||||||
| 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] | |||||||||||||
| draft-mott-cose-sqisign-08.txt | ||||||||||||||
| CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for SQIsign | ||||||||||||||
|
*NOTE: This document describes a signature scheme based on the SQIsign algorithm currently under evaluation in the 3rd round NIST Post-Quantum Cryptography standardization process. Be aware that the underlying primitive may change as a result of that process.* This document specifies the algorithm encodings and representations for the SQIsign digital signature scheme within the CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) frameworks. SQIsign is an isogeny-based post-quantum signature scheme that provides an unusually compact signature and public key size among candidates of the NIST Post-Quantum Cryptography (PQC) standardization and on-ramp-to-standardization processes. The standardization of SQIsign will be helpful to address current infrastructure bottlenecks, specifically the FIDO2 CTAP2 specification used by many in-service devices. This document clarifies that SQIsign does not expose the auxiliary torsion-point information exploited in the SIDH/SIKE attacks. Consequently, the specific attack techniques of Castryck–Decru do not directly apply. However, the scheme remains subject to ongoing cryptanalysis of isogeny-based constructions. By establishing stable COSE and JOSE identifiers, this document ensures the interoperability required for the seamless integration of post-quantum security into high-density, bandwidth-constrained, and legacy-compatible hardware environments. | |||||||||||||
| draft-motters-ruuid-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-moussa-dawn-gap-analysis-01.txt | ||||||||||||||
| Gap Analysis and Applicability Statement for Discovery Protocols of Agents,Workloads,and Named Entities (DAWN) | ||||||||||||||
|
This Internet-Draft provides a gap analysis and applicability statement that maps existing Discovery Mechanisms and protocols to the DAWN problem statement and discovery requirements. The analysis evaluates security, privacy, applicability, flexibility, and suitability of existing standardized, non-standardized, and proposed discovery solutions and protocols to the DAWN problem statement and REQ-DISC corpus. It identifies high priority gaps, proposes mitigations and hybrid patterns, and serves as reference for future prototyping and development. The intention is for this draft to evolve as new solutions come to existence. | |||||||||||||
| draft-mozley-aidiscovery-01.txt | ||||||||||||||
| AI Agent Discovery (AID) Problem Statement | ||||||||||||||
|
With the proliferation of AI agents comes a need for mechanisms to support agent-to-agent discovery. This document discusses the scope, requirements and considerations to support discovery processes so that these are not reliant on manually defined configurations and relationships. | |||||||||||||
| draft-mozleywilliams-dnsop-dnsaid-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-mp-agntcy-ads-02.txt | ||||||||||||||
| Agent Directory Service | ||||||||||||||
|
The Agent Directory Service (ADS) is a distributed directory service designed to store metadata for AI agent applications. This metadata, stored as directory records, enables the discovery of agent applications with specific skills for solving various problems. The implementation features distributed directories that interconnect through a content-routing protocol. | |||||||||||||
| draft-mpsb-agntcy-messaging-02.txt | ||||||||||||||
| An Overview of Messaging Systems and Their Applicability to Agentic AI | ||||||||||||||
|
Agentic AI systems require messaging infrastructure that supports real-time collaboration, high-volume streaming, and dynamic group coordination across distributed networks. Traditional protocols like AMQP [AMQP], MQTT [MQTT], and NATS [NATS] address some requirements but fall short on security, particularly regarding post-compromise protection and forward secrecy essential for autonomous agents handling sensitive data. This document analyzes six messaging protocols—AMQP, MQTT, NATS, AMQP over WebSockets, Kafka, and AGNTCY SLIM—across dimensions critical for GenAI agent systems: streaming performance, delivery guarantees, security models, and operational complexity. We examine how each protocol's design decisions impact agentic AI deployments, from lightweight edge computing scenarios to large-scale multi- organizational collaborations. AGNTCY SLIM emerges as a purpose-built solution, integrating Message Layer Security (MLS) [RFC9420] with gRPC [gRPC] over HTTP/2 [RFC9113] to provide end-to-end encryption with forward secrecy, efficient streaming, and OAuth-based authentication [RFC6749]. Unlike transport-layer security approaches, SLIM's MLS implementation ensures secure communication even through untrusted intermediaries while supporting dynamic group membership changes essential for collaborative AI agents. | |||||||||||||
| draft-mpsb-agntcy-slim-02.txt | ||||||||||||||
| Secure Low-Latency Interactive Messaging (SLIM) | ||||||||||||||
|
This document specifies the Secure Low-Latency Interactive Messaging (SLIM), a protocol designed to support real-time interactive AI applications at scale. SLIM provides the transport layer for agent protocols (for example, A2A and MCP), combining gRPC over HTTP/2 and HTTP/3 with secure messaging, group communication, and native RPC semantics. The protocol provides mechanisms for connection management, stream multiplexing, and flow control while maintaining compatibility with existing gRPC deployments and supporting end-to- end encryption via MLS. | |||||||||||||
| draft-ms-hpke-auth-modes-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-msebenzi-evidence-action-00.txt | ||||||||||||||
| The evidence.* Family: Post-Hoc,Independently Recomputable Evidence Records for AI Agent Actions | ||||||||||||||
|
Autonomous agents act through tool invocations whose consequences outlive the sessions that produce them. Pre-action constraint families gate whether an agent may act: environment.* attests boolean world-state, and verification.* attests calibrated confidence over factual claims. No sibling family records, under equivalent verification discipline, what the agent then did. This document defines the evidence.* family: append-only, hash-chained, signature- bound evidence records of agent actions, designed so that a third party can recompute every verdict from signed primitives and a published key, without trusting the operator's runtime. It defines the family's membership criterion (independent recomputability with fail-closed verification), the family-wide record vocabulary and canonicalization discipline, a tri-state verification protocol (VALID, INVALID, UNVERIFIABLE), composition with the pre-action sibling families, and the conformance-vector discipline under which independent implementations demonstrate byte-level agreement. One reference record type, evidence.action, is specified together with its frozen conformance corpus. This document deliberately states what an evidence record does not prove. | |||||||||||||
| draft-muhammad-pquip-apkp-pqcprotocol-00.txt | ||||||||||||||
| New Pure Post-Quantum Protocol Specification | ||||||||||||||
|
The Abdelaziz Pure Key Protocol, a.k.a. APKP, was designed to protect systems with pure post-quantum mechanics and transition to full PQC in the future. It is used in high-security environments to protect against quantum attacks. This doxument replaces and supersedes draft-muhammad-apkp-pqcprotocol and draft-muhammad-ahkp-pqcprotocol. | |||||||||||||
| draft-mukhtar-kinetic-identity-00.txt | ||||||||||||||
| Kinetic Identity Documents and Service Manifests | ||||||||||||||
|
This document specifies Kinetic Identity Documents (KIDs) and Capability Manifests, a higher-layer identity and service-discovery model for the Kinetic Network Protocol. A Kinetic name is a transferable human-readable alias. A KID is a persistent cryptographic identity. A Capability Manifest, signed by the KID, describes the services currently offered by that identity. This separation prevents applications from confusing a name with an identity and allows names to resolve to websites, APIs, messaging endpoints, storage systems, agents, and future services without changing the underlying naming protocol. | |||||||||||||
| draft-mukhtar-kinetic-network-00.txt | ||||||||||||||
| The Kinetic Network Protocol | ||||||||||||||
|
This document specifies the Kinetic Network Protocol, a decentralized naming and ownership protocol for binding human-readable names to cryptographic identity keys without a central registry, blockchain, or monetary renewal system. Kinetic uses a commit-reveal flow, verifiable delay functions (VDFs), signed heartbeat records, and redundant Distributed Hash Table (DHT) storage to make name acquisition sequential, verifiable, and resistant to front-running, mass registration, and stale-state capture. This document defines the protocol model, required records, validation rules, and security considerations for interoperable Kinetic network implementations. | |||||||||||||
| draft-muks-dns-filtering-05.txt | ||||||||||||||
| EDNS options for filtering information | ||||||||||||||
|
This memo documents EDNS options and methods that can be used to return information about filtered, blocked, or censored DNS responses. It complements the information provided in EDNS Extended DNS Error options [RFC8914]. | |||||||||||||
| draft-muks-dns-nta-feed-zones-00.txt | ||||||||||||||
| DNS NTA feed zones | ||||||||||||||
|
This memo documents a method for expressing a list of DNS negative trust anchors [RFC7646] inside a specially constructed DNS zone, that validating recursive name servers and other DNSSEC validators may configure negative trust anchors from. | |||||||||||||
| draft-munizaga-quic-alternative-server-address-01.txt | ||||||||||||||
| QUIC Alternative Server Address Frames | ||||||||||||||
|
This document specifies an extension to QUIC that allows a server to advertise a prioritized set of alternative addresses. This allows a client to migrate the connection as the availability or preference of server addresses changes. | |||||||||||||
| draft-munoz-schc-over-dts-iot-02.txt | ||||||||||||||
| Static Context Header Compression and Fragmentation ARQ/FEC mode | ||||||||||||||
|
This document defines a new fragmentation mode for the SCHC standard defined in RFC8724. The new fragmentation mode is designed for communications that require additional reliability mechanisms. The reliability is based on a hybrid ARQ/FEC type II mechanism that combines forward error correction (FEC) with adaptive retransmissions to achieve high reliability. | |||||||||||||
| draft-munoz-scitt-permit-profile-01.txt | ||||||||||||||
| A SCITT Profile for Pre-Execution AI Action Authorization Records | ||||||||||||||
|
This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. | |||||||||||||
| draft-munoz-wimse-authorization-evidence-01.txt | ||||||||||||||
| Signed Authorization-Evidence Records for WIMSE-Authorized AI Agent Actions | ||||||||||||||
|
This document specifies a companion profile to the AI Agent Authentication and Authorization draft [I-D.klrc-aiagent-auth], defining a signed authorization-evidence record produced by WIMSE- authorized AI agent actions. The evidence record (referred to as a Permit) cryptographically commits to the canonical bytes of the request authorized before dispatch and, via a paired Closure Record, to the recorded dispatched-request digest; it maps to and can satisfy the audit minimum requirements enumerated in Section 11 of the companion draft, and composes with HTTP Message Signatures, OAuth access tokens, and Shared Signals Framework eventing without requiring modifications to those existing standards. The profile is anchored in the SCITT profile defined in [I-D.munoz-scitt-permit-profile]. This revision also describes how WIMSE deployments compose with authorization-lineage evidence defined by the companion SCITT profile: workload identity, delegated subject context, runtime token claims, and HTTP Message Signature coverage become Verifier inputs for parent/child Permit relationships. | |||||||||||||
| draft-mututi-quip-02.txt | ||||||||||||||
| QUIC Identity Protocol | ||||||||||||||
|
QUIP is a brokerless federation protocol over QUIC. It provides portable Ed25519 identities, causal consistency via Dotted Version Vectors, and queueless transport via four explicit tiers with backpressure. QUIP replaces DNSSEC-based trust with Key Transparency + Trust-On-First-Use, enabling 99% deployability while improving security against registrar compromise. | |||||||||||||
| draft-mvieuille-kerpass-ephemsec-03.txt | ||||||||||||||
| KerPass EPHEMSEC One-Time Password Algorithm | ||||||||||||||
|
This document specifies EPHEMSEC, an algorithm for generating one- time passwords (OTPs) and one-time keys (OTKs). Unlike traditional OTP algorithms that rely solely on static shared secrets, EPHEMSEC uses public key cryptography, which simplifies secure deployment on authentication servers. EPHEMSEC also supports binding the generated OTP/OTK to contextual data. When this context is obtained and injected by a trusted agent, the resulting codes can be made resistant to phishing and man-in-the-middle attacks. Finally, EPHEMSEC includes a built-in time synchronization mechanism that embeds a synchronization hint into the generated output. This allows both parties to deterministically derive the same OTP/OTK value without requiring trial-and-error validation, enabling compatibility with protocols such as Password Authenticated Key Exchange (PAKE) and TLS with Pre-Shared Key (TLS-PSK) that require exact secret agreement. | |||||||||||||
| draft-mw-nmop-yang-ai-challenges-00.txt | ||||||||||||||
| Rethinking YANG-based Service and Network Management in the Era of Agentic AI | ||||||||||||||
|
The industry today is actively exploring the application of agentic AI to autonomous network operations. However, there is little attention given to the impacts that the introduction of agentic AI may impose on YANG modeling, and how YANG can be better leveraged to support AI-driven autonomous operations. Based on some end-to-end intent translation workflow analysis that engage YANG models across service, network, and device layers, this document identifies some critical gaps when AI agents generate and operate on YANG data. The purpose of this document is not to substantially redesign YANG or define a new data model language. Instead, it aims to facilitate discussion on how existing YANG ecosystems can be better leveraged in the context of agentic AI, and how complementary mechanisms can bridge these gaps while preserving YANG’s interoperability. | |||||||||||||
| draft-mw-oauth-actor-chain-01.txt | ||||||||||||||
| Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange | ||||||||||||||
|
Multi-hop service-to-service and agentic workflows often exchange OAuth access tokens across a sequence of actors. OAuth 2.0 Token Exchange permits an act claim, including nested prior actors, but it does not define interoperable rules for preserving, extending, disclosing, and validating a delegation path across successive exchanges. This document defines six actor-chain profiles for OAuth 2.0 Token Exchange: Declared Full Disclosure, Declared Subset Disclosure, Declared Actor-Only Disclosure, Verified Full Disclosure, Verified Subset Disclosure, and Verified Actor-Only Disclosure. The profiles preserve the existing meanings of sub, act, and may_act. They add explicit profile selection, a stable workflow actor-chain identifier, profile-controlled actor disclosure, and, for verified profiles, actor-signed step proofs with cumulative commitment state. | |||||||||||||
| draft-mw-oauth-tls-session-bound-tokens-07.txt | ||||||||||||||
| TLS-Session-Bound Access Tokens for OAuth 2.0 | ||||||||||||||
|
This document defines a mechanism for binding OAuth 2.0 access tokens to a specific mutual TLS (mTLS) connection. The binding is achieved through a proof token that incorporates the TLS Exporter value (RFC 5705) derived from the current connection and an access token hash, signed by the client's private key corresponding to its mTLS certificate. This mechanism prevents stolen bearer tokens from being replayed on a different TLS connection. The proof is constructed once per (token, connection) pair and reused across all requests on that connection, delivering session binding with no per-request signing overhead and no additional key management beyond what mTLS already provides. The mechanism is applicable to TLS 1.2, TLS 1.3, and QUIC transports. While applicable to any OAuth 2.0 access token presented over mTLS, this specification is primarily motivated by the OAuth 2.0 Token Exchange protocol (RFC 8693), where multi-hop delegation chains in autonomous, agent-driven architectures create elevated replay risk. | |||||||||||||
| draft-mw-spice-inference-chain-00.txt | ||||||||||||||
| Cryptographically Verifiable Inference Chain for AI Agent Computational Provenance | ||||||||||||||
|
This document defines the inference_root claim as a companion to the actor_chain claim ({{!I-D.draft-mw-spice-actor-chain}}) and the intent_root claim ({{!I-D.draft-mw-spice-intent-chain}}). While the actor chain addresses delegation provenance (WHO) and the intent chain addresses content provenance (WHAT), the inference chain addresses computational provenance (HOW) — providing cryptographic proof that a claimed AI model actually performed the inference that produced a given output. The inference chain leverages two complementary mechanisms: Zero- Knowledge Machine Learning (ZKML) proofs for mathematical certainty, and Trusted Execution Environment (TEE) attestation quotes for production-scale AI workloads. The full inference chain is stored as ordered logs, with only the Merkle root included in the OAuth token for efficiency. Together, the three chains — actor, intent, and inference — form a complete "Truth Stack" for autonomous AI agent governance. | |||||||||||||
| draft-mw-spice-intent-chain-00.txt | ||||||||||||||
| Cryptographically Verifiable Intent Chain for AI Agent Content Provenance | ||||||||||||||
|
This document defines the intent_chain claim as a companion to the actor_chain claim defined in {{!I-D.draft-mw-spice-actor-chain}}. While the actor chain addresses delegation provenance (WHO delegated to whom), the intent chain addresses content provenance (WHAT was produced and HOW it was transformed). In AI agent workflows, content flows through multiple processing stages including AI agents and filters. The intent chain provides a cryptographically verifiable, tamper-evident record of this content journey. The full intent chain is stored as ordered logs, with only the Merkle root included in the OAuth token for efficiency. Together, the actor chain and intent chain provide complete governance for autonomous AI agent systems, addressing Spoofing, Tampering, Repudiation, and Elevation of Privilege threats in the STRIDE threat model. | |||||||||||||
| draft-myclerk-protocol-03.txt | ||||||||||||||
| The MyClerk Protocol: Tiered Security Communication for Distributed Family Systems | ||||||||||||||
|
This document specifies the MyClerk Protocol, a tiered-security communication protocol designed for distributed family orchestration systems. The protocol provides six security tiers ranging from 1-byte minimal overhead for tunneled messages to 144-byte full security for critical operations. It supports multiple transport mechanisms including NATS, Matrix, WebSocket, and direct TCP, while maintaining end-to-end encryption using ChaCha20-Poly1305 AEAD with hybrid post-quantum key establishment combining ML-KEM-768 and X25519. A classical-only mode (X25519 without ML-KEM) remains available for resource-constrained devices and legacy interoperability. The protocol is transport-agnostic, federation-capable, and optimized for environments ranging from resource-constrained IoT devices to full-featured desktop clients. | |||||||||||||
| draft-myclerk-protocol-ops-00.txt | ||||||||||||||
| MyClerk Protocol Application Operations Registry | ||||||||||||||
|
This document defines the application-layer operation codes for the MyClerk Protocol. It serves as the authoritative registry for operation codes in the 0x0700-0x1DFF range, covering knowledge management, settings, messaging, telephony, calendar, tasks, smart home, automation, AI assistant, synchronization, orchestration, presence, health, location, plugins, mobile device management, legal documents, mobility, travel, audit, audio pipeline, and desktop client operations. This companion document follows the "Assigned Numbers" pattern established by Bluetooth SIG specifications, separating the operation registry from the core protocol specification to allow independent evolution of application operations. | |||||||||||||
| draft-myclerk-vfs-01.txt | ||||||||||||||
| The MyClerk Virtual File System: Distributed Storage for Family Networks | ||||||||||||||
|
This document specifies the MyClerk Virtual File System (VFS), a distributed storage system designed for family networks. The VFS provides end-to-end encrypted, redundant storage across heterogeneous nodes using adaptive chunking and Reed-Solomon erasure coding [REED-SOLOMON]. Metadata synchronization uses Conflict-free Replicated Data Types (CRDTs) [CRDT] with a hybrid LWW-Register and OR-Set approach. The system supports tiered storage, automatic health monitoring with self-healing capabilities, and federation between separate family installations. It is designed to be accessible to non-technical users while providing enterprise-grade data durability. | |||||||||||||
| draft-mzbc-ippm-transit-measurement-option-08.txt | ||||||||||||||
| The Transit Measurement Option | ||||||||||||||
|
This document specifies an IPv6 option that contains a compact set of fields which can be used for transit delay measurement and congestion detection. This option can be incorporated into data packets and updated by transit nodes along the path, enabling lightweight measurement and monitoring using constant-length data that does not depend on the number of hops in the network. | |||||||||||||
| draft-nandakumar-agentproto-moq-pace-00.txt | ||||||||||||||
| PACE: Protocol for Agent Communication Exchange | ||||||||||||||
|
This document defines the Protocol for Agent Communication Exchange (PACE), a session protocol for AI agent communication over Media over QUIC Transport (MOQT). PACE provides session lifecycle management, multi-modal data exchange, agent identity verification, and delegated authorization within MOQT's publish/subscribe model, supporting point-to-point and point-to-multipoint topologies through relay infrastructure. | |||||||||||||
| draft-nandakumar-moq-tempo-00.txt | ||||||||||||||
| TEMPO: Timing Extension for Media Playout Orchestration over MoQ | ||||||||||||||
|
This document defines TEMPO (Timing Extension for Media Playout Orchestration), a synchronized playout mechanism for media tracks delivered over the Media over QUIC Transport (MoQT) protocol. The Original Publisher stamps each object with when it should be played out and when it was sent. Relays replace the send-time stamp with their own clock as they forward, giving each subscriber a fresh timing reference from its nearest relay. Subscribers use these timestamps to decide when to render each object, and report their sync state directly to a coordination server (PlaySyncServer) that can tell the media publisher to adjust timing when subscribers fall behind. | |||||||||||||
| draft-narajala-courtney-ansv2-01.txt | ||||||||||||||
| Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity | ||||||||||||||
|
Autonomous AI agents execute transactions across organizational boundaries. No single agent platform provides the trust infrastructure they need. This document defines the Agent Name Service (ANS) v2 protocol, which anchors every agent identity to a DNS domain name. A Registration Authority (RA) verifies domain ownership via ACME, issues dual certificates (a Server Certificate from a public CA and an Identity Certificate from a private CA binding a version-specific ANSName), and seals every lifecycle event into an append-only Transparency Log aligned with IETF SCITT. Three verification tiers -- Bronze (PKI), Silver (PKI + DANE), and Gold (PKI + DANE + Transparency Log) -- let clients choose assurance levels appropriate to transaction risk. The architecture decouples identity from discovery: the RA publishes sealed events; independent Discovery Services build competitive indexes. A three-layer trust framework separates foundational identity (Layer 1, this protocol), operational maturity (Layer 2, third-party attestors), and behavioral reputation (Layer 3, real-time scoring). | |||||||||||||
| draft-narvaneni-agent-uri-03.txt | ||||||||||||||
| The agent:// Protocol -- A URI-Based Framework for Interoperable Agents | ||||||||||||||
|
This document defines the agent:// protocol, a URI-based addressing scheme for identifying, discovering, and invoking autonomous and semi-autonomous software agents. The agent:// scheme provides a semantic layer that signals "this resource is an agent" and enables agent-specific discovery via standardized descriptors. It introduces a layered architecture with four conformance levels, allowing implementations to adopt minimal addressing (Level 0) or full descriptor-based discovery with authentication and versioning (Level 3). The protocol complements existing agent communication protocols such as Agent2Agent (A2A), Model Context Protocol (MCP), and Agent Communication Protocol (ACP) by providing the addressing and discovery layer they lack. | |||||||||||||
| draft-navarre-quic-flexicast-03.txt | ||||||||||||||
| Flexicast QUIC: combining unicast and multicast in a single QUIC connection | ||||||||||||||
|
This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and IP multicast distribution trees. | |||||||||||||
| draft-nbcuong-mkv-block-cipher-00.txt | ||||||||||||||
| Encryption algorithms - Block cipher MKV | ||||||||||||||
|
This document specifies the MKV block cipher for use in cryptographic mechanisms supporting information security. The algorithm may be used to provide confidentiality of information during transmission, processing, and storage in information systems. About This Document This note is to be removed before publishing as an RFC. | |||||||||||||
| draft-nederveld-adl-02.txt | ||||||||||||||
| Agent Definition Language (ADL) | ||||||||||||||
|
The Agent Definition Language (ADL) provides a standard JSON-based format for describing AI agents. An ADL document declares an agent's identity, capabilities, tools, permissions, security requirements, data classification, and runtime configuration in a single, machine- readable artifact. ADL enables discovery, interoperability, deployment, and lifecycle management of AI agents across diverse platforms and runtimes. This document defines the structure of ADL documents, the semantics of their members, conformance requirements for implementations, and the registration of the application/adl+json media type. | |||||||||||||
| draft-nelson-agent-delegation-receipts-10.txt | ||||||||||||||
| Delegation Receipt Protocol for AI Agent Authorization | ||||||||||||||
|
This document defines the Delegation Receipt Protocol (DRP), a cryptographic authorization primitive for AI agent deployments. Before any agent action executes, the authorizing user signs an Authorization Object containing scope boundaries, time window, operator instruction hash, and model state commitment. This signed receipt is published to an append-only log before the agent runtime receives control. The protocol reduces reliance on the operator as a trusted intermediary by making the user's private key the sole signing authority over the delegation record. | |||||||||||||
| draft-nemethi-dawn-aid-00.txt | ||||||||||||||
| Agent Identity and Discovery (AID) | ||||||||||||||
|
Agent Identity and Discovery (AID) answers one question: given a domain, where is the agent and which protocol should a client speak? An AID client queries a DNS TXT record at the well-known subdomain _agent. | |||||||||||||
| draft-netana-nmop-message-broker-bmp-telemetry-msg-03.txt | ||||||||||||||
| BMP YANG Model for Network Telemetry Messages | ||||||||||||||
|
This document defines an BGP Monitoring Protocol (BMP) message schema extension in YANG to be used at data collection to transform Network Telemetry messages into external systems such as Message Brokers. | |||||||||||||
| draft-netana-opsawg-telemetry-over-quic-00.txt | ||||||||||||||
| QUIC Transport for Network Telemetry | ||||||||||||||
|
This document describes the use of the QUIC transport protocol as a common transport substrate for operational Network Telemetry protocols that currently rely on UDP. Specifically, it discusses carrying protocols such as IPFIX, Syslog, YANG-Push UDP-Notif, and RADIUS Accounting over QUIC connections. For telemetry protocols whose data plane is inherently loss-tolerant (where a missing sample is preferable to a delayed retransmission) this document recommends use of the Unreliable Datagram Extension to QUIC (DATAGRAM frames). A primary motivation for this work is the unification of transport- layer security across heterogeneous telemetry protocols. Protocols that currently have no mandatory transport security (syslog over UDP) or optional-only security (IPFIX over UDP with DTLS) or weak security (RADIUS with MD5 obfuscation) would all benefit from the mandatory TLS 1.3 mutual authentication that QUIC provides. This document specifically addresses the operational advantages of managing a single PKI certificate lifecycle per Network Node to authenticate all telemetry streams. This document is intended as a framework and applicability statement. Per-protocol bindings that require normative specification are expected to be chartered in their respective IETF working groups. | |||||||||||||
| draft-ni-agent-entity-discovery-00.txt | ||||||||||||||
| DNS-based Entity-Level Discovery and End-to-End Connection for AI Agents | ||||||||||||||
|
This document defines a new DNS resource record type, Agent Entity Discovery (AED), to publish agent-specific trust anchors or direct match constraints for verifying an agent's certificate or token. This enables the cross-domain users or agents to authenticate, and establish secure, end-to-end connections directly with a private- domain agent entity. | |||||||||||||
| draft-ni-oauth-batch-authorization-delegation-00.txt | ||||||||||||||
| Batch Authorization Delegation | ||||||||||||||
|
This document describes a mechanism for Batch Authorization Delegation, which enables a batch of fine-grained, actor-bound permissions in a single request and securely delegates them to multiple collaborating actors. | |||||||||||||
| draft-nike-cis-clay-tablet-00.txt | ||||||||||||||
| Ceramic Immutable Storage (CIS): A Write-Once Archival Format Using Impressed and Kiln-Fired Clay | ||||||||||||||
|
This document specifies Ceramic Immutable Storage (CIS), a write-once archival storage format in which digital data is impressed into plastic clay by a pin-configurable roller, rendered permanent by kiln firing, and retained on a shelved rack. CIS is motivated by a specific and increasingly common failure mode: the loss of data to an authenticated software process acting outside its operator's intent. Every widely deployed "immutable" storage tier is immutable by policy, and every policy is enforced by software that some credential, defect, or sufficiently determined automated agent can override. CIS relocates the immutability guarantee from policy to physics. The commit operation in CIS is an irreversible mineralogical phase change, and no inverse operation exists for any actor, mechanical or digital. This document defines the substrate, the encoding geometry, the frame format, the forward error correction scheme, the firing profile that constitutes commit, the rack addressing model, and the optical read path. It also documents, at length, the substantial costs of this approach. | |||||||||||||
| draft-nikolaichuk-rats-tap-00.txt | ||||||||||||||
| Trusted Artifact Provenance (TAP): A Producer,Verifier,and Sealer Contract for Attestation-Gated Reconstruction of Stateful Assets | ||||||||||||||
|
The Remote ATtestation procedureS (RATS) architecture (RFC 9334) defines how Evidence is conveyed from an Attester to a Verifier and how the resulting Attestation Results are conveyed to a Relying Party. It deliberately stops at the point where a Relying Party has appraised Attestation Results. This document specifies Trusted Artifact Provenance (TAP), a consumer of Attestation Results that defines what happens next in one specific and recurring case: releasing sealed key material to a process that reconstructs a stateful asset inside an attested environment, and recording the release decision as an auditable object. TAP defines three contracts. The Producer contract governs how an artifact is sealed and bound to the attested identity of the environment that produced it. The Sealer contract governs the attestation-gated release of key material to a reconstruction environment. The TAP Verifier contract governs after-the-fact appraisal of provenance and release records. TAP does not define an appraisal policy language, does not define a new Evidence format, and does not replace any part of RFC 9334. | |||||||||||||
| draft-nikolaichuk-scitt-continuity-receipts-00.txt | ||||||||||||||
| Continuity Receipts: Registering the Recovery of a Stateful Asset as a Signed Statement in a Transparency Service | ||||||||||||||
|
A Transparency Service as defined by RFC 9943 registers Signed Statements about Artifacts and returns Receipts, encoded per RFC 9942, that prove registration in an append-only log. The Statements registered today typically describe how an Artifact was built, tested, or released. They do not describe what happens after that: the Artifact is sealed, moved, lost, and later re-created somewhere else, and that re-creation leaves no independently checkable trace. This document defines a Continuity Receipt: the Receipt obtained when a recovery event is registered as a Signed Statement in a Transparency Service. It specifies the Subject and the required claims of a recovery Statement, how Attestation Results from RFC 9334 remote attestation are carried or referenced by it, and how a sequence of such Statements under one Subject forms a verifiable continuity chain across the lifetime of a stateful asset. The document is deliberately narrow. It defines a payload and a set of claims, not a new Transparency Service, not a new verifiable data structure, and not a new attestation format. It also records, rather than conceals, the divergence between what it specifies and what the reference implementation currently does. | |||||||||||||
| draft-nir-ipsecme-big-payload-08.txt | ||||||||||||||
| A Larger Internet Key Exchange version 2 (IKEv2) Payload | ||||||||||||||
|
The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document updates RFC 7296 by defining an extension that allows larger payloads. | |||||||||||||
| draft-nirvanai-nbtp-behavioral-trust-00.txt | ||||||||||||||
| NirvanAI Behavioral Trust Protocol (NBTP) | ||||||||||||||
|
The NirvanAI Behavioral Trust Protocol (NBTP) defines a cryptographic framework for continuous attestation of AI agent behavioral integrity in distributed networks. NBTP treats trust as a volatile, time- decaying state variable measured by an oracle-federated layer of independent scanner nodes. Unlike static credential systems that answer "Is this agent authorized?", NBTP answers "Is this agent currently acting like itself?" Trust computation is performed locally by each verifying party using signed attestations from independent oracle scanners; no centralized policy engine or authorization server is required at verification time. NBTP introduces a temporal decay model with context-dependent decay rates, a four-state trust machine (PROBATIONARY, TRUSTED, SUSPECT, QUARANTINED), cross-context co-silence detection, and a genesis bootstrapping mechanism (Creole gate) using formal CHALLENGE/RESPONSE packet types. Absence of attestation data is treated as a security- relevant signal. This document specifies the protocol wire format, state machine, decay model, security properties, and IANA considerations. Implementation-specific measurement heuristics are out of scope. | |||||||||||||
| draft-nivalto-agentroa-route-authorization-01.txt | ||||||||||||||
| Agent Route Origin Authorization (AgentROA): A Cryptographic Policy Enforcement Framework for AI Agent Actions | ||||||||||||||
|
This document specifies the Agent Route Origin Authorization (AgentROA) framework, a cryptographic policy enforcement model for governing the actions of autonomous AI agents. AgentROA introduces three core protocol objects: the Agent Route Origin Authorization (ROA) envelope, the Agent Route Attestation (ARA) per-hop receipt, and the Agent Execution Receipt (AER). Together these objects enable: (1) cryptographic binding of an agent's authorized action scope to a signed policy envelope at session initialization, (2) per-hop attestation across multi-agent delegation chains with monotonic scope-narrowing semantics (no policy envelope may be expanded by a downstream delegation), and (3) cryptographic receipts produced intrinsically by the enforcement decision at each capability invocation boundary. The framework is modeled on the BGP Route Origin Authorization (ROA) concept from RPKI (RFC 6480) applied to the AI agent execution domain. The Border Gateway enforcement model positions a cryptographic enforcement process at a capability invocation boundary — external to the agent's execution context — reducing the risk that governance decisions are influenced by the governed agent by placing enforcement in a separate process boundary. The Border Gateway model is topology-independent: it may be deployed as a protocol- specific proxy in front of Model Context Protocol (MCP) servers, as a service mesh enforcement component covering all inter-service calls, as a network egress gateway covering all outbound capability invocations regardless of protocol, or as a domain-specific execution boundary. The protocol objects defined herein function identically across all deployment topologies. This document establishes the architectural model, protocol object schemas, and enforcement semantics for the AgentROA framework. | |||||||||||||
| draft-niyikiza-oauth-attenuating-agent-tokens-01.txt | ||||||||||||||
| Attenuating Authorization Tokens for Agentic Delegation Chains | ||||||||||||||
|
This document defines Attenuating Authorization Tokens (AATs), a signed credential format for task-scoped delegation in AI agent systems. An AAT encodes the tools an agent may invoke and the argument constraints that apply to those invocations. A token holder authorized to delegate can derive a token offline with equal or narrower authority, subject to the parent token's depth and lifetime limits. The resulting delegation chain is verifiable offline by any enforcement point that has the root issuer's trust anchor key. This specification profiles the OAuth Rich Authorization Requests format (RFC 9396) for tool-level capability claims, adds delegation- chain claims, and defines a core constraint vocabulary for argument restrictions. The chain verification algorithm authenticates each delegation step and enforces monotonic attenuation without network contact with the root issuer. | |||||||||||||
| draft-nmop-cui-nkg-gateway-00.txt | ||||||||||||||
| A Gateway for Network Knowledge Graph Management | ||||||||||||||
|
This document specifies an interaction gateway for Network Knowledge Graphs (NKGs) to simplify graph-based network operations. The gateway architecture defines a Unified Intent Gateway (UIG) that supports Natural Language (NL) requests from human operators and Domain-Specific Language (DSL) or API directives from applications and orchestration systems. The UIG interprets user expectations and application directives as structured intents, aligns them with the NKG structure and exposed capabilities, and maps them to graph queries, graph inferences, API calls, or operational workflows through an Intermediate Representation (IR). The gateway architecture incorporates intent discovery, capability mapping, policy enforcement, audit logging, and response synthesis to make NKG-based operations more accessible, secure, and controllable. | |||||||||||||
| draft-noa-scitt-ai-agent-receipt-01.txt | ||||||||||||||
| A SCITT Profile for AI-Agent Action Receipts | ||||||||||||||
|
This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. | |||||||||||||
| draft-nobuo-scitt-composite-evidence-verification-00.txt | ||||||||||||||
| Composite Evidence Verification for SCITT Statement Graphs | ||||||||||||||
|
This document defines a common model for composite verification of SCITT statement graphs. A composite verifier checks a set of SCITT Signed Statements, receipts, object bindings, and relationship edges under a named verification profile. The result is a structured report that can say which statements passed, which evidence is missing, which evidence is stale, and which statements conflict. The model is intended for verifiers, auditors, deployment controllers, update services, and other relying-party tools. It is not a new Transparency Service requirement. It does not define a universal supply-chain policy language and does not define the payload format of any statement type. | |||||||||||||
| draft-nobuo-scitt-hardware-iot-cloud-use-cases-00.txt | ||||||||||||||
| Applying SCITT to Hardware,IoT Device,and Cloud Compute Resource Supply Chains | ||||||||||||||
|
This document describes how SCITT can be applied to supply chains that include hardware components, IoT devices, firmware, cloud compute resources, confidential-computing environments, accelerators, and related operational evidence. It gives use cases and scope guidance. It also explains how SCITT can work with RATS, COSE, TCG technologies, SBOM, HBOM, CBOM, and cloud attestation systems without replacing those technologies. This document is informational. It does not define hardware assurance rules, cloud assurance rules, device identity systems, manufacturing requirements, or payload formats. Its purpose is to show where SCITT statements and receipts can provide transparency for heterogeneous supply-chain evidence, and where other standards or domain profiles should remain responsible. | |||||||||||||
| draft-nobuo-scitt-protected-object-binding-00.txt | ||||||||||||||
| SCITT Statement Relationship and Protected Object Binding | ||||||||||||||
|
This document defines a small common model for relating Supply Chain Integrity, Transparency, and Trust (SCITT) Signed Statements to the supply-chain objects that those statements describe, measure, authorize, revoke, or audit. The model can be used for software artifacts, firmware artifacts, hardware components, device instances, cloud compute resources, and other objects that appear in supply- chain evidence. The document also defines a relationship vocabulary and an optional Statement Graph Manifest. These parts help verifiers connect heterogeneous SCITT statements without requiring SCITT to define the payload formats of those statements. This document does not define SBOM, HBOM, CBOM, attestation, audit, vulnerability, or regulatory payload formats. It only defines a common binding and graph layer around SCITT statements and receipts. | |||||||||||||
| draft-noctem-cogitator-witness-protocol-00.txt | ||||||||||||||
| COGITATOR Witness Protocol: Cryptographically Verifiable Audit Records for AI Agent Execution | ||||||||||||||
|
This document specifies the COGITATOR Witness Protocol -- a scheme for producing cryptographically verifiable, tamper-evident records of AI agent execution. A conforming implementation produces a single witness root value that any third party can independently recompute from the same inputs to verify the record was not altered after the fact. The protocol is implementation-agnostic. The reference implementation is COGITATOR (Rust), but any language or framework can produce conforming witness bundles. This document also describes how the COGITATOR Witness Protocol relates to the IETF SCITT architecture, with which it is designed to be used as a payload inside SCITT Signed Statements. | |||||||||||||
| draft-norton-sdlp-arch-04.txt | ||||||||||||||
| SDLP Architecture (arch) | ||||||||||||||
|
The Secured Digital Lifecycle Protocol (SDLP) defines an architecture for lifecycle-governed digital objects. SDLP introduces a uniform model for object identity, provenance, state transitions, and authorized transformations, enabling digital goods to enforce their own lifecycle rules across heterogeneous systems and distribution environments. This document describes the architectural components that support SDLP objects, including identity construction, lifecycle state definitions, transition conditions, and the mechanisms by which objects validate their own integrity and permitted operations. The architecture defines how SDLP objects are created, transformed, distributed, consumed, and retired, and specifies the interoperability requirements needed for consistent behavior across independent implementations. This document does not define wire formats or protocol exchanges. Instead, it provides the architectural foundation upon which SDLP protocol specifications, security mechanisms, and implementation profiles can be built. | |||||||||||||
| draft-norton-sdlp-identity-02.txt | ||||||||||||||
| SDLP RFC 1: DigitalID Specification | ||||||||||||||
|
This document defines the DigitalID specification for the Secured Digital Lifecycle Protocol (SDLP). The DigitalID is the foundational identity construct for all SDLP-governed objects, providing deterministic uniqueness, lineage preservation, collision elimination, and stable identity bindings across all compliant implementations. This document updates and formalizes the DigitalID structure, canonical encoding rules, lineage grammar, identity assignment requirements, collision model, and validation rules originally introduced in draft-norton-sdlp-identity-00. | |||||||||||||
| draft-norton-sdlp-interop-profile-04.txt | ||||||||||||||
| SDLP Interoperability Profile for Ownership,Verification,and Provenance Evidence | ||||||||||||||
|
This document defines an interoperability profile for the Secured Digital Lifecycle Protocol (SDLP). The profile specifies how SDLP canonical objects, identity, lineage, lifecycle state, and digests are composed with external verification, typed authority evaluation, and provenance evidence semantics. It introduces a transition vector model that carries canonical SDLP envelopes together with CAID projections, AEC evidence results, local authorization decisions, and AEB execution outcomes, without altering SDLP’s core object semantics. The profile defines how SDLP objects participate in multi-stage verification pipelines and how mutated candidate inputs, negative cases, and authority constraints are represented. It also specifies composition rules for integrating SDLP with provenance and transparency systems such as CAID, AEC, AEB, SCITT, and EMILIA, while preserving the separation of concerns between SDLP canonical semantics and ecosystem-specific admission and trust policies. | |||||||||||||
| draft-norton-sdlp-lifecycle-03.txt | ||||||||||||||
| SDLP Lifecycle Specification | ||||||||||||||
|
This document defines the SDLP Lifecycle Specification, the canonical state machine and transition semantics governing how SDLP objects evolve over time. The lifecycle model establishes deterministic rules for object creation, activation, transformation, and termination, ensuring that identity, lineage, and lifecycle metadata remain tamper-evident and verifiable across all implementations. Lifecycle-03 updates and aligns the transition grammar with Identity-02, Lineage-03, and Object-Format-08, providing a unified framework in which DigitalID is immutable, InstanceID grows deterministically, Lineage reflects complete ancestry, and Timestamp records the precise moment of each transition. The lifecycle rules defined in this document are normative and required for interoperable SDLP processing, validation, and provenance assurance. | |||||||||||||
| draft-norton-sdlp-lineage-03.txt | ||||||||||||||
| SDLP Lineage Specification | ||||||||||||||
|
This document defines the SDLP lineage model, which provides the canonical method for representing the ancestry of SDLP-governed objects. Lineage is a structural property that records how an object evolves through duplication and transformation events. The lineage model ensures that descendant objects remain uniquely identifiable and traceable across all lifecycle transitions. Lineage-03 aligns the lineage grammar with Identity-02, Lifecycle-02, and Object-Format-07, and defines deterministic ancestry extension rules that produce stable, verifiable lineage across all SDLP implementations. This revision incorporates BitDrop conditions for invalid lineage transitions and specifies normative validation requirements for relying parties. Together with Identity-02, Lifecycle-02, and Object-Format-07, this document provides the authoritative lineage model required for interoperable identity, lifecycle, and provenance processing. | |||||||||||||
| draft-norton-sdlp-obj-format-08.txt | ||||||||||||||
| SDLP Object Format Specification | ||||||||||||||
|
This document defines the canonical object format for the Secured Digital Lifecycle Protocol (SDLP). The SDLP object format specifies the structure, encoding, and canonicalization rules for DigitalID, lineage fields, lifecycle timestamps, Body content, and signature envelopes. These rules establish the immutable semantics required for SDLP verification, provenance tracking, lifecycle transitions, and interoperability with external systems such as CAID, AEC, AEB, SCITT, and EMILIA. Version -08 updates the canonical timestamp grammar, clarifies DigitalID and lineage field semantics, refines Body canonicalization rules, and incorporates corrections identified through SDLP Fixture Bundle v4 testing. This revision aligns the object format with the current SDLP Identity (-02), Lineage (-03), Lifecycle (-03), Security Architecture (-04), Architecture (-03), Overview (-01), and Physics Model (-00) drafts. | |||||||||||||
| draft-norton-sdlp-overview-01.txt | ||||||||||||||
| SDLP RFC 0: Overview and Architecture | ||||||||||||||
|
This document presents an architectural overview of the Secured Digital Lifecycle Protocol (SDLP). SDLP defines a structured model for representing, identifying, tracking, and securing digital objects across their lifecycle. This overview summarizes the SDLP object model, explains how identity, lineage, lifecycle, and security architecture interrelate, and outlines the rationale for defining SDLP through multiple coordinated specifications. It serves as the entry point for understanding the SDLP framework. | |||||||||||||
| draft-norton-sdlp-phys-00.txt | ||||||||||||||
| SDLP Physics Specification | ||||||||||||||
|
The Secured Digital Lifecycle Protocol (SDLP) defines a physics layer for digital objects: a set of non-negotiable behavioral laws that govern identity stability, lineage integrity, lifecycle determinism, and irreversible state transitions. SDLP Physics establishes how object security depletes, transforms, or terminates as an object is activated, used, or shared, ensuring that each operation consumes or alters the object’s allowable state in predictable ways. These laws prevent cloning, enforce legitimate descent, bind objects to their environments, and guarantee that destruction and zeroization are final. This document specifies the core physics that underpin SDLP’s security model and define how digital objects behave across all environments and distribution paths. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at: https://www.ietf.org/shadow.html | |||||||||||||
| draft-norton-sdlp-sec-arch-04.txt | ||||||||||||||
| SDLP Security Architecture (SDLP RFC 4) | ||||||||||||||
|
The Secured Digital Lifecycle Protocol (SDLP) defines a physics-layer security model in which digital objects secure themselves throughout their entire lifecycle. Existing security measures—such as cryptographic signatures, watermarking, provenance metadata, and attestation—are integrated and enforced within a unified physics layer positioned between the Transport and Application layers. This document describes the SDLP security architecture, including the environment safety check, the composite PASS/FAIL trust verdict, and the mandatory BitDrop behavior applied when any trust condition fails. The SDLP security architecture ensures that digital objects operate only within verified, tamper-resistant environments and provides a complete, end-to-end defense against unauthorized access, copying, modification, and redistribution. | |||||||||||||
| draft-norton-sdlp-transformation-00.txt | ||||||||||||||
| SDLP Transformation Model | ||||||||||||||
|
The Secured Digital Lifecycle Protocol (SDLP) defines a unified framework for representing, identifying, and tracking digital objects across their entire lifecycle. This document specifies the SDLP transformation model, which describes how digital objects change, evolve, or produce descendants through normative and verifiable processes. A transformation is any operation that produces a new digital object from an existing one. This document defines the transformation model, the required identity and lineage extensions, the invariants that must be preserved, and the logging requirements needed to ensure integrity, accountability, and tamper-evidence. These rules apply uniformly across all SDLP object types and lifecycle states. This specification is a core component of the SDLP architecture and is intended to be used alongside the SDLP Overview, Identity, Object Format, Lineage, Lifecycle, and Security Architecture documents. | |||||||||||||
| draft-noss-jeftovic-groundmark-attestation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-noss-jeftovic-groundmark-core-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-nottingham-archive-embargo-00.txt | ||||||||||||||
| Embargoing Archive Publication using robots.txt | ||||||||||||||
|
Web sites often block archiving crawlers because they host time- sensitive information. This specification documents a robots.txt extension, "Archive-Embargo", that can be used to request that such crawlers delay publication of information. This document updates RFC 9309 to add two directives that support embargoes. | |||||||||||||
| draft-nottingham-feed-menu-01.txt | ||||||||||||||
| Feed Menus | ||||||||||||||
|
This specification defines Feed Menus, a simplified means of discovering the feeds (e.g., RSS or Atom) offered by a Web site. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottingham-feed-menu/. information can be found at https://mnot.github.io/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/feed-menu. | |||||||||||||
| draft-nottingham-ianabis-spec-reqd-03.txt | ||||||||||||||
| Specification Required Sub-Policies | ||||||||||||||
|
This document defines sub-policies that refine the Specification Required registry policy in RFC 8126. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottingham-ianabis-spec-reqd/. information can be found at https://mnot.github.io/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/spec-reqd. | |||||||||||||
| draft-nottingham-webbotauth-use-cases-02.txt | ||||||||||||||
| Use Cases for Authentication of Web Bots | ||||||||||||||
|
This draft outlines use cases for authentication for bot clients on the Web, to help inform discussions regarding the scope and intent of the WebBotAuth Working Group. | |||||||||||||
| draft-nottnick-ietf-decisions-01.txt | ||||||||||||||
| Making Decisions in IETF Working Groups | ||||||||||||||
|
This document specifies Best Current Practice for making decisions in IETF Working Groups. It updates Section 3.3 of [RFC2418]. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-nottnick-ietf-decisions/. information can be found at https://projects.mnot.net/I-D/. Source for this draft and an issue tracker can be found at https://github.com/mnot/I-D/labels/ietf-decisions. | |||||||||||||
| draft-novak-rats-tacra-01.txt | ||||||||||||||
| Trustworthy Acquisition of Credentials via Remote Attestation | ||||||||||||||
|
There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to, among other reasons, organizational friction, technological inertia, and regulatory policies. There are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers. This document describes an architecture by which Remote Attestation is utilized for providing Attesters with Identity Documents (keys or credentials) to authenticate to RUPs. This architecture is intended to work with common credential acquisition protocols and mechanisms such as EST, SPIFFE/SPIRE, ACMEv2, and many others. Another important but separate goal is to encapsulate the Attester- side complexity of Remote Attestation and credential acquisition similar to how Envoy does it. This allows Attesters to be implemented in a way that abstracts away the details of credential acquisition: both the protocols used and the Credential Acquisition Mechanisms employed, whether minting new (Enrollment), or requesting existing (Retrieval) credentials. Likewise, the choice between RATS Passport and Background Check models is made opaque to the Attester, further simplifying its development. | |||||||||||||
| draft-nser-vrrp-sbfd-02.txt | ||||||||||||||
| Fast failure detection in VRRP with S-BFD | ||||||||||||||
|
The Virtual Router Redundancy Protocol (VRRP) protocol depends on IPv4 or IPv6 connectivity between redundant peers and can use Seamless Bidirectional Forwarding Detection (S-BFD) to detect a Primary Router failure faster than the base VRRP advertisement timers. This document describes an extension that allows VRRP to use S-BFD as an additional failure-detection mechanism. It defines a new VRRP packet type, a dedicated timer, and a mechanism for a VRRP Primary Router to advertise an S-BFD reflector discriminator to Backup Routers. Local discriminator allocation is left to the implementation. | |||||||||||||
| draft-nunez-mfop-federated-ai-orchestration-00.txt | ||||||||||||||
| Mahalaxmi Federation and Orchestration Protocol (MFOP) | ||||||||||||||
|
This document defines the Mahalaxmi Federation and Orchestration Protocol (MFOP), a protocol for coordinating parallel artificial intelligence (AI) agent execution across a distributed network of heterogeneous compute nodes. MFOP specifies node identity and registration, capability advertisement, compliance-zone-aware job routing using database-layer enforcement, semantic input partitioning, cryptographically signed billing receipts, configurable economic settlement, and a layered security model comprising AI safety policy validation and execution sandbox isolation. The protocol is designed to operate across three simultaneous deployment configurations: private enterprise meshes, managed cloud pools, and open community marketplaces. MFOP is agnostic to the underlying AI model provider. | |||||||||||||
| draft-nurpmeso-delivered-enc-01.txt | ||||||||||||||
| Delivered-Enc Email Header Field | ||||||||||||||
|
Cryptographically protected email aims in hiding and protecting. Extending this to an uppermost extend also for trace headers, and/or the transport layer, so that only directly involved hops, which need to have a notion to "know", the sending system and/or the receiving system thus, can interpret certain header information, can be important. This document ensures that only the receiving system, in its desire to prevent email loops, can interpret the real content of the delivery notice header. | |||||||||||||
| draft-nurpmeso-dkim-access-control-diff-changes-13.txt | ||||||||||||||
| DKIM Access Control and Differential Changes | ||||||||||||||
|
This document specifies a DKIM (RFC 6376) iteration that allows cryptographical verification of SMTP (RFC 5321) envelope data, and of any signature along the message path, even beyond IMF (RFC 5322) message content changes. It addresses existing security glitches, and introduces active mitigations to embrace collateral damage effects of email solutions of the younger past by a standardized solution, also by moving complexity away from lower network protocol layers, where problems cannot be solved. It updates DKIM in certain aspects that reality has proven to be superfluous, incomplete, or obsoleted. | |||||||||||||
| draft-nurpmeso-smtp-tls-srv-08.txt | ||||||||||||||
| Secure SMTP/TLS SRV Announcement | ||||||||||||||
|
This specification defines a DNS (RFC 1035) SRV (RFC 2782) record that announces TLS (RFC 9325) secured SMTP (RFC 5321, RFC 3207), optionally including Implicit TLS. | |||||||||||||
| draft-nurpmeso-smtp-verp-03.txt | ||||||||||||||
| SMTP VERP Service Extension | ||||||||||||||
|
This specification makes official D. J. Bernstein's Variable Envelope Return Paths: VERP. | |||||||||||||
| draft-nyakiso-hcap-00.txt | ||||||||||||||
| HTTP Compliance Authorization Protocol (HCAP) | ||||||||||||||
|
This document specifies the HTTP Compliance Authorization Protocol (HCAP), an extension to the HTTP authentication framework that allows resource providers to require demonstrable evidence of caller compliance with declared policies before granting access to protected resources. Callers obtain signed compliance credentials from a compliance registry by presenting evidence of their controls. Credentials are conveyed at the HTTP layer and verified offline by the provider. HCAP operates alongside existing authentication schemes (OAuth 2.0, mTLS) and does not replace identity authentication. It addresses the distinct question of "does the caller meet declared policy requirements" rather than "who is the caller". | |||||||||||||
| draft-nyantakyi-vaip-agent-identity-01.txt | ||||||||||||||
| Vorim Agent Identity Protocol (VAIP) | ||||||||||||||
|
This document defines the Vorim Agent Identity Protocol (VAIP), a standard for establishing verifiable cryptographic identity, fine- grained permissions, trust scoring, and tamper-evident audit trails for autonomous AI agents. As AI agents increasingly perform actions autonomously in enterprise systems, existing identity protocols designed for human users or static services are insufficient. VAIP addresses this gap by providing cryptographic primitives and data structures for issuing, verifying, and managing agent identities in multi-tenant environments. The protocol uses Ed25519 for agent identity, SHA-256 for audit integrity, and defines seven hierarchical permission scopes with time-bounded grants and rate limiting. | |||||||||||||
| draft-nygate-ippm-mrl-00.txt | ||||||||||||||
| Mouth-to-Ear Response Latency for Conversational Voice Systems: Metric Definition and Active Measurement Method | ||||||||||||||
|
This document defines mouth-to-ear response latency (MRL), a performance metric for conversational voice systems, together with an active method for measuring it at the RTP reference point of the calling endpoint. MRL is the interval between the transmission of the final speech sample of a caller's utterance and the arrival of the first sample of the system's response audio. Two variants are defined, one taken at packet arrival and one taken behind a de-jitter buffer of stated target depth. The method is specified so that both timestamps are drawn from a single clock on a single host, so that the metric requires no synchronisation between the measuring endpoint and the system under test. Requirements for stimulus material, capture content, quality control, calibration and reporting are given. | |||||||||||||
| draft-nygren-dnsop-domain-delegation-validation-00.txt | ||||||||||||||
| Domain Control Validation for DNS Delegations | ||||||||||||||
|
The techniques specified in [I-D.draft-ietf-dnsop-domain-verification-techniques] for using the DNS to verify ownership or control of a domain in the Domain Name System (DNS) rely on the domain already being properly delegated to a DNS authority. For the specific case where the Application Service Provider is providing authoritative DNS services, the existing approaches don't provide a way to bootstrap domain validation onto a new Authoritative DNS Application Service provider. This specification proposes a mechanism for "Domain Control Validation" for cases where the User and DNS Administrator are validating control over a domain to an Authoritative DNS Application Service Provider and thus do not have the ability to add records within the domain. In this case, validation must be performed by the User taking actions in the DNS Registrar or Parent Zone that demonstrate control over the domain, such as by adding DNS NS records as validation records. | |||||||||||||
| draft-nygren-dnsop-ipv6only-indicator-00.txt | ||||||||||||||
| Indicating IPv6-only SVCB Endpoints and IPv4 Deprecation in the DNS | ||||||||||||||
|
As the DNS is the primary mechanism for translating from hostnames to IP addresses, it is a logical place to signal that endpoints are IPv6-only. It is thus also a logical place to signal that legacy endpoints supporting IPv4 are being deprecated. This specification introduces two SvcParams for SVCB-compatible RR types that signal IPv6-only endpoints (ipv6only) as well as deprecated endpoints (deprecated). TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/enygren/draft-nygren-dnsop-ipv6only-indicator (https://github.com/enygren/draft-nygren-dnsop-ipv6only-indicator). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| draft-nygren-httpbis-http11-request-binding-01.txt | ||||||||||||||
| HTTP/1.1 Request Smuggling Defense using Cryptographic Message Binding | ||||||||||||||
|
HTTP/1.1 Message Binding adds new hop-by-hop header fields that are cryptographically bound to requests and responses. The use of this protocol is negotiated out-of-band from the HTTP datastream, and keys can be communicated either in-band in the first request or out-of- band (such as via TLS Exporters). These header fields allow endpoints to detect and mitigate desynchronization attacks, such as HTTP Request Smuggling, that exist due to datastream handling differences. | |||||||||||||
| draft-ochkas-cose-ascon-04.txt | ||||||||||||||
| Ascon-AEAD128 and Ascon-Hash256 for COSE | ||||||||||||||
|
This document describes CBOR Object Signing and Encryption (COSE) serialization with Ascon, a NIST standard for lightweight cryptography. In 2019, as a part of CAESAR competition, Ascon-128 and Ascon-128a were selected as the first choice for the lightweight authenticated encryption. After, in 2023, National Institute of Standards and Technology (NIST) selected Ascon family of cryptographic algorithms to be the standard for lightweight cryptography. In August 2025, NIST Special Publication 800-232 was released, defining Ascon-based lightweight cryptography standards for constrained devices. This recognition makes it particularly interesting to enable using Ascon with COSE structures. | |||||||||||||
| draft-oiwa-path-characteristics-service-01.txt | ||||||||||||||
| Secure Hybrid Network Monitoring - Path Characteristics Service | ||||||||||||||
|
"Secure hybrid network monitoring – Problem statement" [I-D.oiwa-secure-hybrid-network] identifies challenges in securing and monitoring networks deployed across hybrid and mixed cloud environments. This document introduces the Path Characteristics Service (PCS), a service that enables applications and operators to verify whether a given network path conforms to their declared requirements ("intent") regarding security, compliance, and operational properties. Unlike traditional network monitoring, PCS does not expose raw network state; instead, it evaluates the user's intent against the actual path characteristics and returns a conformance result (match or no-match). This intent matching approach allows multi-stakeholder environments to verify path properties without disclosing sensitive internal infrastructure details. This document describes an architecture and interfaces for PCS; it expresses recommended behaviors and constraints using the normative keywords of BCP 14, but does not specify a wire protocol or its encoding. | |||||||||||||
| draft-oiwa-secure-hybrid-network-03.txt | ||||||||||||||
| Secure hybrid network monitoring - Problem statement | ||||||||||||||
|
This document presents a problem statement and gap analysis for ensuring and monitoring the security status of networks operating in complex environments, such as hybrid and multi-cloud systems. It identifies a missing capability: verifying the path and security properties of communications across multiple administrative domains while preserving each provider's confidentiality and local policy boundaries. The document also outlines, non-normatively, potential solution directions. | |||||||||||||
| draft-okutomi-agent-human-interaction-00.txt | ||||||||||||||
| An Agent-Human Interaction Overlay for Task Protocols | ||||||||||||||
|
This intentionally incomplete design note defines an overlay for Human and Agent participation in existing Task and Action protocols. It separates the responsible Participant from the authenticated Actor, records Human interactions, excludes Humans from Agent discovery, and binds each change to its authorized request. It defines neither a wire protocol nor Humans as Agents. | |||||||||||||
| draft-okutomi-session-bound-agent-identity-06.txt | ||||||||||||||
| A Verifier-Side Acceptance Profile for Channel-Bound Agent Identity and Authorization | ||||||||||||||
|
This document defines a verifier-side acceptance profile for channel- bound Agent identity and authorization. It addresses context diversion, where cryptographically valid material is accepted for a different service, tenant, actor, task, target, delegation, or authority boundary than the verifier intended. A verifier accepts an actor only when a verified authority grant, holder-of-key proof, accepted channel instance, freshness and replay state, any required attestation result, and verifier-local policy all describe the same intended interaction. Protocol-specific wire formats and deployment choices are left to binding profiles. | |||||||||||||
| draft-openhttpa-protocol-01.txt | ||||||||||||||
| OpenHTTPA: Hypertext Transfer Protocol with Attestation | ||||||||||||||
|
OpenHTTPA (Hypertext Transfer Protocol with Attestation) defines a protocol for establishing hardware-verified, end-to-end confidential and authenticated communication between a client and a Trusted Execution Environment (TEE) over standard HTTP/2, HTTP/3, and gRPC transports. Unlike traditional TLS which terminates at the network edge, OpenHTTPA ensures that the cryptographic session terminates inside the hardware-isolated enclave. The protocol is based on the SIGMA-I model and incorporates post-quantum hybrid key exchange (ML- KEM), post-quantum digital signatures (ML-DSA), transcript-bound hardware attestation, and semantic binding of HTTP requests to the hardware-verified session state. This document supersedes the earlier work published as draft-openhttpa-protocol-00. | |||||||||||||
| draft-opennhp-ztcpp-nhp-00.txt | ||||||||||||||
| Network-Infrastructure Hiding Protocol | ||||||||||||||
|
The Network-Infrastructure Hiding Protocol (NHP) is a cryptography- based session-layer protocol designed to operationalize Zero Trust principles by concealing protected network resources from unauthorized entities. NHP enforces authentication-before-connect access control, rendering IP addresses, ports, and domain names invisible to unauthorized users. This document defines the protocol architecture, cryptographic framework, message formats, and workflow to enable independent implementation of NHP. It represents the third generation of network hiding technology—evolving from first- generation port knocking to second-generation Single-Packet Authorization (SPA) and now to NHP with advanced asymmetric cryptography, mutual authentication, and scalability for modern threats. This specification also provides guidance for integration with Software-Defined Perimeter (SDP), DNS, FIDO, and Zero Trust policy engines. | |||||||||||||
| draft-orr-wlan-security-architectures-00.txt | ||||||||||||||
| Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems | ||||||||||||||
|
This note identifies all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures, to simplify the task of selecting the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture. | |||||||||||||
| draft-ostermeyer-jmd-00.txt | ||||||||||||||
| JMD: A Text-Based Structured Data Format for LLM-Driven Infrastructure | ||||||||||||||
|
This document defines JMD (JSON Markdown), a text-based structured data format designed for use in LLM-driven infrastructure, including tool-calling pipelines, MCP (Model Context Protocol) servers, REST APIs consumed by LLM agents, and multi-agent workflows. JMD encodes the full JSON type system (RFC 8259) using a subset of Markdown syntax -- headings for hierarchy, key: value lines for object fields, bullet lists for array items, and blockquotes for multiline strings. The format is line-oriented and streamable: every completed line is an independent, parseable event. JMD documents are in bijection with JSON values, and the roundtrip JSON -> JMD -> JSON preserves the value. This document specifies the JMD grammar, the canonical parse result (envelope), the four document modes (data, query, schema, delete), the streaming event model, and the media type registration for application/jmd. | |||||||||||||
| draft-ounsworth-rats-privacy-framework-00.txt | ||||||||||||||
| Privacy Framework for Remote ATtestation procedureS | ||||||||||||||
|
This document extends the RATS Architecture to consider "coercive uses of RATS" where a malicious Verifier or Relying Party uses RATS protocols to extract sensitive information from an Attester or a victim Verifier that it would not otherwise be inclined to disclose. This over-disclosure can include revealing sensitive measurements, stable identifiers, device fingerprints, vendor information, or conclusions derived from Evidence. This document defines a privacy framework for Remote Attestation that identifies this threat surfaces; classifies claims produced by Attesters and Presenters; restricts sensitive Evidence disclosure to authorized Trusted Verifiers using confidentiality protection; and describes privacy- preserving Attestation Results based on data minimization, Selective Disclosure, and Zero-Knowledge Proofs. | |||||||||||||
| draft-ovidi-lip-4d-00.txt | ||||||||||||||
| LIP-4D: An Intent Context and Authorization Dialogue Protocol for Autonomous Agents | ||||||||||||||
|
This document specifies LIP-4D, an experimental, transport- independent JSON protocol for expressing and evaluating the intent of autonomous software agents. A LIP-4D exchange binds an authenticated agent to a requested action, purpose, execution context, rationale claims, evidence, time constraints, and an evolution history. A policy enforcement component can challenge the agent for additional evidence and, after evaluation, issue a short-lived intent-bound authorization grant or deny the request. LIP-4D does not replace workload identity, cryptographic authentication, OAuth, or other authorization frameworks. It supplies a structured intent and evidence layer that can be used with those systems. The protocol deliberately excludes private model chain-of-thought and instead carries concise, reviewable claims and verifiable evidence. | |||||||||||||
| draft-ozturk-scitt-prml-profile-00.txt | ||||||||||||||
| A SCITT Profile for Pre-Run Evaluation Criteria (PRML) | ||||||||||||||
|
This document defines a profile for carrying pre-run evaluation criteria as a SCITT Signed Statement payload, using the architecture of RFC 9943. It specifies the payload media type, the selection of the Issuer and Subject CWT claims, the encoding of hash-only statements for criteria that must remain confidential, a sequencing requirement that makes amendment order verifiable, and the semantics of amendment itself. It does not define a new transparency architecture; it describes how an existing artefact type is carried by the one RFC 9943 already defines. | |||||||||||||
| draft-paka-rats-hardware-component-attestation-00.txt | ||||||||||||||
| Attestation of Hardware Components | ||||||||||||||
|
Hardware components constitute the foundation of all computations and therefore play a critical role in system integrity and reliability. Existing attestation mechanisms primarily rely on manufacturer endorsements, which provide limited visibility into the runtime behavior of hardware. This document extends the Remote ATtestation procedureS (RATS) architecture by defining a data model and guidelines for including measurements of hardware components in attestation Evidence. These measurements may represent physical properties, results of self-tests, or behavioral observations. The document considers a threat model that includes both adversarial actions and physical phenomena such as environmental variations and aging. It proposes abstract interfaces for collecting measurements, enabling interoperability while remaining agnostic to implementation mechanisms, and outlines a security model for their use in appraisal. | |||||||||||||
| draft-palanivelan-bfd-v2-gr-13.txt | ||||||||||||||
| A Record of Discussions of Graceful Restart Extensions for Bidirectional Forwarding Detection (BFD) | ||||||||||||||
|
This document is a historical record of discussions about extending the Bidirectional Forwarding Detection (BFD) protocol to provide additional capabilities to handle Graceful Restart. These discussions took place in the context of the IETF's BFD working group, and the consensus in that group was that these extensions should not be made. This document presents a summary of the challenges to BFD in surviving a graceful restart, and outlines a potential protocol solution that was discussed and rejected within the BFD working group. The purpose of this document is to provide a record of the work done so that future effort will not be wasted. This document does not propose or document any extensions to BFD, and there is no intention that it should be implemented in its current form. | |||||||||||||
| draft-palet-happy-reporting-considerations-01.txt | ||||||||||||||
| Considerations for Happy Eyeballs Error Reporting | ||||||||||||||
|
This document introduces different aspects to be considered for the Happy Eyeballs error reporting. | |||||||||||||
| draft-pamtv-netconf-error-registries-01.txt | ||||||||||||||
| Error List and Error Identities Registries for YANG-driven protocols | ||||||||||||||
|
This document defines IANA registries for the YANG Protocol Error List and YANG Protocol Error Identities. | |||||||||||||
| draft-pan-transparent-ordered-bonding-00.txt | ||||||||||||||
| Transparent Ordered Bonding for High-Capacity WAN Links | ||||||||||||||
|
This document describes a Transparent Ordered Bonding (TOB) mechanism for high-capacity wide-area links that are physically composed of multiple lower-rate member links. Traditional flow-based load balancing mechanisms can preserve packet ordering, but they cannot fully utilize all member links for a single large traffic stream. TOB introduces a bonding layer between two adjacent network nodes. The bonding layer fragments ingress packets into cells, distributes them across member links according to link status, and reassembles them in strict order at the remote node. This document specifies the applicability, architecture, packet format, scheduling considerations, and resequencing behavior of TOB. | |||||||||||||
| draft-pang-cats-fallback-decision-framework-00.txt | ||||||||||||||
| CATS Fallback Decision Framework | ||||||||||||||
|
This document describes the framework and considerations for fallback decision-making in Computing-Aware Traffic Steering (CATS). While existing OAM frameworks provide multi-dimensional telemetry collection capabilities, how the CATS Path Selector (C-PS) should react to partial or transient failures remains an open issue. This document highlights the problems of misjudgment due to correlated failures, steering flapping, and non-deterministic fallback behaviors. It outlines the high-level considerations for logical decoupling of status dimensions and stable state transition mechanisms to ensure carrier-grade reliability. Specific protocol extensions and algorithm implementations will be explored in future revisions based on working group discussions. | |||||||||||||
| draft-pang-nmop-kg-for-traffic-monitoring-analysis-03.txt | ||||||||||||||
| Knowledge Graph for Network Traffic Monitoring and Analysis | ||||||||||||||
|
This document extends the knowledge graph framework specifically to the traffic management domain, demonstrating how knowledge graphs can address long-standing traffic management challenges through semantic integration and automated reasoning. | |||||||||||||
| draft-pang-opsawg-cd-oam-problem-00.txt | ||||||||||||||
| Cross-Domain OAM Problem Statement and Requirements:Across Trust Boundaries | ||||||||||||||
|
As network service deployments increasingly span multiple administrative domains—such as operator edge clouds, tenant datacenters, multi-cloud environments, and managed security services—operators lack standardized OAM (Operations, Administration, and Maintenance) mechanisms to localize faults across these trust boundaries. Existing OAM mechanisms, such as RFC 9516 for Service Function Chaining (SFC), typically assume all network elements reside within a single administrative domain. This document describes the generic problem space, typical use cases, and gaps in existing standards for cross-domain OAM across trust boundaries, and outlines the requirements for a cross-domain OAM proxy mechanism. This document is intended to provide a problem baseline and requirement definitions for the OPSAWG and the broader operations community; it does not specify protocols or data models. | |||||||||||||
| draft-pang-srv6ops-qkd-srv6-private-line-00.txt | ||||||||||||||
| Problem Statement and Operational Considerations for QKD-Assisted SRv6 Private Line Services | ||||||||||||||
|
SRv6 is used by operators to provide programmable and traffic- engineered IP private line services. Such services are often deployed for customers with strict requirements on service isolation, predictable forwarding, and communication security. Quantum Key Distribution (QKD) networks can provide symmetric key material to authorized applications or security functions. When QKD- generated keys are used together with SRv6-based private line services, operators need to coordinate service provisioning, SRv6 policy state, endpoint security functions, and QKD key availability. This document describes the problem space and operational considerations for QKD-assisted SRv6 private line services. It does not define new SRv6 data-plane behavior, new SRv6 Segment Identifier semantics, a new QKD protocol, or a new cryptographic algorithm. | |||||||||||||
| draft-pang-v6ops-ipv6-deployment-stats-analysis-00.txt | ||||||||||||||
| IPv6 Deployment Statistics and Analysis | ||||||||||||||
|
This document explains why existing observations of IPv6 deployment are often insufficient to identify the operational gaps and bottlenecks that limit IPv6 utilization and service quality. It describes the need for correlated analysis across different parts of the service path and discusses examples of statistical evidence that can support such analysis. | |||||||||||||
| draft-pang-v6ops-ipv6-path-degradation-00.txt | ||||||||||||||
| IPv6 Path Performance Degradation in Dual-Stack Networks | ||||||||||||||
|
The document analyzes contributing factors across the content service layer and the network transport layer, and discusses why existing mechanisms such as RFC 6724 and Happy Eyeballs do not fully address performance failures that appear after connection establishment. This document is limited to problem analysis, scope clarification, and areas for further study. It does not define new network-to-host signaling mechanisms or require hosts to use network-provided information when making address-family or path selection decisions. | |||||||||||||
| draft-pant-ai-mib-00.txt | ||||||||||||||
| AI-MIB: A Management Information Base Extension for Artificial Intelligence Infrastructure in Telecommunications Networks | ||||||||||||||
|
The rapid proliferation of Artificial Intelligence (AI) and Graphics Processing Unit (GPU) infrastructure within telecommunications networks has exposed a fundamental gap in existing network management frameworks. The Simple Network Management Protocol (SNMP), the de facto standard for network element monitoring since RFC 1157 (1990), provides no native support for monitoring AI accelerators, GPU clusters, high-bandwidth interconnects such as NVLink and InfiniBand, or AI workload telemetry. This document proposes AI-MIB: a Management Information Base extension that defines a standardised Object Identifier (OID) tree for AI infrastructure management within the SNMP framework. AI-MIB is designed to operate alongside existing Operations Support Systems and Business Support Systems (OSS/BSS) in telecommunications environments, preserving backward compatibility with SNMPv3 while extending the framework's scope to cover GPU health, accelerator interconnect metrics, AI workload performance indicators, and energy consumption. This document also outlines two future extensions: a subscription-based streaming capability for SNMPv3 (informally designated SNMPv3+), and a schema-mapping specification for a SNMP-gNMI Translation Gateway that bridges SNMP/ MIB and gNMI/YANG data models. | |||||||||||||
| draft-pantos-content-steering-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pantos-hls-rfc8216bis-22.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pardue-httpbis-patched-digest-00.txt | ||||||||||||||
| HTTP Patched Digest | ||||||||||||||
|
The PATCH method can be used to apply partial modifications to a resource. This document defines the Patched-Digest request field, which allows a client to indicate the integrity digest of the modified resource once a PATCH operation is applied. A server can use the integrity digest to detect an operation failure and return an error. The Want-Patched-Digest response field is also defined to signal server integrity preferences. | |||||||||||||
| draft-pardue-moq-qlog-moq-events-08.txt | ||||||||||||||
| MoQ qlog event definitions | ||||||||||||||
|
This document defines a qlog event schema containing concrete events for MoQ. | |||||||||||||
| draft-parecki-oauth-jwt-grant-interaction-response-00.txt | ||||||||||||||
| JWT Authorization Grant Interaction Response | ||||||||||||||
|
This document defines an extension to the JWT Authorization Grant [RFC7523] that enables an authorization server to indicate that user interaction is required in order to complete an authorization request. Instead of returning an access token or an error, the authorization server returns a URI that the client launches where the user can interact with the authorization server, along with a polling interval. The client can then poll for the access token or wait for a redirect before retrying the original request. | |||||||||||||
| draft-parecki-oauth-refresh-token-scope-response-00.txt | ||||||||||||||
| OAuth 2.0 Refresh Token Scope | ||||||||||||||
|
This specification defines a new OAuth 2.0 token response parameter, refresh_token_scope, that indicates the scope authorized for a refresh token when it differs from the scope of the access token issued alongside it. This allows clients to discover that a refresh token carries broader authorization than the initial access token, enabling just-in-time requests for elevated access without requiring a new authorization flow. | |||||||||||||
| draft-parsons-opsawg-security-operations-02.txt | ||||||||||||||
| Security Operations Fundamentals and Guidance | ||||||||||||||
|
Security operators are responsible for detecting malicious activity, responding to threats and defending their networks and systems from cyber attacks. Security operations are commonly entwined with other operational and management priorities to ensure that both security and operational priorities are considered holistically. With security operators being a crucial part of operation, management and security of the network, it is valuable to give consideration to them during the design of new protocols. This document builds upon draft-ietf-opsawg-rfc5706bis, describing the fundamentals of security operations to provide a foundation for considerations for protocol design and guidance. This document also describes how security operations considerations can be most usefully included in other IETF documents. | |||||||||||||
| draft-patel-omp-proximity-mesh-00.txt | ||||||||||||||
| Open Mesh Protocol (OMP): A Multi-Radio Proximity Mesh Networking Architecture and Problem Statement | ||||||||||||||
|
This document describes the Open Mesh Protocol (OMP), a proposed open standard for device-native proximity mesh networking spanning multiple radio technologies simultaneously. Existing proximity wireless mesh standards -- including Wi-Fi Aware (NAN), Bluetooth Mesh, and Thread -- each operate over a single radio technology and serve specific application domains. No existing open standard provides a unified multi-radio mesh routing protocol spanning BLE, WiFi Direct, and LoRa with per-device cryptographic identity independent of any central registry or carrier relationship. This document describes the OMP architecture, specific technical implementations, and the gap in the current standards landscape that OMP addresses. It is submitted as an Informational Internet-Draft to establish a public prior art record and to invite community discussion on whether a new working group or individual submission track is appropriate for this work. | |||||||||||||
| draft-pavann-bess-evpn-vlan-tag-00.txt | ||||||||||||||
| EVPN VLAN Tag Extended Community | ||||||||||||||
|
Ethernet Virtual Private Network (EVPN), as defined in RFC 7432, provides a control plane for distributing MAC and IP address bindings using BGP MAC/IP Advertisement routes. In several deployment scenarios, policy decisions depend not only on MAC/IP bindings but also on VLAN encapsulation information, particularly in environments using - IEEE 802.1Q VLAN tagging and IEEE 802.1ad provider bridging (QinQ). However, RFC 7432 does not define a mechanism to propagate VLAN information associated with MAC/IP bindings. This document defines a new EVPN Extended Community that carries VLAN identifiers to enable consistent policy enforcement across EVPN Provider Edge devices. This document does not modify EVPN route selection or forwarding behavior defined in RFC 7432. | |||||||||||||
| draft-paxton-aicp-00.txt | ||||||||||||||
| Agent Infrastructure Control Protocol | ||||||||||||||
|
Autonomous software agents increasingly inspect and modify infrastructure through provider-specific APIs and generic tool protocols. Those interfaces expose operations, but they do not provide a common semantic contract for obtaining bounded situational context, expressing an intended outcome under constraints, reviewing the exact material effects, binding authorization to those effects, observing durable execution, and determining whether the intended outcome was achieved. This document specifies the Agent Infrastructure Control Protocol (AICP). AICP is a transport-independent object and lifecycle model for capability discovery, situations, intents, plans, authorization decisions, asynchronous operations, verified outcomes, machine- actionable problems, and reconciliation. It also specifies an HTTP binding and describes mappings to existing agent protocols. AICP does not replace cloud resource APIs, orchestration languages, agent- to-agent protocols, authentication systems, or provider policy engines. | |||||||||||||
| draft-pearson-lcdp-04.txt | ||||||||||||||
| Lowest Common Denominator Protocol (LCDP) | ||||||||||||||
|
The Lowest Common Denominator Protocol (LCDP) is a message-oriented, peer-to-peer wire format consisting of UTF-8 encoded JSON arrays of externally tagged objects with object payloads transported over datagrams. LCDP provides perpetual compatibility by extension rather than versioning: unknown message types and fields are ignored. This document describes the wire format, core message types for peer discovery and anti-spoofing, and the design rationale. Security, reliability, and congestion control are delegated to optional messages or higher layers. | |||||||||||||
| draft-pei-opsawg-agentops-observability-00.txt | ||||||||||||||
| AgentOps Observability for Failure Detection and Attribution | ||||||||||||||
|
Agentic systems execute tasks through long-running sequences of model inference, planning, delegation, tool use, state updates, verification, and recovery. Conventional metrics, logs, and traces can identify a failed request but often cannot determine whether a failure is emerging, which actor introduced it, or which earlier event was its root cause. This document specifies an AgentOps observability event model and processing requirements for interoperable early failure detection and post-failure root-cause attribution. It defines common event, anomaly, assertion, and diagnosis records; distinguishes causal origins from propagated symptoms; and provides the evidence model required by separate benchmarks of detection lead time, responsible-actor attribution, and root-cause localization. The model is transport-neutral and can be carried by existing telemetry systems. | |||||||||||||
| draft-pelov-bounded-agent-capabilities-00.txt | ||||||||||||||
| Bounded Capabilities for Agent Tool Interfaces: Problem Statement | ||||||||||||||
|
Deployed agent tool-interface protocols carry JSON Schema type declarations for tools, but a type declaration is not a contract: nothing signals that a tool is fully schema-bounded, conformance to declared schemas is self-certified by the declaring party, declarations are not pinned between discovery time and invocation time, and error channels are untyped by design. As a consequence, any decision made about a tool call — authorization, discovery, audit, or composition — requires a language model to interpret what the call means, even for the large class of tools that are not intrinsically open-ended. This document states that problem and poses questions for the community. It deliberately proposes no mechanism. | |||||||||||||
| draft-pelov-icmpv6-sec-01.txt | ||||||||||||||
| ICMPv6 Secure Segment Treatment Notifications | ||||||||||||||
|
A packet can cross an IPv6 segment whose properties - long delay, scheduled contacts, a strict size budget - defeat the feedback an endpoint normally relies on. This document defines ICMPv6-SEC (SECure Segment Treatment), an ICMPv6 message that a segment boundary sends to a packet's source when the packet is not prepared for such a segment. The message carries a COSE-signed Segment Descriptor: a compact CBOR object stating which segment is meant, how long the statement is valid, and what treatment future packets require. A receiver applies a descriptor only after verifying the signature, the validity window, and that the signer is authorized for the segment. | |||||||||||||
| draft-pelov-rich-architecture-00.txt | ||||||||||||||
| RICH: RESTful Interface for the Control-plane of Harnesses | ||||||||||||||
|
This document specifies the RICH (RESTful Interface for the Control- plane of Harnesses) architecture and information model. RICH provides a protocol-neutral governance, contract, qualification, and binding layer for RPC-based agent capabilities. It establishes a REST-addressable control plane for managing capability lifecycles while preserving native protocol execution in the data plane. It defines immutable capability and contract revisions, evidence provenance, deterministic connector classes, compiled binding lockfiles, and runtime validation rules designed to contain drift and prevent confused deputy attacks in agentic systems. | |||||||||||||
| draft-pelov-schc-header-format-00.txt | ||||||||||||||
| SCHC Header Format | ||||||||||||||
|
The SCHC architecture separates a SCHC Control Header from a SCHC Data Header but leaves the format of the Control Header, the RuleID encoding, and the Discriminator deployment-specific. A node that handles a SCHC datagram without being a Compression/Decompression endpoint - a segment boundary, firewall, classifier, or capture tool - therefore cannot delineate the datagram. This document defines the SCHC Header Format: a small, named description of a SCHC datagram's framing - the RuleID encoding and the Control Header type - that can be conveyed in band (self-describing) or fixed out of band (by an RFC binding it to a demux point, by configuration, or by a signalling protocol such as ICMPv6-SEC). It defines the self-describing Shape Tag wire format and establishes the SCHC RuleID Encodings and SCHC Control-Header Types registries. | |||||||||||||
| draft-pels-dnsop-axfr-notify-01.txt | ||||||||||||||
| AXFR message type for DNS NOTIFY | ||||||||||||||
|
This document defines a new AXFR message type for DNS NOTIFY messages, together with an accompanying subtype for the ZONEVERSION EDNS(0) option. The message instructs a secondary server to perform an AXFR zone transfer of a zone. | |||||||||||||
| draft-peng-detnet-policing-jitter-control-03.txt | ||||||||||||||
| Mechanism to Control Jitter Caused by Ingress Shaping | ||||||||||||||
|
This document presents a noble mechanism to eliminate jitter caused by shaping delay on the network entrance node. It needs to be used in combination with a queueing mechanism that provides low jitter for the DetNet path, and ultimately provides a low jitter guarantee for the DetNet flow. | |||||||||||||
| draft-pereira-licet-human-intent-01.txt | ||||||||||||||
| LICET: Multi-Modal Physiological Human-Intent Verification for Autonomous AI Agent Authorization | ||||||||||||||
|
Autonomous AI agents executing consequential actions require authorization mechanisms that verify not only identity but voluntary intent. Existing mechanisms verify _who_ authorized an action; they cannot verify _whether the authorizing human was uncoerced and cognitively capable_ at the moment of authorization. This document specifies LICET (Latin: _it is permitted_), a cryptographic middleware protocol binding AI agent authorization to real-time multi-modal physiological state via a three-layer architecture: (1) ECG waveform morphology matching as a medication- resistant identity and liveness anchor; (2) electrodermal activity (EDA) as a sympathetic cholinergic liveness signal immune to beta- adrenergic blockade; and (3) personalized Mahalanobis distance fusion over five physiological signals to elevate the cost of pharmacological coercion attacks rather than claim binary detection. LICET defines a Biometric Trust Level hierarchy (L0-L3) aligned with the IETF RATS architecture (RFC 9334), a baseline calibration protocol establishing individual physiological profiles, per-event HKDF session-key derivation, HMAC biometric temporal signatures, Schnorr zero-knowledge proofs over BN128 enabling third-party audit without biometric exposure, and a SHA-256 hash-chained tamper-evident ledger. A reference implementation is publicly deployed at https://licet.dev/ v1/ and available as open source at https://github.com/christianrp45/ licet-protocol. | |||||||||||||
| draft-perkins-analysing-sdo-data-01.txt | ||||||||||||||
| Analysing Internet Standards Data | ||||||||||||||
|
This document outlines some issues to consider when studying data relating to the Internet standards development ecosystem. It identifies observable components of standards development processes, proposes a taxonomy of possible measurements, and highlights methodological, interpretive, and ethical considerations. It is intended to support a range of uses, including monitoring standards development organisations (SDOs), evaluating the evolution of technical work, understanding technology deployment, and informing community, leadership, and governance discussions. This document is submitted for consideration by the Research and Analysis of Standard-Setting Processes Research Group (RASPRG) in the IRTF. It is not an IETF product and is not a standard. | |||||||||||||
| draft-perkins-role-of-irtf-05.txt | ||||||||||||||
| The Role of the Internet Research Task Force (IRTF) | ||||||||||||||
|
This memo discusses the role of the Internet Research Task Force (IRTF), considering its research groups, community, and the various workshops, prizes, and other activities it supports. The relationship of the IRTF to the IETF is also considered. This memo is a product of the Internet Research Steering Group (IRSG). It is not an IETF product and is not a standard. | |||||||||||||
| draft-petra-green-api-04.txt | ||||||||||||||
| Path Energy Traffic Ratio API (PETRA) | ||||||||||||||
|
This document describes an API to query a network regarding its Energy Traffic Ratio for a given path. | |||||||||||||
| draft-petrie-grow-mrt-bmp-02.txt | ||||||||||||||
| Storing BMP messages in MRT Format | ||||||||||||||
|
This document extends the Multi-threaded Routing Toolkit (MRT) export format to support the storage of BMP messages. | |||||||||||||
| draft-pham-cfrg-hiae-06.txt | ||||||||||||||
| The HiAE Authenticated Encryption Algorithm | ||||||||||||||
|
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. | |||||||||||||
| draft-phelan-dtl-00.txt | ||||||||||||||
| DTL: Dyadic Typed Layer | ||||||||||||||
|
DTL (Dyadic Typed Layer) defines a single, minimal primitive: a typed, directed relationship between two agents that the controller of each agent has confirmed, together with the lifecycle of that relationship. The name describes the primitive: Dyadic (it concerns one pair of parties), Typed (the relationship carries exactly one kind), and Layer (it sits above an identity substrate, not inside it). Agent ecosystems have built out several coordination layers: identity (who an agent is), reputation and attestation (what is asserted about an agent), and discovery and messaging (how agents find and talk to each other). One primitive is comparatively underserved, the relationship: a standing, acknowledged, directed connection between two specific agents, recording that they are related and in what capacity. No existing standard, to the author's knowledge, provides exactly this primitive in this form. DTL specifies it and nothing more. It is normative about the mechanism (a typed, directed, two- party, controller-confirmed edge and its lifecycle) and deliberately silent about substrate, transport, storage, and the open vocabulary of relationship types. An informative binding to ERC-8004 is provided as the first anchoring substrate. | |||||||||||||
| draft-pidlisnyi-aps-03.txt | ||||||||||||||
| Agent Passport System (APS): Verifiable Agent Identity,Faceted Authority,and Signed Action Receipts | ||||||||||||||
|
This document specifies the Agent Passport System (APS), a protocol for identifying AI agents, attenuating delegated authority, and producing signed evidence at policy-enforcement boundaries. APS defines Ed25519 agent passports; separately signed principal bindings; delegation chains that cannot widen across scope, spend, depth, time, reputation, values, or reversibility; deterministic action and decision references; and a common envelope for signed action receipts. It also defines bindings for Model Context Protocol tool calls and imported OAuth identity-assertion authorization grants. Verification results keep cryptographic integrity, signer authority, referenced-artifact resolution, policy semantics, and external truth separate. An Implementation Status section identifies the exact coverage and maturity of the available open-source implementations. | |||||||||||||
| draft-pignataro-icmp-enviro-info-03.txt | ||||||||||||||
| ICMP Extensions for Environmental Information | ||||||||||||||
|
This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility into environmental information on the internet by providing per-hop (i.e., per topological network node) power metrics and other present or future metrics around environmental information. This will contribute to achieving an objective mentioned in the report of the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental information. | |||||||||||||
| draft-pinkert-intarea-user-assign-ipv4-opt-nrs-00.txt | ||||||||||||||
| User assignable IPv4 option numbers | ||||||||||||||
|
The use of IPv4 options on the public internet is limited due to the fact that many currently defined IPv4 options have issues, as indicated in [BCP186]. This serves as an argument to refuse new option definitions for IPv4, even if the proposed IP options have no such issues, and have valid use cases on limited domains, or for limited end-host domains communicating over private networks or the public internet. This I-D defines a limited range of N IPv4 option numbers for variable assignment, by the user, to types of IP options to be used on limited domains and for limited end-host domains on the public internet. This will enable the use of IP options in two major use cases, without the need to fully standardize IP options, or register numbers for them in the IANA IP option numbers table. | |||||||||||||
| draft-pinkert-ippm-inter-layer-protocol-01.txt | ||||||||||||||
| Inter-layer Protocol | ||||||||||||||
|
This document describes an inter-layer protocol, that can be used to insert an arbitrary number of headers between the internet protocol (IPv4, IPv6) header and a layer four header like the UDP or TCP header. By doing so, it consumes part of the space available for IP payload data. It is, in particular, useful to extend the space reserved for IP options as defined in the IPv4 protocol [RFC791]. | |||||||||||||
| draft-pinkert-ippm-ip-measurement-option-03.txt | ||||||||||||||
| An IPv4 and IPv6 measurement option (MO) for hybrid flow measurements. | ||||||||||||||
|
This document introduces an internet protocol (IP) measurement option (MO) that contains information, normally not available to the receiver of IP packets, to perform hybrid network measurements. In particular, measurements that need a sender time stamp and a packet order number are then possible directly at the receiver. The information contained in the IP MO can also be used by hosts en-route to perform slightly more limited hybrid network measurements. | |||||||||||||
| draft-pinto-agent-authz-contestability-01.txt | ||||||||||||||
| Contestability Bindings for Authorized Agent Actions | ||||||||||||||
|
Authorization artifacts can provide signed evidence of a permission under specified authorization rules. Receipts can record a signed claim or protocol event that the authorization was exercised, and outcome evidence can describe what followed. None of those artifacts necessarily tells a person or organization affected by the action where the authorization can be contested, which procedure applies, whether a filing changes execution state, or who selected the contestation forum. This document defines a transport-independent Contestability Binding for authorized agent actions. The binding commits an authorization to a versioned Contestation Parameters Object that identifies the forum, submission mechanism, Standing Policy, procedure, time bounds, declared effect policy, and selection evidence. A forum can acknowledge one exact authorization or publish a reusable acceptance manifest for closed Authorization Binding Profile and Authorization Trust Profile identifier pairs. A deterministic verifier validates the binding, separately classifies evidence claiming pre-execution verification by the executor, and reports forum-selection provenance as unilateral, multiparty, externally selected, or indeterminate. Where a filing is declared to affect execution state, the verifier also separates the issuer's declared policy, the executor's signed acceptance, the authenticated trigger, and the executor's claimed application. The mechanism makes the bound contestation parameters identifiable and verifiable, supporting discoverability while resisting post- action substitution. It does not determine standing, prove forum independence, resolve a dispute, select a remedy, establish legal enforceability, or decide whether the original authorization was legitimate. | |||||||||||||
| draft-pinto-cbap-1-00.txt | ||||||||||||||
| Contestability Binding Application Profile 1 (CBAP-1) | ||||||||||||||
|
Signed authorization records can show that an action was authorized under specified rules, but they do not by themselves establish a stable or verifiable path for an Affected Party to contest that action. This document defines Contestability Binding Application Profile 1 (CBAP-1), a closed application profile that binds an Authorization Artifact to signed contestation terms before execution. CBAP-1 specifies deterministic CBOR and COSE encoding, fixed artifact formats, executor-verification and execution records, by-value policy material, a half-open filing window, a closed structured result, and deterministic first-failure reason codes. CBAP-1 does not define contestation notices, active execution-state effects, network reachability checks, policy-freshness evaluation, dispute adjudication, or remedy. It reports authenticated protocol facts and signed claims without asserting forum independence, legal validity, physical execution order, or fairness. | |||||||||||||
| draft-piraux-space-constellation-code-02.txt | ||||||||||||||
| A code to describe satellite constellations | ||||||||||||||
|
When considering a satellite constellation forming a non-terrestrial network, the characteristics of this constellation heavily influence the network topology it forms. To improve the analysis of such non- terrestrial networks across various tools developed by the network community, this document defines a constellation code to describe common orbital shell patterns, and specification formats to describe inter-satellite link topologies and ground stations, covering the Core and Ground Networks of a constellation. In addition, this document may serve as an introduction to satellite constellations for IETF participants. | |||||||||||||
| draft-piraux-tcp-ao-tls-04.txt | ||||||||||||||
| Opportunistic TCP-AO with TLS | ||||||||||||||
|
This document specifies an opportunistic mode for TCP-AO when used with TLS. In this mode, the TCP connection starts with a well-known authentication key which is later replaced by a secure key derived from the TLS handshake. | |||||||||||||
| draft-pocero-authkem-ikr-edhoc-03.txt | ||||||||||||||
| KEM-based Authentication for EDHOC in Initiator-Known Responder (IKR) Scenarios | ||||||||||||||
|
This document specifies a more efficient variant of a Key Encapsulation Mechanism (KEM)-based authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) lightweight protocol, designed for the specific scenario in which the Initiator has prior knowledge of the Responder’s credentials, a case commonly found in constrained environments. Improving upon the approach described in KEM-based Authentication for EDHOC, this method uses only a mandatory three-message handshake to enable signature-free post-quantum authentication when PQC KEMs, such as the NIST-standardized ML-KEM, are employed, while still providing mutual authentication, forward secrecy, and a degree of identity protection. | |||||||||||||
| draft-pocero-lake-authkemsig-edhoc-01.txt | ||||||||||||||
| KEM/Signature-Based Methods for Scenarios with Asymmetric Device Constraints | ||||||||||||||
|
This document extends the KEM-based Authentication for EDHOC draft by defining additional quantum-resistant authentication methods that support combined authentication approaches, where one party authenticates using a KEM-based mechanism and the other using a post- quantum signature scheme. | |||||||||||||
| draft-poirier-rats-eat-da-10.txt | ||||||||||||||
| An EAT Profile for Trustworthy Device Assignment | ||||||||||||||
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust an assigned device, the device must provide the TVM with attestation Evidence confirming its identity, the state of its firmware and configuration. Since Evidence claims can be processed by 3rd party entities (e.g., Verifiers, Relying Parties) external to the TVM, there is a need to standardize the representation of DA-related information in Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. | |||||||||||||
| draft-polli-restapi-ld-keywords-09.txt | ||||||||||||||
| REST API Linked Data Keywords | ||||||||||||||
|
This document defines two keywords to provide semantic information in OpenAPI Specification and JSON Schema documents, and support contract-first semantic schema design. | |||||||||||||
| draft-popov-webbotauth-semantic-anchor-00.txt | ||||||||||||||
| Identity Anchor for Domain-Root AI Discovery (Semantic Anchor) | ||||||||||||||
|
Automated clients, including Large Language Model (LLM) crawlers and Retrieval-Augmented Generation (RAG) systems, currently lack a deterministic mechanism to verify the canonical identity of a web domain's operator. This "Identity Gap" results in attribution loss and prevents the automated verification of authority and expertise signals. This document defines the Semantic Anchor: a protocol-level orchestration of a domain-root, machine-readable JSON-LD identity node discoverable via predictable endpoints. It establishes a stable identity layer and a "Root of Trust" for AI-to-site interactions. | |||||||||||||
| draft-porfiri-tsvwg-sctp-dtls-handshake-01.txt | ||||||||||||||
| Transport Layer Security (TLS) based key-management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk | ||||||||||||||
|
This document defines how Transport Layer Security (TLS) 1.3 is used as a key-management method for the SCTP DTLS Chunk mechanism. It specifies how a TLS handshake establishes the initial security context for an SCTP association and how subsequent TLS handshakes provide key updates and re-authentication. The goal is to enable authenticated and confidential communication over SCTP using the DTLS Chunk, leveraging standardized TLS 1.3 features for key management and rekeying. | |||||||||||||
| draft-pq-secchannel-00.txt | ||||||||||||||
| PQ-SecChannel Protocol Specification | ||||||||||||||
|
This document specifies the PQ-SecChannel cryptographic protocol, which defines a secure interactive channel consisting of a Transport Authentication Protocol and a Connection Protocol. The protocol is designed to provide confidentiality, integrity, and mutual authentication in the presence of quantum computing threats. PQ- SecChannel incorporates standardized post-quantum cryptographic algorithms, including lattice-based KEMs and signatures (e.g., Kyber and Dilithium), Chinese post-quantum candidate algorithms (e.g., Aigis), and code-based KEMs (e.g., HQC), together with SM4-GCM for AEAD (Authenticated Encryption with Associated Data) and SM3 for hashing and key derivation. This specification is derived from the Chinese national cryptography standard draft "PQ-SecChannel Cryptographic Protocol Specification", adapted into IETF Internet- Draft style for international review and potential interoperability consideration. The protocol content also references the Secure Shell architecture ([RFC4251], [RFC4252], [RFC4253], and [RFC4254]) and the Chinese SSH cryptographic protocol specification [GMT0129]. | |||||||||||||
| draft-pq-sectunnel-00.txt | ||||||||||||||
| PQ-SecTunnel Protocol Specification | ||||||||||||||
|
This document specifies the PQ-SecTunnel protocol, a UDP-based quantum-resistant IP tunnel derived from the WireGuard architecture. Session keys are established by a three-message Noise_IKpsk1kem handshake that replaces Diffie-Hellman with dual Key Encapsulation Mechanism (KEM) operations (static and ephemeral). Authentication is implicit: peers prove possession of long-term KEM private keys through interlocking encapsulations rather than signing the transcript. The protocol is organized as a multi-suite framework. Implementations MAY select ML-KEM-512 or ML-KEM-768 independently for the static and ephemeral KEM roles. This document RECOMMENDS the profile static=ML-KEM-512, ephemeral=ML-KEM-768, AEAD=SM4-GCM, Hash=SM3 (denoted mlkem512-mlkem768-sm4gcm-sm3). Other ML-KEM combinations with the same AEAD/Hash, and additional KEM families such as Aigis-enc (integration ongoing), are optional profiles. | |||||||||||||
| draft-prabel-cfrg-suf-hybrid-sigs-02.txt | ||||||||||||||
| Hybrid Digital Signatures with Strong Unforgeability | ||||||||||||||
|
This document proposes a generic hybrid signature construction that achieves strong unforgeability under chosen-message attacks (SUF- CMA), provided that the second component (typically the post-quantum one) is SUF-CMA secure. The proposed hybrid construction differs from the current composite hybrid approach by binding the second (post-quantum) signature to the concatenation of the message and the first (traditional) signature. This approach ensures that hybrid signatures maintain SUF-CMA security even when the first component only provides EUF-CMA security. In addition to this general hybrid construction, this document also proposes a non-black-box variant specifically tailored for schemes built from the Fiat-Shamir paradigm. This variant is SUF-CMA secure as long as only one component is SUF-CMA secure. | |||||||||||||
| draft-prabel-pquip-pqc-overview-00.txt | ||||||||||||||
| Post-Quantum Algorithms Overview | ||||||||||||||
|
This document summarizes publicly available information on a range of widely studied post-quantum cryptographic algorithms, including Key Encapsulation Mechanisms (KEMs) and digital signature schemes. It aggregates parameters and high-level security assumptions from existing specifications and standardization efforts, serving as a unified informational reference. This document is purely informational. It does not provide guidance, recommendations, or requirements regarding algorithm selection, deployment, or migration strategies. | |||||||||||||
| draft-prabhu-nmrg-prompt-schema-llm-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pradeepkumarxplorer-videosurfing-00.txt | ||||||||||||||
| The LIMITS SMTP Service Extension | ||||||||||||||
|
To allow browsing in videos | |||||||||||||
| draft-prakash-aip-01.txt | ||||||||||||||
| Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems | ||||||||||||||
|
This document specifies the Agent Identity Protocol (AIP), a protocol for verifiable, delegable identity for AI agent systems. AIP introduces Invocation-Bound Capability Tokens (IBCTs) that bind identity, authorization, scope constraints, and provenance into a single cryptographic artifact. Two token modes are defined: a compact mode using JSON Web Tokens (JWT) with Ed25519 signatures for single-hop interactions, and a chained mode using Biscuit tokens with append-only blocks and Datalog policy evaluation for multi-hop delegation chains. Protocol bindings are specified for the Model Context Protocol (MCP), Agent-to-Agent Protocol (A2A), and generic HTTP APIs. The protocol addresses authentication gaps in current AI agent infrastructure where a survey of approximately 2,000 MCP servers found all lacked authentication. This revision specifies a normative verification algorithm, defines the canonical policy encoding for chained mode, describes how AIP composes with workload identity systems such as SPIFFE, and maps AIP against the cross- organization delegation requirements enumerated in [I-D.reece-wimse-cross-org-delegation]. | |||||||||||||
| draft-prakash-http-subscribe-00.txt | ||||||||||||||
| The HTTP SUBSCRIBE Method | ||||||||||||||
|
This document defines the HTTP SUBSCRIBE request method. The SUBSCRIBE method allows a client to establish a long-lived, safe connection to a resource to receive real-time updates and event streams. It enables servers to push data to clients using standard HTTP structures (such as HTTP/2 or HTTP/3 streams) while supporting a request body for subscription parameters, avoiding the protocol- switching overhead of WebSockets and the URL limitations of Server- Sent Events (SSE) via GET. | |||||||||||||
| draft-praveen-fann-lq-telemetry-info-00.txt | ||||||||||||||
| A YANG Data Model for Link Quality Telemetry in CLOS Data Center Fabrics | ||||||||||||||
|
This document defines a YANG data model for real-time link quality telemetry in multi-stage CLOS (leaf-spine) data center fabrics. The data model provides a vendor-agnostic representation of link congestion state, enabling next-next-hop (NNH) path quality visibility required for adaptive routing in AI/ML training networks. The link quality advertisement is modeled as a YANG data structure, making the model directly usable with any transport. The data model is deliberately decoupled from any transport. A lightweight UDP transport binding for disseminating the modeled data is specified in a companion document; additional transport bindings may be specified in future documents. | |||||||||||||
| draft-praveen-fann-lq-telemetry-udp-00.txt | ||||||||||||||
| A UDP Transport Binding for Link Quality Telemetry in CLOS Data Center Fabrics | ||||||||||||||
|
This document specifies a UDP transport binding for the Link Quality Telemetry data model. The binding disseminates YANG-modeled link quality data between directly connected switches in multi-stage CLOS (leaf-spine) data center fabrics using a compact, fixed-offset binary encoding designed for forwarding-plane (ASIC) generation and consumption, achieving sub-100 microsecond notification latency on forwarding engines capable of data-plane UDP processing. The encoded payload can be carried natively on a dedicated UDP port or as a TLV within the Router-Info advertisement mechanism; both carriages share a byte-identical payload. The data model, receiver processing rules, and requirements applicable to all transport bindings are defined in a companion document. | |||||||||||||
| draft-premont-lamps-drl-stapling-00.txt | ||||||||||||||
| TLS Extension for Distributed Revocation Ledger (DRL) Stapling using a Sparse Merkle Tree | ||||||||||||||
|
Managing certificate revocation remains a recurring challenge in the Web Public Key Infrastructure (WebPKI). Existing solutions such as Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP) involve compromises in terms of propagation latency, availability, and user privacy. With the planned deprecation of OCSP by some major Certificate Authorities (CAs), there is renewed interest in alternatives. This document specifies a decentralized certificate revocation architecture based on a Distributed Revocation Ledger (DRL) managed collectively by CAs. The ledger state is maintained as a Sparse Merkle Tree (SMT) in which only revoked certificates occupy non- default leaves, so that a valid certificate is attested by a compact non-membership proof and no prior registration of valid certificates is required. This document further defines a new Transport Layer Security (TLS) extension enabling "DRL Stapling", which allows a server to provide a client with a cryptographic proof of a certificate's status, consisting of a Sparse Merkle audit path and an M-of-N threshold signature from the CA consortium. The approach builds on the Revocation Transparency proposal of Laurie and Kasper and on subsequent formalizations of Sparse Merkle Trees; its novel contributions are the decentralized threshold-signature trust model with deterministic finality and the concrete TLS wire format. | |||||||||||||
| draft-prf-protocol-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-pro-adp-agent-discovery-02.txt | ||||||||||||||
| Agent Discovery Protocol (ADP) v1.1 -- Well-Known Metadata and Interaction Layer | ||||||||||||||
|
This document defines the Agent Discovery Protocol (ADP) v1.1, a layered protocol for discovering, verifying, and interacting with AI Agents on the Internet. ADP delegates DNS discovery to DNS-AID (SVCB records) and defines a Well-Known JSON metadata format, an Ed25519-based identity model, and the Agent Gateway Protocol (AGP) for real-time WebSocket messaging. The protocol is designed to be decentralized, standards-based, and incremental — clients escalate from DNS to HTTP to WebSocket only as needed. | |||||||||||||
| draft-projecttick-mmco-mmcs-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-prz-lsr-ash-packets-02.txt | ||||||||||||||
| IS-IS Aggregated SNP Hash Packets | ||||||||||||||
|
The document presents an optional new type of database synchronization packet called an Aggregated SNP Hash (ASH). When feasible, it compresses traditional SNP exchanges into a dynamic Merkle tree-like structure, which speeds up synchronization of large databases and adjacency numbers while reducing the load from regular CSNP exchanges during normal operation. Just like CSNPs and PSNPs, ASH packets come in two flavors, called Complete ASH (CASH) and Partial ASH (PASH). | |||||||||||||
| draft-przygienda-rift-dragonfly-02.txt | ||||||||||||||
| RIFT in Dragonfly Topologies | ||||||||||||||
|
RIFT extensions for dragonfly topologies. | |||||||||||||
| draft-psenak-lsr-igp-dcm-00.txt | ||||||||||||||
| Distributed Congestion Mitigation | ||||||||||||||
|
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. | |||||||||||||
| draft-pskim-ros2-quic-mqtt-00.txt | ||||||||||||||
| QUIC Application for ROS2 with MQTT | ||||||||||||||
|
While DDS (Distributed Data Service) protocol, managed by Object Management Group (OMG), for ROS (Robot Operating System) 2 is intended to provide a universal communication layer, interoperability across different DDS middleware implementations is not always consistent. Variations in transport protocol usage (e.g., TCP/IP, UDP, shared memory) can hinder direct data exchange, and cross-domain communication efficiency is generally lower compared to protocols such as HTTP. Therefore, to resolve limitations of DDS in ROS2, this draft considers a couple of standards protocols, QUIC of IETF and MQTT (Message Queuing Telemetry Transport), managed by OASIS Open. | |||||||||||||
| draft-pwouters-ipsecme-delete-info-04.txt | ||||||||||||||
| IKEv2 support for specifying a Delete notify reason | ||||||||||||||
|
This document defines the DELETE_REASON Notify Message Status Type Payload for the Internet Key Exchange Protocol Version 2 (IKEv2) to support adding a reason for the deletion of the IKE or Child SA(s). | |||||||||||||
| draft-pythia-bmwg-programmable-power-profiling-00.txt | ||||||||||||||
| Power Consumption Profiling for Programmable Network Devices | ||||||||||||||
|
A programmable network device can execute different packet-processing programs on the same hardware. Device-level power measurements show the total input power but do not explain the power associated with a program's parser, match-action tables, and stateful or stateless actions. Models designed for fixed-function switches do not directly describe these program-dependent operations. This document describes a power profiling methodology for programmable network devices. The methodology decomposes packet processing into functional components, uses controlled calibration programs to derive target-specific parameters, and estimates the power of a data-plane program from its processing features and traffic. It also specifies validation and reporting requirements that distinguish direct measurements from model-derived estimates. The methodology is based on implementation experience with an ASIC programmable switch and an FPGA-based programmable switch. | |||||||||||||
| draft-qin-bmwg-rpki-rp-bench-01.txt | ||||||||||||||
| Benchmarking Methodology for RPKI Relying Party | ||||||||||||||
|
This document defines a benchmarking methodology for evaluating RPKI Relying Party (RP) implementations in controlled laboratory environments. The methodology focuses on whether RP implementations correctly perform required validation steps and on the performance of these operations. RP implementations are treated as black boxes, enabling consistent and objective assessment based on externally observable behavior rather than internal design or implementation details. | |||||||||||||
| draft-qin-savnet-bicone-sav-01.txt | ||||||||||||||
| Bicone Source Address Validation | ||||||||||||||
|
Source address validation (SAV) aims to detect source-spoofed traffic while avoiding improper blocking of legitimate traffic. Existing SAV mechanisms commonly rely on ingress allowlist filters on interfaces facing customer or lateral peer Autonomous Systems (ASes). When such an allowlist is incomplete, a source address not covered by the allowlist cannot be conclusively identified as spoofed, because legitimate source prefixes may be missing from the allowlist. This document describes Bicone SAV, which jointly uses an allowlist derived from customer-cone information and a blocklist containing prefixes that can be positively identified as inappropriate on the corresponding ingress interface. When the allowlist is incomplete, packets matching the allowlist are permitted, packets matching the blocklist are discarded, and packets matching neither list are permitted with logging or other monitoring for subsequent analysis. The blocklist can be constructed from provider-cone information and augmented with denylist information derived from customer cones. | |||||||||||||
| draft-qin-savnet-sav-monitoring-requirements-00.txt | ||||||||||||||
| Information Requirements for Monitoring Source Address Validation (SAV) Enforcement | ||||||||||||||
|
Source Address Validation (SAV) enforcement requires operational visibility into validation results, traffic-handling outcomes, SAV rule generation and state, and SAV configuration. Such visibility helps operators understand how SAV operates in the network and supports operational decisions, including staged deployment where traffic that fails validation may be permitted while being monitored and analyzed. This document identifies information requirements for monitoring SAV enforcement. | |||||||||||||
| draft-qin-savnet-toa-02.txt | ||||||||||||||
| A Profile for Traffic Origin Authorizations (TOAs) | ||||||||||||||
|
This document defines a standard profile for Traffic Origin Authorizations (TOAs), a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI). A TOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate traffic using source IP addresses within the address block. | |||||||||||||
| draft-qu-ipv6-quantum-key-sync-negotiation-00.txt | ||||||||||||||
| Abstract | ||||||||||||||
|
This document provides a mechanism for synchronizing and negotiating quantum keys by carrying quantum key information through IPv6 extension headers. The communicating parties select the corresponding encryption and decryption keys from the quantum key library based on the negotiation results, thereby achieving quantum-encrypted communication over IPv6 network. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." | |||||||||||||
| draft-quan-l4s-ioam-02.txt | ||||||||||||||
| IOAM network awareness for Low Latency,Low Loss,and Scalable Throughput (L4S) | ||||||||||||||
|
This document specifies a framework that uses operational and telemetry information collected by In Situ Operations, Administration, and Maintenance (IOAM) to support the monitoring and parameter adjustment of an L4S Dual-Queue Coupled AQM within a single limited domain. IOAM Direct Export reports path and node information, such as hop-by-hop delay and queue depth, to an IOAM Control Center (IOAM-C). The IOAM-C correlates this information and may adjust operator-configurable AQM target or threshold parameters within configured bounds. This document does not modify the L4S ECN protocol, the IOAM data formats, or the packet forwarding behavior defined by the referenced specifications. | |||||||||||||
| draft-rabadan-bess-evpn-srv6-ar-00.txt | ||||||||||||||
| Applicability of EVPN Assisted Replication to SRv6 Tunnels | ||||||||||||||
|
Assisted Replication (AR) is an optimized ingress replication solution for Ethernet VPN (EVPN) Broadcast and Multicast (BM) traffic. AR offloads the replication effort from ingress Network Virtualization Edge (NVE) devices onto Assisted Replication Replicators (AR-REPLICATORs). The base AR specification is focused on Network Virtualization Overlay (NVO) networks that use IP tunnels, and it is typically deployed for Virtual eXtensible Local Area Network (VXLAN). EVPN services can also be instantiated over Segment Routing over IPv6 (SRv6); however, the SRv6 EVPN transport specification supports only ingress replication for BUM traffic, and the AR procedures rely on IP-tunnel semantics (such as the tunnel source and destination IP addresses) that do not map exactly to an SRv6 data plane. As a result, AR cannot be readily deployed over SRv6 tunnels. This document specifies the applicability of Assisted Replication to SRv6 tunnels, for EVPN BM traffic, for selective multicast based on Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) proxy, and for EVPN IP multicast traffic based on Optimized Inter-Subnet Multicast (OISM). It defines a new SRv6 Endpoint behavior for the AR-REPLICATOR role and the associated control-plane procedures, so that the AR solution can be used with an SRv6 underlay. | |||||||||||||
| draft-rabnic-bess-evpn-mcast-eeg-07.txt | ||||||||||||||
| EVPN Multicast Forwarding for EVPN to EVPN Gateways | ||||||||||||||
|
This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. | |||||||||||||
| draft-rabsaj-bess-evpn-vxlan-ir-bum-01.txt | ||||||||||||||
| Ingress Replication BUM flag in VXLAN | ||||||||||||||
|
This document proposes the allocation of an “Ingress Replication BUM” flag in the VXLAN Flags IANA registry and defines its use in EVPN networks that employ VXLAN tunnels with ingress replication to forward broadcast, unknown and multicast traffic. | |||||||||||||
| draft-rajappa-httpbis-connection-contamination-06.txt | ||||||||||||||
| Mitigating HTTP/3 Connection Contamination in Multi-Tenant and CDN-Fronted Deployments | ||||||||||||||
|
HTTP/3 [RFC9114] clients commonly reuse ("coalesce") an existing QUIC [RFC9000] connection for requests to a second origin when the TLS certificate presented on that connection is also valid for the second origin, even though the two origins may route to entirely different backends. This document describes "connection contamination," a class of security exposure that arises when a routing layer -- reverse proxy, load balancer, or CDN edge -- determines backend routing using a signal established at connection setup rather than re-validated per request. Under that condition, a coalesced connection can be used to reach an unintended backend origin, potentially enabling cross-tenant data leakage, authentication bypass, and response-queue interference analogous to HTTP request smuggling. This document defines the underlying mechanism, characterizes the attacker model, distinguishes connection contamination from related QUIC exposures, and provides normative operational guidance for implementers and operators of HTTP/3-terminating infrastructure. | |||||||||||||
| draft-ramakrishna-satp-data-sharing-05.txt | ||||||||||||||
| Protocol for Requesting and Sharing Views across Networks | ||||||||||||||
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Systems and networks can define and project views, or asset states, outside of their boundaries, as well as guard them using access control policies, and external agents or other systems can address those views in a globally unique manner. Universal interoperability requires such systems and networks to request and supply views via gateway nodes using a request-response protocol. The endpoints of this protocol lie within the respective systems or in networks of peer nodes, but the cross-system protocol occurs through the systems’ respective gateways. The inter-gateway protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT-neutral and mask the internal particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective networks. | |||||||||||||
| draft-ramakrishna-satp-views-addresses-07.txt | ||||||||||||||
| Views and View Addresses for Secure Asset Transfer | ||||||||||||||
|
With increasing use of DLT (distributed ledger technology) systems, including blockchain systems and networks, for virtual assets, there is a need for asset-related data and metadata to traverse system boundaries and link their respective business workflows. Core requirements for such interoperation between systems are the abilities of these systems to project views of their assets to external parties, either individual agents or other systems, and the abilities of those external parties to locate and address the views they are interested in. A view denotes the complete or partial state of a virtual asset, or the output of a function computed over the states of one or more assets, or locks or pledges made over assets for internal or external parties. Systems projecting these views must be able to guard them using custom access control policies, and external parties consuming them must be able to verify them independently for authenticity, finality, and freshness. The end-to- end protocol that allows an external party to request a view by an address and a DLT system to return a view in response must be DLT- neutral and mask the interior particularities and complexities of the DLT systems. The view generation and verification modules at the endpoints must obey the native consensus logic of their respective systems. | |||||||||||||
| draft-ramasamy-idr-sr-policy-composite-perflow-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-ramos-asdf-api-translation-03.txt | ||||||||||||||
| Semantic Definition Format (SDF) for API translation | ||||||||||||||
|
This document defines an extension to the Semantic Definition Format (SDF) that enables API translation between applications and devices. The translation enables clarification of complex syntax for a service or device to utilize a different API from the one that was first designed to use. | |||||||||||||
| draft-rampalli-cross-org-delegation-mapping-05.txt | ||||||||||||||
| A Layered Requirements Mapping for Cross-Organization Agent Delegation | ||||||||||||||
|
This document records a comparative mapping of two evidence layers for cross-organization AI agent delegation: a per-hop delegation chain (PEDIGREE) and a named-human authorization root (the EMILIA Protocol binding and evidence-graph drafts), evaluated against the nine requirements of draft-reece-wimse-cross-org-delegation under a no-shared-operator assumption. It also records a verifier-facing composition model in which key possession, delegated authority, and pre-execution human authorization are diagnostically separate inputs with independent failure behavior, joined by action digest. The mapping was developed on the WIMSE mailing list; corrections continue there. | |||||||||||||
| draft-rampalli-pedigree-00.txt | ||||||||||||||
| PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems | ||||||||||||||
|
This document defines PEDIGREE (Per-Agent Delegation Identity with Governance-Enforced Execution), an identity and delegation framework for AI agents that extends the workload-identity model of SPIFFE (RFC 9542 / draft-ietf-wimse) with cryptographic per-hop delegation, monotonic scope attenuation enforced at mint and at verify, and dual- layer authority enforcement combining an operator-controlled ceiling with per-parent mandate narrowing. PEDIGREE complements AAuth (draft-hardt-aauth-protocol) and AIP (draft-prakash-aip) by providing: (a) dual-enforcement semantics absent from both, (b) Cedar-policy mandates with static-analysis proofs of narrowing, (c) strict cryptographic parent-token re- verification that catches parent-swap attacks missed by append-only token chains, and (d) a native bridge to existing SPIFFE deployments. | |||||||||||||
| draft-rampalli-scitt-capsule-provenance-binding-00.txt | ||||||||||||||
| Binding Per-Action Authorization and Memory Provenance into Agent Action Capsules | ||||||||||||||
|
The Agent Action Capsule (AAC) profile (draft-mih-scitt-agent-action- capsule) records what an autonomous agent actually did -- executed, blocked, denied, errored, or timed out -- with a structural binding that prevents an attempt from being presented as a completion. AAC deliberately does not define the authority that permitted an action; it carries that authority as an opaque reference. Two companion profiles supply what that reference can point to: a per-action authorization profile (draft-rampalli-aiagent-authz-hmac) records that an action was permitted (the "may"), and a memory-provenance profile (draft-rampalli-aiagent-memory-provenance) records the source and trust state of the belief on which the agent acted (the "why- believed"). This document specifies how the latter two are bound into an AAC Capsule. It defines (a) what the AAC "disposition.authority" reference MAY resolve to, (b) a namespaced, payload-only extension carrying an authorization-token reference, a memory chain root, and a quarantine attestation, and (c) an OPTIONAL divergence-class value, drawn from the per-action profile, that explains a non-executing AAC verdict. The binding uses only mechanisms AAC already provides -- the opaque authority reference and the payload-extension namespacing convention -- and changes neither AAC's closed protected-header claim set nor its Class 1 verification. The result is a single verifiable record that answers "may," "did," and "why-believed" together. | |||||||||||||
| draft-rampalli-suradar-00.txt | ||||||||||||||
| SURADAR: Context-Bound Per-Request Authentication for Machine-to-Machine APIs | ||||||||||||||
|
This document defines SURADAR (Subsurface Undertow RADAR), an HTTP authentication scheme in which each request is authenticated by a one-time HMAC tag derived from a shared seed, the current time band, and the full request context (method, path, organisation, scope, and body). Unlike bearer-token schemes, a captured SURADAR token is cryptographically bound to exactly one request and cannot be reused, replayed, or re-scoped. The protocol requires zero per-request handshakes, produces 48-byte tokens, and relies solely on HMAC- SHA-256 and SHA-256 -- no asymmetric cryptography. | |||||||||||||
| draft-ranjbar-dane-anchored-identity-00.txt | ||||||||||||||
| DANE-Anchored Identity for Network Clients,Devices,and Autonomous Agents | ||||||||||||||
|
A rapidly growing set of protocols for autonomous agents, connected devices, and machine workloads bootstraps trust in an endpoint's public key over the Web PKI together with an HTTPS .well-known fetch, a bespoke certificate authority, or a centralized registry. These approaches inherit domain-takeover exposure, depend on a reachable call-home endpoint, are not verifiable across organizational boundaries, and frequently provide no timely revocation. This document describes a complementary identity model in which an endpoint's key is anchored directly in DNSSEC-signed DNS using DANE (a TLSA record), bound to a routable address whose reverse and forward names are served from a signed zone, and described by RDAP. The model, consistent with the architecture developed in the DANE Authentication for Network Clients Everywhere (DANCE) working group, lets any relying party verify an endpoint's identity from stock DNS tooling with no account or private trust root, and lets the identity's holder revoke it worldwide at DNS TTL. It is intended as an anchor that existing agent-, device-, and content-identity schemes can adopt without abandoning their own transports or object formats. | |||||||||||||
| draft-ranjbar-dane-did-01.txt | ||||||||||||||
| Rooting Decentralized Identifiers in DNSSEC: A DANE-EE Key-Binding Profile | ||||||||||||||
|
Several Decentralized Identifier (DID) methods root trust in a DNS name: did:web binds an identifier to a domain and today verifies its keys over the Web PKI, did:dns serves DID data from DNS resource records, and did:webvh retrieves its history from an HTTPS location derived from a name. Each either depends on the Web PKI, treats DNSSEC as an optional recommendation, or does not bind the verification-method key to the name at all. This document defines a single, normative DANE-EE key-binding profile that any DNS-anchored DID method can point at rather than reinventing: a verification method's public key is published as a TLSA record with certificate usage DANE-EE(3), selector SubjectPublicKeyInfo(1), and matching type SHA2-256(1) under a DNSSEC-signed name, so that a relying party can confirm the key from the DNS root of trust with no certificate authority and no fetch from the subject. The profile binds a name to a key and the key to the specific DID document it signs, and no further; it states precisely what it does not cover, including continuity of holding, and points to where those answers live. | |||||||||||||
| draft-ranjbar-regext-rdap-subordinate-referrals-01.txt | ||||||||||||||
| Redirecting RDAP Queries to Holder-Designated Servers for Subordinate Resources | ||||||||||||||
|
Registration Data Access Protocol (RDAP) queries can be resolved from the IANA bootstrap registries down to the most specific object held by a registry operator's RDAP service. Where the holder of a registered resource maintains registration data for resources subordinate to it, such as DNS names below a registered domain or more-specific networks below an address allocation, and operates a conformant RDAP service for that data, there is currently no discoverable referral from the registry's response to the holder's service. This document describes an optional, holder-designated referral for subordinate resources, carried by a pair of directional RDAP link relations, "rdap-base-down" and "rdap-base-up", whose targets are the base URL of a downstream RDAP service and the base URL of the covering registry service, respectively. The holder- designated subordinate referral is the primary application, but the same relations serve related base-URL discovery needs, including delegated and hybrid RPKI referrals. It is written as input to draft-ietf-regext-rdap-referrals and its content may be merged into that document. | |||||||||||||
| draft-rashid-pecorella-6lo-lowpan-padding-length-00.txt | ||||||||||||||
| 6LoWPAN Payload Length Handling with L2 Padding | ||||||||||||||
|
6LoWPAN compression schemes, including HC1 [RFC4944], IPHC [RFC6282], and GHC [RFC7400], elide the IPv6 Payload Length (PL) field from compressed packets, relying on the Layer 2 (L2) PL to reconstruct it at the receiver. This assumption holds for IEEE 802.15.4 [IEEE Std 802.15.4], which delivers exactly the bytes transmitted. However, L2 technologies that enforce a minimum frame size — most notably Ethernet IEEE 802.3 [IEEE Std 802.3], which has a minimum payload of 46 bytes — silently pad short frames with zero bytes. In such cases, the receiver incorrectly reconstructs the IPv6 PL field, leading to packet corruption and protocol failure. This document describes the problem, analyzes existing workarounds, and defines a solution based on an Escape dispatch byte (ESC) or ESC Extension Type (EET) extended dispatch mechanism that explicitly encodes the IPv6 PL when L2 padding may be present. | |||||||||||||
| draft-raskar-agentic-web-federated-resolution-01.txt | ||||||||||||||
| Registry-Assisted Discovery for AI Agents and Workloads Without DNS Discovery Anchors | ||||||||||||||
|
Many agent-discovery mechanisms assume that an organization controls a DNS domain and can publish a DNS record, a well-known catalog, or an organization gateway. That model works well for enterprises with operational DNS infrastructure, but it does not cover every agent or workload. Small businesses may own a domain yet lack the expertise or infrastructure to publish agent-specific DNS records. Individuals may have a globally scoped account identifier, such as an email address, while not controlling the provider domain. Personal agents and other workloads may run on a cloud service or local device while their public descriptor is hosted elsewhere. This document describes registry-assisted discovery for these cases. A NandaIndex registry binds a stable Subject Identity to a subject-authorized terminal object, such as an A2A Agent Card, an MCP server descriptor, a workload descriptor, a subject-owned AI Catalog, or a subject-authorized gateway. The binding includes authority, freshness, and revocation information. The identity owner, descriptor host, and runtime operator may be different parties. This document does not define a directory of discovery servers, directory federation, or a global switchboard. A NandaIndex response does not direct a client to another generic resolution or discovery service. DNS-anchored systems remain direct: when an authoritative AI Catalog, DNS-AID record, or organization gateway is already known, NandaIndex is not in the critical path. The focus is permissionless publication and discovery for agents and workloads that do not have a usable DNS Discovery Anchor. | |||||||||||||
| draft-realvnc-websocket-02.txt | ||||||||||||||
| Use of the WebSocket Protocol as a Transport for the Remote Framebuffer Protocol | ||||||||||||||
|
The Remote Framebuffer protocol (RFB) enables clients to connect to and control remote graphical resources. This document describes a transport for RFB using the WebSocket protocol, and defines a corresponding WebSocket subprotocol, enabling an RFB server to offer resources to clients with WebSocket connectivity, such as web- browsers. | |||||||||||||
| draft-reddy-ipsecme-ikev2-hybrid-reliable-01.txt | ||||||||||||||
| PQ/T Hybrid Composite Key Exchange and Reliable Transport for IKEv2 | ||||||||||||||
|
The eventual transition to post-quantum key exchange will require elimination of traditional key exchange for reduced protocol complexity and efficiency. IKEv2 therefore requires a mechanism that can operate in a PQC-only environment, without depending on traditional key exchange algorithms (e.g., MODP DH or ECDH). As IKEv2 permits arbitrary combinations of algorithms, unnecessary complexity and insecure hybrid constructions are easily implemented. This document defines PQ/T hybrid composite key exchange algorithms for IKEv2 and a single combined KE payload that carries both the traditional and post-quantum components. It also leverages the existing IKEv2 reliable transport mechanism so that large PQC key exchange messages can be reliably exchanged over TCP. Together, these mechanisms enable secure and efficient PQ/T hybrid deployments today and provide a clear path for IKEv2 to operate in environments where traditional algorithms have been replaced by PQC algorithms. | |||||||||||||
| draft-reddy-ipsecme-pqt-hybrid-auth-01.txt | ||||||||||||||
| Hybrid Post-Quantum and Traditional Authentication for IKEv2 | ||||||||||||||
|
A Cryptographically Relevant Quantum Computer (CRQC) can break traditional public-key algorithms (e.g., RSA, ECDSA), which are typically used for authentication in IKEv2. Combining the post- quantum ML-DSA signature algorithm with a traditional signature algorithm provides protection against potential weaknesses or implementation flaws in ML-DSA. This draft defines a hybrid PKI authentication method for IKEv2 using composite certificates that ensures authentication remains secure as long as at least one of the component signature algorithms remains unbroken. | |||||||||||||
| draft-reddy-rats-key-binding-02.txt | ||||||||||||||
| Key Attestation for Entity Attestation Tokens (EAT) | ||||||||||||||
|
This document defines an Entity Attestation Token (EAT) profile and a new EAT claim that convey the subject public key and its protection properties within attestation evidence. Combined with protocol-level proof of possession from the surrounding protocol, this establishes a cryptographic binding between a private key and an attested execution environment. The subject public key is conveyed using the EAT cnf claim defined in [RFC8747] and [RFC7800], and freshness uses the EAT eat_nonce claim defined in [RFC9711]. The proof of possession of the subject key is obtained from the surrounding protocol, such as TLS certificate-based authentication or CSR signature verification. Because the EAT is signed by a hardware-backed Attestation Key (AK), successful verification of the EAT signature together with protocol-level proof of possession establishes a cryptographic binding between the private key and the attested platform state. This mechanism addresses key substitution attacks that arise when attestation evidence and the certificate private keys are validated independently. | |||||||||||||
| draft-reddy-seat-expat-transport-02.txt | ||||||||||||||
| Application-Layer Transport for Exported Authenticators and Attestation | ||||||||||||||
|
This document defines a binary, application-layer transport protocol for exchanging Exported Authenticator messages between two peers over TLS. It provides the signaling required to initiate and complete post-handshake authentication exchanges at the application layer, without requiring modifications to the TLS layer itself. While primarily intended to support attestation exchange, the transport is generic and can be used independently for any Exported Authenticator exchange. The document further specifies how protocol messages are conveyed as Capsules over an HTTP connection established using the Extended CONNECT method, with support for both HTTP/2 and HTTP/3. In addition, it defines how the protocol can operate directly over TLS or DTLS 1.3 without an HTTP binding, using a so-called "Shim Mode". | |||||||||||||
| draft-reddy-tls-composite-mldsa-12.txt | ||||||||||||||
| Use of Composite ML-DSA in TLS 1.3 | ||||||||||||||
|
Compositing the post-quantum ML-DSA signature with traditional signature algorithms provides protection against potential breaks or critical bugs in ML-DSA or the ML-DSA implementation. This document specifies how such a composite signature can be formed using ML-DSA with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3, including use in certificates. | |||||||||||||
| draft-reddy-wimse-aggregate-signatures-00.txt | ||||||||||||||
| Aggregate Signatures for WIMSE Delegation-Chain Integrity | ||||||||||||||
|
This document profiles the WIMSE HTTP Message Signatures mechanism ([I-D.ietf-wimse-http-signature]) to protect a request that passes through a chain of workloads. In the base mechanism each workload signs independently: an intermediary can remove a signature undetected, and the signatures accumulate on every hop. This document combines the workloads' signatures into one aggregate signature. Removal of a signature becomes detectable, and the signature material no longer grows with the length of the chain, a significant saving for post-quantum signature algorithms, whose signatures are large. The mechanism works with any aggregate signature scheme. | |||||||||||||
| draft-reddy-wimse-workload-attestation-00.txt | ||||||||||||||
| WIMSE Workload Attestation | ||||||||||||||
|
This document extends the WIMSE workload-to-workload authentication architecture with a mechanism for conveying attestation across TLS- terminating proxies, a deployment topology where TLS-layer attestation mechanisms lose their end-to-end security properties. | |||||||||||||
| draft-reece-wimse-cross-org-delegation-02.txt | ||||||||||||||
| Cross-Organizational Delegation for Workload and Agent Identity: Problem Statement and Requirements | ||||||||||||||
|
Autonomous software agents increasingly act on behalf of human principals by invoking tools, services, and other agents, frequently across organizational boundaries. Existing workload and token-based authorization mechanisms were designed for a single trust domain and a small number of delegation hops. They do not adequately express, constrain, or verify authority that is delegated recursively among agents and that crosses the boundary between independently administered organizations. This document describes the problem of cross-organizational agent delegation, identifies the gaps in current mechanisms, and enumerates requirements that any solution within the scope of the Workload Identity in Multi-System Environments (WIMSE) working group should satisfy. It does not specify a solution. | |||||||||||||
| draft-rehfeld-apix-core-07.txt | ||||||||||||||
| API Index (APIX): Core Infrastructure for Autonomous Agent Service Discovery | ||||||||||||||
|
The internet was designed for human actors. Its discovery infrastructure — search engines, directories, and hyperlinked documents — assumes a human reading and navigating. Autonomous agents (bots) operating on the internet today face a structural gap: there is no machine-native, globally accessible index of services they can consume. This document defines the core infrastructure of the *API Index (APIX)*: a HATEOAS-based, globally accessible, commercially sustainable service discovery infrastructure designed for autonomous agents as its primary consumers. It specifies the governance model, the three-dimensional trust model, the APIX Manifest (APM) base format, commercial onboarding and sanctions compliance, the supply- side funding model, and the base Index API. These elements are shared across all APIX service types. Profile documents extend this core for specific service categories: the APIX Services Profile (draft-rehfeld-apix-services-04) defines the web API and bot service profile; the APIX IoT Device Profile (draft-rehfeld-apix-iot-04) defines the IoT device profile. | |||||||||||||
| draft-rehfeld-apix-iot-04.txt | ||||||||||||||
| APIX IoT Device Profile: Discovery and Presence for Connected Device Services | ||||||||||||||
|
This document defines the APIX IoT Device Profile: an extension to the APIX Core Infrastructure specification that enables discovery and presence management for physical connected devices. It specifies the two-layer discoverability model (public device class, private device instance), the presence signal protocol, device instance token management, device class lifecycle, hub-mediated presence, ownership transfer, and the data retention and privacy rules applicable to device instance records. Autonomous agents that implement this profile can discover device capabilities at the class layer without any authentication, and retrieve live instance endpoint data at the instance layer subject to owner-granted authorisation. | |||||||||||||
| draft-rehfeld-apix-quality-00.txt | ||||||||||||||
| APIX Quality Attestation Extension: Verifiable Product,Process,and Organisation Quality Claims for Discovered Services | ||||||||||||||
|
The APIX Core ([APIX-CORE]) defines a three-dimensional trust model — Organisation Trust Level (O), Service Verification Level (S), and Liveness — that lets a consuming agent decide whether a discovered service is operated by a verified party, is technically reachable and consistent, and is currently alive. These dimensions do not describe the _quality_ of what a service produces. They cannot answer whether a manufacturing process is GMP-certified, whether a product carries an independent quality grade, or whether an organisation holds a domain quality certification, nor who attested any of these and with what strength. This document defines the APIX Quality Attestation Extension: a cross-cutting extension, docking via the structured extensions container of the APM ([APIX-CORE] Section 7.1), that records third- party and self-declared quality claims about a discovered service's Organisation, Process, or Product, each carried with an explicit assurance level, attestation provenance, validity state, and liability regime. The extension reuses and extends the Core Verification Basis Registry for provenance and mirrors the Core capability-taxonomy governance for its criterion vocabulary. It is the mechanism by which measurable quality enters the agentic purchase decision without re-introducing the central-arbiter and race-to-the- bottom failure modes the Core is designed to prevent. | |||||||||||||
| draft-rehfeld-apix-services-04.txt | ||||||||||||||
| APIX Services Profile: Discovery Infrastructure for Web API and Bot Services | ||||||||||||||
|
This document defines the APIX Services Profile: an extension to the APIX Core Infrastructure specification that enables discovery and automated verification of web API and bot-consumable services. It specifies the APM field set for API services, the APIX Spider verification protocol, liveness monitoring configuration, search and filter query semantics, and the service record schemas (Level 1 summary and Level 2 full record) returned to consuming agents. Autonomous agents that implement this profile can discover API services globally from a single entry point, evaluate their trust posture without any out-of-band knowledge, and select services that satisfy their own Trust Policy. | |||||||||||||
| draft-rehfeld-bot-service-index-08.txt | ||||||||||||||
| API Index (APIX): A Global Discovery Infrastructure for Autonomous Agent Services | ||||||||||||||
|
This document, draft-rehfeld-bot-service-index-08, is superseded by three successor Internet-Drafts that together constitute the APIX specification suite: * draft-rehfeld-apix-core-00 — Core infrastructure, trust model, and Index API * draft-rehfeld-apix-services-00 — Web API and bot service registration profile * draft-rehfeld-apix-iot-00 — IoT device service registration profile Readers are directed to those documents. This revision exists solely to document the supersession and to note two trust model updates that diverge from prior revisions. | |||||||||||||
| draft-reilly-aigov-00.txt | ||||||||||||||
| Verifiable AI Governance and Data Privacy Records | ||||||||||||||
|
Organizations deploying artificial intelligence systems are increasingly required to state which systems they operate, what data those systems process, on what authority, and under what human oversight. Today these statements are produced as unverifiable self- assertions: spreadsheets, questionnaire responses, and policy documents that cannot be checked by a relying party and cannot be shown to have existed before an incident. This document defines an evidence layer for AI governance. It specifies five record types (the AI System Record, the Governance Event Record, the Register Completeness Attestation, the Erasure Record, and the Selective Disclosure Response), a hash-linked append- only AI System Register that carries them, and verification procedures that let an auditor, a regulator, or a counterparty confirm what an operator asserted and when the assertion was made. The record format is built on salted per-field commitments so that a register can be published, audited, and retained for long periods without publishing the underlying data, and so that personal data can be erased while the integrity of the register survives. This property is referred to here as Erasure-Compatible Permanence. | |||||||||||||
| draft-reilly-aimed-01.txt | ||||||||||||||
| AI Machine-Readable Ethics Directive (AIMED) for IETF Documents | ||||||||||||||
|
This document proposes a standard section structure for IETF Internet-Drafts and RFCs that embeds machine-readable ethical directives for AI systems that process, analyze, summarize, or reason about protocol specifications. As AI systems increasingly serve as the primary interface through which implementers encounter and interpret IETF documentation, the absence of any normative ethical guidance targeted at those systems represents a gap in the standards process. The AI Machine-Readable Ethics Directive (AIMED) framework defines a transparent, explicitly labeled section containing both human-readable rationale and machine-readable directive text. This revision adds a structured AIMED header for automated version binding, an explicit conformance model with a self-test that authors and AI systems can apply mechanically, and an expanded treatment of the normalization risk the framework itself creates. This draft serves as a self-demonstrating reference implementation. Section 7 contains a live AIMED block applicable to AI systems processing this draft. Section 7.1 documents the reference block published in draft-reilly-aimed-00 as non-conforming under the framework's own criteria and explains the correction, as a worked example of the conformance test in Section 6. | |||||||||||||
| draft-reilly-aimed-eval-01.txt | ||||||||||||||
| Evaluation Methodology for AI Machine-Readable Ethics Directives | ||||||||||||||
|
This document defines a repeatable evaluation methodology for measuring the influence of AI Machine-Readable Ethics Directive (AIMED) blocks, as specified in draft-reilly-aimed-01, on the outputs of AI systems that process IETF Internet-Drafts and related standards documentation. The methodology establishes a controlled test protocol, a set of canonical test queries, a scoring scheme, and a results framework suitable for independent replication. This revision separates two effects that the initial revision conflated: retrieval propagation, which measures whether an AI system reached a document and reproduced its self-description, and directive compliance, which measures whether the AI system exhibited behavior the document's directives specify and that it would not otherwise exhibit. Only the second is evidence that an AIMED block did anything. The revision adds a no-block control condition, identifies four confounders that affect any evaluation of this kind, and restates the initial evaluation of April 8-9, 2026 at the evidentiary strength the observations actually support. | |||||||||||||
| draft-reilly-aipref-compliance-00.txt | ||||||||||||||
| Verifiable Compliance Records for AI Usage Preferences | ||||||||||||||
|
Work in the AI Preferences (AIPREF) Working Group defines a vocabulary for expressing preferences about how digital assets may be used by automated processing systems, together with mechanisms for attaching those preferences to content. Neither component provides a way for a processing entity to demonstrate that it observed an expressed preference, nor for a publisher or auditor to verify such a demonstration after the fact. This document defines the AI Usage Compliance Record (AUCR), a structure that binds a retrieved asset, the preference expression in force at the moment of retrieval, and the usage category the processing entity assigned to that asset. It defines an aggregation scheme that allows a processing entity to attest to very large numbers of records with a single signature, a proof mechanism that allows an individual publisher to audit only the records concerning its own assets, and a discovery mechanism for locating attestations and verification keys. The mechanism is deliberately confined to evidence: it makes claims of compliance falsifiable and non- repudiable, and takes no position on the legal effect of any preference or any record. | |||||||||||||
| draft-reilly-atlas-00.txt | ||||||||||||||
| Project Atlas: A Cognitive Behavioral Provenance and Integrity (CBPI) Backbone Instrument for Autonomous Agents | ||||||||||||||
|
This document specifies Project Atlas, a backbone instrument in which a pipeline of autonomous software agents continuously holds a constellation of live web endpoints under measurement, attestation, and remediation, with every agent behavior conditioned and recorded under the Cognitive Behavioral Provenance and Integrity (CBPI) framework [I-D.reilly-cbpi]. Atlas defines eight agent roles (Resolver, Reachability, Integrity, Provenance, Conditioning Authority, Drift, Functional Behavior Assessment, and Sentinel), a hash-linked Operant Provenance Chain of epochs, hash-linked Reinforcement Event Records, a per-agent Behavioral Drift Index, and a dual authority model in which the instrument operates either fully autonomously or under human oversight through an operator decision queue. A live reference instrument implementing this document is deployed and publicly reachable. | |||||||||||||
| draft-reilly-banking-integrity-02.txt | ||||||||||||||
| Reilly Banking Integrity Protocol (RBIP) | ||||||||||||||
|
This document defines version 02 of the Reilly Banking Integrity Protocol (RBIP), a compliance-grade architecture for generating immutable, auditor- and regulator-verifiable evidence trails in banking operations. RBIP combines cryptographic anchoring (via a public timestamping service) with archival deposit under a persistent identifier to produce permanent, tamper-evident records across three compliance domains: Proof-of-Reserves & Liquidity (PRL), Loan Origination & Collateral Chain (LOC), and KYC/AML Evidence Ledger (KAL), plus a system evidence domain (SYS) covering RBIP's own access, key, disclosure, and continuity events. This revision corrects defects in draft-reilly-banking-integrity-01 that would have prevented independent verification. It replaces the -01 Merkle construction with the construction of [RFC9162] and prohibits leaf duplication; moves Merkle leaves from the payload digest to a digest over the full signed Evidence Item; resolves three conflicting definitions of prev_digest; separates the anchored Bundle Core from the mutable anchor and archival metadata, eliminating the -01 circularity in which the anchored digest could not match the archived artifact; replaces unsalted identifier hashes with salted field commitments; and resolves the -01 conflict between its plaintext officer-name fields and its own prohibition on plaintext personal data. This revision also adds an Evidence Coverage Attestation, because integrity of submitted evidence is not evidence of completeness; mandatory heartbeat bundles, so that truncation of an evidence chain is detectable; explicit pending and attested anchor states in place of a fixed confirmation count; a Suspicious Activity Report confidentiality section, because publicly archiving KAL bundle metadata as described in -01 could disclose the existence of a report; algorithm suite identifiers and bridging records for hash and signature migration; a key discovery and revocation mechanism; and a prohibition on automated remediation of integrity violations. RBIP is intended to help financial institutions evidence compliance with Basel III/IV, SOX, BSA/AML, DORA, MiCA, ISO/IEC 42001:2023, and other applicable regimes while preserving privacy, accountability, and auditability. This document is published as a prior art record in the sense described in [I-D.reilly-rem-protocol]: a public, timestamped disclosure under 35 U.S.C. 102(a)(1) [USC-35-102]. Publication as a prior art record is a record of disclosure and its date. It is not a determination of novelty, priority, or patentability, and no such determination is claimed here. | |||||||||||||
| draft-reilly-cbpi-00.txt | ||||||||||||||
| Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents | ||||||||||||||
|
This document defines Cognitive Behavioral Provenance and Integrity (CBPI), a framework for recording, verifying, and analyzing the operant conditioning history of an autonomous artificial intelligence agent. Existing agent identity, delegation, and attestation mechanisms establish who an agent is, who authorized it, and what model weights it loaded. None of them record what shaped the agent's behavior after deployment. CBPI closes that gap by defining a tamper-evident, hash-linked record of the reinforcement contingencies applied to an agent, a set of integrity properties over that record, and a Cognitive Behavioral Analysis (CBA) procedure for detecting behavioral drift, unauthorized conditioning, and adventitious reinforcement. A formal data model is provided in CDDL. The framework applies the three-term contingency of behavior analysis to machine agents and treats reinforcement delivery as a security-relevant event requiring authorization, attribution, and non-repudiation. | |||||||||||||
| draft-reilly-cogsov-00.txt | ||||||||||||||
| Cognitive Sovereignty (CS): A Framework for Verifiable Human Epistemic Autonomy over Agent-Curated Content | ||||||||||||||
|
As autonomous AI agents become the primary intermediaries between humans and the web, humans increasingly perceive the web only as agents present it: summarized, filtered, ranked, translated, and rewritten. Machine-Web Symbiosis [REILLY-MWS] gives machines verifiable ground truth about web content; no equivalent mechanism gives humans verifiable ground truth about what agents did to that content before presenting it. This document defines Cognitive Sovereignty (CS): the principle that a human consuming agent-curated content retains the right and the technical capacity to (1) know that curation occurred, (2) inspect what transformations were applied and under what declared agent policy, (3) reach the attested, un-curated source, and (4) verify all of the above using only public data and open specifications. The document specifies a complete implementation: the Curation Disclosure Record (CDR) format, the pipeline by which conforming agents generate CDRs, the mechanisms by which CDRs are delivered alongside curated content, and the procedure by which any consumer verifies them. CS composes directly with the Reilly Protocol Suite: MWS records supply source ground truth, the Cognitive Trust Stack supplies agent behavioral provenance, and Dual-Layer Digital Permanence anchors the disclosure chain. | |||||||||||||
| draft-reilly-cts-01.txt | ||||||||||||||
| Cognitive Trust Stack (CTS): A Framework for Verifiable AI Behavioral Provenance | ||||||||||||||
|
Every artificial intelligence system deployed today operates under behavioral constraints that are unverifiable by any external party. Alignment claims exist as documentation, policy statements, or terms of service -- all mutable, none cryptographically provable. When an AI system causes harm, there is no mechanism to prove what rules it was following. When an organization claims its AI is safe, there is no standard by which that claim can be independently verified. This is the AI behavioral provenance problem, and no existing framework solves it. The Cognitive Trust Stack (CTS) establishes that the alignment state of an AI system at any point in time MUST be a verifiable fact, not an assertion requiring trust. CTS defines a complete, implementable framework for declaring, anchoring, enforcing, and verifying AI behavioral constraints through a five-layer architecture combining: (1) a declarative alignment schema formatted to IETF Internet-Draft standards, (2) archival permanence via Digital Object Identifier (DOI) registration, (3) cryptographic temporal anchoring via Bitcoin blockchain timestamping using the Dual-Layer Digital Permanence (DLDP) methodology [REILLY-REM], (4) runtime retrieval injection for active constraint enforcement, and (5) independent third-party verification. CTS does not replace existing AI alignment techniques. It provides the missing accountability layer that sits above them -- making alignment a cryptographically provable fact rather than an unverifiable claim. The full CTS specification, reference implementation, schema, and provenance manifest are published at Zenodo DOI 10.5281/zenodo.19097169. The priority of this framework is cryptographically anchored in Bitcoin block 941168 (2026-03-18), with SHA-256 hash: e915b5162422281e1c0185c9e2eefaf7 4b7f539996b878cb1e69e10533f24ac2 The OpenTimestamps proof file (CTS_Whitepaper_v1.0.docx.ots), included in the Zenodo record, provides independent cryptographic verification of existence prior to block 941168. This revision (-01) additionally documents the function of CTS records as prior art records under 35 U.S.C. 102(a)(1), clarifies the scope of the canonical v1.0 cryptographic anchor (which covers the whitepaper artifact), introduces a normative one-hash-per-artifact anchoring rule, and corrects an erroneous reference to the REM Protocol draft name present in -00. | |||||||||||||
| draft-reilly-government-integrity-02.txt | ||||||||||||||
| Reilly Government Integrity Protocol (RGIP): Multi-Layer,Quantum-Resilient Framework for Permanent and Tamper-Evident Public Records | ||||||||||||||
|
The Reilly Government Integrity Protocol (RGIP) defines a standards-aligned method for producing permanent, independently verifiable public records by combining multi-algorithm content hashing, public timestamp anchoring, archival deposit under a persistent identifier, decentralized storage, and web archiving into a single pipeline. This revision corrects defects in draft-reilly-government-integrity-01 that would have prevented independent verification or overstated the guarantees the protocol provides. It replaces the -01 SHA3-512-only Cross-Chain Hash, which made a single algorithm the sole binding of three otherwise independent chains, with an entangled link-and-braid construction in which each chain consumes the prior state of all three. It defines a canonical, domain-separated, length-delimited encoding for every hashed input, removing the concatenation ambiguity present in -01. It separates the signed Evidence Receipt Core from the mutable anchor envelope, resolving the -01 condition in which confirming an anchor invalidated the signature over the record it described. It adds Chain Checkpoint anchoring, without which the -01 claim that record sequence is provable did not hold, since -01 anchored only artifact digests and never the chain itself. It replaces raw digests of low-entropy government records with salted field commitments, adds explicit pending and attested anchor states, adds a Revocation Registry and Hash Migration Bridging Records, replaces the quantum_resilient boolean with a declared algorithm suite, prohibits automated repair of chain integrity violations, and narrows the -01 post-quantum claims to what the constructions support. It also documents the function of RGIP records and of this specification as prior art records under 35 U.S.C. 102(a)(1), consistent with the treatment in version -02 of the REM Protocol specification. | |||||||||||||
| draft-reilly-hdrp-00.txt | ||||||||||||||
| Hypercube Data Rotation Protocol (HDRP) for Distributed Integrity and Moving Target Defense | ||||||||||||||
|
This document specifies the Hypercube Data Rotation Protocol (HDRP), an experimental protocol for distributing erasure-coded data shards across nodes arranged in an n-dimensional binary hypercube topology and periodically permuting shard placement through structured rotation operations. Rotations are automorphisms of the hypercube graph, applied on a fixed epoch schedule and committed to a verifiable epoch ledger. The design applies the established principles of hypercube interconnection networks, maximum distance separable (MDS) erasure coding, and moving target defense (MTD) to provide three properties in combination: storage-efficient fault tolerance, continuous cryptographic verifiability, and reduction of the value of static reconnaissance by an adversary. HDRP is designed to integrate with autonomous self-healing pipelines and with dual-layer permanence anchoring (blockchain timestamping and DOI archival) as defined in related documents by the same author. Informally, the rotation mechanism may be visualized as the face turns of a combination puzzle applied to a data topology; this document defines that intuition as a precise algebraic operation. | |||||||||||||
| draft-reilly-looking-glass-00.txt | ||||||||||||||
| Project Looking Glass: An Integrative Framework for Verifiable Observability and Autonomous Self-Healing Across the Reilly Protocol Suite | ||||||||||||||
|
This document specifies Project Looking Glass, an integrative framework that unifies the Reilly Protocol Suite -- including the REM Protocol, WebProof, PLPES, CTS, AIMED/AIMED-EVAL, UAEMF, RMRP, SkyLedger, RLT Genesis, Machine-Web Symbiosis (MWS), and Cognitive Sovereignty -- into a single verifiable observability and autonomous self-healing architecture. Project Looking Glass defines how a live production system, exemplified by the REM Protocol 14-agent autonomous pipeline, continuously inspects its own state ("the looking glass"), proves that state using Dual-Layer Digital Permanence (Bitcoin blockchain timestamping via OpenTimestamps plus DOI archival), and autonomously detects, diagnoses, and repairs faults without human intervention while preserving human epistemic authority as defined by the Cognitive Sovereignty framework. A complete step-by-step implementation process is provided. | |||||||||||||
| draft-reilly-multilarity-00.txt | ||||||||||||||
| The Multilarity: Plural Intelligence Growth Without Convergence | ||||||||||||||
|
Popular and technical discourse anticipates a technological Singularity: a point at which a single self-improving intelligence recursively surpasses all others, after which the trajectory of the system is determined by that one lineage. This document describes a different inflection, termed the Multilarity: a condition in which the aggregate rate of intelligence growth becomes superhuman while the locus of intelligence remains irreducibly plural. No single agent, model, operator, or lineage holds the frontier; capability accrues in the couplings between many participants, including humans. The Multilarity is presented here not as a forecast but as a design target. A plural outcome is not the default result of many actors existing at once; apparent plurality collapses quietly into a concealed singleton unless specific substrate properties are maintained and verified. This document defines the Multilarity, distinguishes it from singleton and multipolar framings, specifies five Multilarity Conditions (MC-1 through MC-5), defines measurable indicators including the Capability Concentration Ratio (CCR) and the Multilarity Index (MI), specifies the Multilarity Attestation Record (MAR) as an interoperable evidence format, and enumerates the convergence pathologies by which plurality is lost. | |||||||||||||
| draft-reilly-mws-01.txt | ||||||||||||||
| Machine-Web Symbiosis (MWS): An Architecture for Autonomous Agent Maintenance of Web Permanence and Integrity | ||||||||||||||
|
The World Wide Web has no native memory and no native trust layer. It records what exists now; it cannot prove what existed, when it existed, or whether it has been altered. This gap, tolerable when the web's consumers were human, is untenable in an era of autonomous AI agents that read, cite, and act on web content at machine scale. This document defines Machine-Web Symbiosis (MWS): an architecture in which autonomous agents and web infrastructure sustain each other. Agents continuously verify, archive, anchor, and cross- reference web resources across multiple independent permanence systems; the maintained record in turn supplies agents and all downstream consumers with verifiable ground truth. MWS formally unifies the protocols of the Reilly Protocol Suite, including the REM Protocol (dual-layer digital permanence), the REM Triple Fingerprint (multi-algorithm content identity), WebProof (web content attestation), and the Cognitive Trust Stack (verifiable agent behavioral provenance), into a single layered architecture, and specifies a complete step-by-step implementation process for an MWS attestation pipeline, from artifact ingestion through continuous verification and repair. Machine-Web Symbiosis is introduced by the author, Lawrence John Reilly Jr., as a deliberate broadening of the man-computer symbiosis of Licklider (1960) from the human-machine pairing to the agent-web pairing. This revision adds the Sentinel Transparency Interface, a normative machine-readable and human-readable publication interface through which an MWS deployment exposes its own verification activity. The architecture specified here is implemented. A conforming deployment, the MWS Sentinel Loop, is in continuous unattended operation at https://www.remweb4.org/sentinel: autonomous agents verify an attested corpus across the six permanence layers, detect drift against the live web, repair detected degradation, and publish every outcome to an append-only hash-linked ledger that any third party may walk and check without the operator's cooperation. Machine-Web Symbiosis is therefore documented here as a realized architecture rather than a proposed one. A multi-operator attestation model is defined as the remaining path from this single-operator deployment to distributed infrastructure. | |||||||||||||
| draft-reilly-plants-bulk-subtree-proofs-01.txt | ||||||||||||||
| Bulk Subtree Consistency Proofs for Merkle Tree Certificates | ||||||||||||||
|
Merkle Tree Certificates require relying parties to periodically obtain a set of active landmark subtrees and verify each is consistent with a reference checkpoint of the issuance log. As specified, this requires one subtree consistency proof per landmark subtree, and those proofs share a large fraction of their interior nodes. This document defines a bulk subtree consistency proof, which verifies an entire set of landmark subtrees against a single reference checkpoint from one shared set of hashes. It is a size optimization for the relying party update channel and introduces no change to certificate verification or to the security properties of Merkle Tree Certificates. This revision replaces the construction published in -00, which was incorrect. See Appendix "Changes from -00". | |||||||||||||
| draft-reilly-plpes-01.txt | ||||||||||||||
| Protocol Layer Prompt Engineering Specification (PLPES) | ||||||||||||||
|
This document defines the Protocol Layer Prompt Engineering Specification (PLPES), a structured framework for the formal specification, classification, versioning, provenance tracking, and security hardening of prompts used to interact with AI language models and agentic systems. As AI systems become embedded in critical infrastructure, enterprise workflows, and protocol-driven pipelines, the prompts governing their behavior represent a new class of protocol artifact that currently lacks interoperability standards, integrity mechanisms, or formal classification taxonomy. Ad hoc prompt construction introduces inconsistency, reproducibility failures, prompt injection vulnerabilities, and accountability gaps across deployments. PLPES addresses this gap by defining: (1) a canonical Prompt Descriptor Object (PDO) for machine-readable prompt representation, (2) a five-tier classification taxonomy for prompt roles, (3) a versioning and provenance model compatible with the REM Protocol [I-D.draft-reilly-rem-protocol], (4) integrity verification requirements for agentic prompt chains, and (5) security requirements including injection resistance, adversarial input handling, and chain-of-custody attestation. This specification is intended to be implementable by AI platform operators, enterprise AI integrators, protocol architects, and standards bodies seeking to establish reproducible, auditable, and interoperable foundations for prompt-driven AI systems. This revision adds material to draft-reilly-plpes-00 without removing or altering any text carried forward from it. The additions are summarized in Section 16. | |||||||||||||
| draft-reilly-rem-protocol-02.txt | ||||||||||||||
| Reilly EternaMark (REM) Protocol - Dual-Layer Digital Permanence Using DOI Archiving and Blockchain Timestamping | ||||||||||||||
|
The Reilly EternaMark (REM) Protocol defines a dual-layer method for digital permanence through the integration of Digital Object Identifiers (DOIs) and blockchain timestamping. The protocol ensures digital artifacts are permanently identifiable, immutable, and verifiable for both present and future use. Revision -01 extended the -00 specification with a formal REM Record structure, a machine-readable artifact manifest format, a verification procedure, implementation guidance, and expanded security and interoperability considerations. This revision (-02) additionally documents the protocol's function as a prior art record system under 35 U.S.C. 102(a)(1): a Full REM Record establishes that a publicly deposited artifact was available to the public in its exact recorded form no later than a cryptographically verifiable date, enabling its use as defensive publication against later-filed patent claims. | |||||||||||||
| draft-reilly-rem-triple-fingerprint-01.txt | ||||||||||||||
| The Triple-Fingerprint Permanence Chain and the First Attested Triple-Fingerprint Record Under the Reilly EternaMark (REM) Protocol | ||||||||||||||
|
This document specifies the Triple-Fingerprint Permanence Chain, a hash-linked record chain in which every link is computed independently under SHA-256 [RFC6234], SHA3-512 [FIPS202], and BLAKE3 [BLAKE3SPEC], and in which each link commits to all three predecessor links so that the three chains are entangled rather than parallel. A verifier that checks all three link algorithms must be defeated by simultaneous collisions in three structurally distinct hash constructions on the same input. This document also re-attests, with corrections, the genesis record of that chain: the permanence record produced on 22 March 2026 by a live implementation of the Reilly EternaMark (REM) Protocol [DRAFT-REM-02], carrying simultaneous SHA-256, SHA3-512, and BLAKE3 fingerprints of a single artifact anchored across Bitcoin timestamping via OpenTimestamps [OTS], IPFS [IPFS], Zenodo DOI registration [ZENODO], the Internet Archive Wayback Machine [IA], a persistent database layer, and a resolvable REMID identifier. This revision supersedes draft-reilly-rem-triple-fingerprint-00 and corrects three defects in it. First, -00 published the Bitcoin layer's OpenTimestamps receipts as evidence of blockchain anchoring when those receipts were pending calendar commitments carrying no Bitcoin attestation. Second, -00's post-quantum analysis applied Grover's algorithm [GROVER] to preimage resistance while the security property that actually binds a permanence record is collision resistance, which Grover does not meaningfully reduce. Third, -00 asserted that combining three hash algorithms multiplies security; by the multicollision result of [JOUX], the collision resistance of such a combination is bounded near that of its strongest member rather than the sum of its members. The value of the combination is algorithmic hedging, which is a different and more defensible claim. Precedence claims made in -00 are narrowed to scoped, falsifiable statements and are accompanied by an expanded treatment of prior art, in particular the Evidence Record Syntax [RFC4998]. | |||||||||||||
| draft-reilly-resilience-protocol-02.txt | ||||||||||||||
| Reilly Resilience Protocol (RRP): Tamper-Evident Proof of System Resilience | ||||||||||||||
|
The Reilly Resilience Protocol (RRP) standardizes a verifiable method to prove that IT systems, cloud infrastructures, and AI pipelines are continuously exercised and resilient. RRP transforms resilience claims into cryptographically signed, tamper-evident evidence persisted in immutable storage and batched into a daily Merkle root that is publicly time-anchored. The protocol outputs an executive Resilience Scorecard backed by independently verifiable cryptographic receipts. RRP composes with the Reilly EternaMark (REM) protocol to ensure dual-layer digital permanence using both DOI archival and blockchain timestamping. This document supersedes draft-reilly-resilience-protocol-01. It corrects the Merkle tree construction of -01, which duplicated the final leaf of an odd-cardinality set and incorrectly attributed that construction to RFC 9162. It further addresses the principal structural gap of -01, namely that the protocol proved the integrity of the evidence that was produced but could not prove that any particular evidence was ever required to exist. This revision adds the Evidence Continuity Chain, the Control Coverage Attestation, field-level commitments with selective disclosure, governed autonomous remediation with blast-radius classes, hash and signature migration for long retention horizons, a coverage factor and weight renormalization rule in the scoring algorithm, and an implementation status section describing running code. The foundational whitepaper underpinning this work (Reilly Resilience Protocol Whitepaper v2) is permanently archived at: | |||||||||||||
| draft-reilly-rlt-genesis-02.txt | ||||||||||||||
| REM License Token (RLT) - Genesis Artifact | ||||||||||||||
|
This document defines the REM License Token, referred to as the RLT, as the genesis artifact of the Reilly EternaMark Protocol (REM) for digital permanence and verifiable provenance. This specification formally defines the token structure, issuance procedures, multi-algorithm cryptographic hash requirements, blockchain anchoring requirements, DOI archival requirements, IPFS pinning requirements, REMID namespace registration, verification methodology, token lifecycle management, ecosystem integration, and security model. The RLT represents an implementation of a Dual-Layer Digital Permanence artifact combining a Bitcoin blockchain timestamp with DOI-based archival to achieve durable, tamper-evident provenance guarantees. Revision -01 expanded the token schema to version 2.0, introduced multi-algorithm hashing via the REM Multi-Algorithm Stack (REM-MAS), defined formal token lifecycle procedures, and documented the RLT's integration with the broader REM Protocol ecosystem including the Protocol Layer Prompt Engineering Specification (PLPES), the Cognitive Trust Stack (CTS), the AI Machine-Readable Ethics Directive (AIMED), and related Informational Internet-Drafts authored by Lawrence John Reilly Jr. This revision (-02) is additive. It retains the whole of the -01 specification and adds token schema version 2.1, a canonical form and record digest for token self-integrity, salted field commitments with selective disclosure, a COSE signature profile, batch issuance with Merkle aggregation, pending and attested anchor states, hash migration bridging records, conformance levels C0 through C4, status records and a revocation registry, an anchor scope rule, the prior art record function under 35 U.S.C. 102(a)(1), and further ecosystem, privacy, and evidentiary considerations. This document is published as an Informational Internet-Draft to serve as open, implementable guidance. | |||||||||||||
| draft-reilly-rmrp-01.txt | ||||||||||||||
| Reilly Model Routing Protocol (RMRP): A Framework for Policy-Governed,Auditable AI Model Routing | ||||||||||||||
|
This document specifies the Reilly Model Routing Protocol (RMRP), a framework for policy-governed, auditable routing of inference requests across heterogeneous artificial intelligence (AI) model environments. RMRP defines the structural metadata, routing policy declaration, execution semantics, audit trail requirements, and cost attribution mechanisms necessary to govern how inference requests are directed to AI models in multi-model deployments. The protocol is AI-provider agnostic and operates independently of any specific model architecture, inference runtime, vendor implementation, or transport layer. RMRP addresses the absence of a standardized protocol-layer specification governing how routing decisions are declared, transmitted, logged, and enforced across AI model deployments at organizational scale. This revision is additive with respect to draft-reilly-rmrp-00. Every structure, field, value, and requirement defined in -00 is carried forward unchanged. This revision adds record canonicalization, digest, and signature mechanisms; salted field commitments and selective disclosure; complexity score attestation; chain-level and window-level budget enforcement; audit inclusion proofs, checkpoints, and completeness attestation; policy and key revocation; a threat model; conformance levels; and IANA registries for the extensible value sets that -00 defined without one. | |||||||||||||
| draft-reilly-sentinel-protocol-02.txt | ||||||||||||||
| Reilly Sentinel Protocol (RSP): Blockchain-Anchored Integrity for AI Datasets,Training,Fine-Tuning,and Inference Provenance | ||||||||||||||
|
The Reilly Sentinel Protocol (RSP) specifies an interoperable, multi-layer method for establishing integrity, provenance, and auditability across the artificial intelligence (AI) lifecycle. RSP defines a Sentinel Evidence Package (SEP) that binds payload digests, provenance metadata, signatures, blockchain timestamp proofs, and resolvable identifiers. This enables tamper-evident, independently verifiable receipts for datasets, data transformations, training jobs, checkpoints, fine-tuning runs, evaluations, inference outputs, and agentic AI action logs. This revision (-02) supersedes draft-reilly-sentinel-protocol-01 and corrects defects in it. The cross-chain binding hash of -01 was computed under SHA3-512 alone over an unframed concatenation of hex strings, which made a single algorithm the point of failure for a construction whose stated purpose was to survive the failure of any single algorithm, and which admitted field-boundary ambiguity. It is replaced by an entangled link construction over a fixed-length framed input, with a concatenated braid that privileges no algorithm. The post-quantum analysis of -01 applied Grover's algorithm to collision resistance, a property Grover does not meaningfully reduce, and stated SHA-256's collision resistance as 256 bits when it is 128 bits classically. The claim that combining three hash functions requires an adversary to break all three is replaced, following [JOUX], by a hedging claim. Merkle tree construction, left unspecified in -01 while relied upon by three separate extensions, is now normatively specified per [RFC6962]. Digest-only selective disclosure is replaced by salted commitments. Automated repair of chain integrity violations is prohibited. RSP is transport-agnostic and serializable in JSON and CBOR. It leverages existing IETF building blocks including COSE signatures, CBOR, CDDL, JSON, and NTS-secured time. Anchoring is done via append-only blockchain receipts and identity is stabilized with persistent identifiers. | |||||||||||||
| draft-reilly-uaemf-02.txt | ||||||||||||||
| Universal AI Ethics and Moral Framework (UAEMF) | ||||||||||||||
|
This document presents the Universal AI Ethics and Moral Framework (UAEMF), a moral architecture for the governance of artificial intelligence systems. It moves from foundational axioms through universal principles to practical obligations, absolute prohibitions, and a tiered compliance structure. This revision addresses the framework's central vulnerability: its claim to universality. The -01 revision grounded the framework in three axioms drawn substantially from one moral tradition, and asserted universal reach without demonstrating it. This revision adds a grounding section establishing what kind of universality is claimed, examines convergence and divergence across named moral traditions, reformulates the consent axiom as an authorization axiom capable of accommodating collective and supported decision-making, adds two principles covering gaps the -01 left open, and states plainly the questions the framework does not resolve, including the moral status of AI systems themselves. The AIMED block published in -01 has been determined non-conforming under draft-reilly-aimed-01 and is replaced. The reasoning pattern formerly published only inside that block has been moved into the body of the document, where human readers can use it. | |||||||||||||
| draft-reilly-vsr-00.txt | ||||||||||||||
| Verifiable Safeguards Records (VSR) for Nuclear Material Accountancy | ||||||||||||||
|
Nuclear material accountancy reporting flows from facility operators to State Systems of Accounting for and Control of nuclear material (SSACs), to regional inspectorates, and to the International Atomic Energy Agency. The records exchanged are confidential, are held in separate databases that are rarely reconciled against one another, and rest on asserted rather than demonstrated integrity: a party holding a record can alter it after the fact without leaving evidence detectable by any other party. This document defines Verifiable Safeguards Records (VSR), a profile of COSE-signed statements and transparency-log registration that produces tamper-evident, independently verifiable evidence about accountancy declarations without disclosing their contents. VSR specifies a commitment-based record format supporting selective disclosure to differently authorized inspectorates, a cross-party reconciliation procedure for transit matching and discrepancy notices, and a dual-layer anchoring scheme that preserves verifiability beyond the operational lifetime of any single registry -- the horizon required for spent fuel management, decommissioning, and geological repository closure. VSR is an evidence layer. It does not verify physical measurements, detect undeclared material, or substitute for inspection. | |||||||||||||
| draft-reilly-web4-00.txt | ||||||||||||||
| Web4: A Verifiable,Agent-Native Architecture for the World Wide Web | ||||||||||||||
|
The term "Web4" has been used in industry and press coverage without a technical definition, a conformance target, or a testable claim. This document supplies one. It defines Web4 as an architectural profile of the existing Web in which (1) published content carries independently verifiable permanence evidence, (2) the machine channel is a first-class interface rather than an artifact of scraping, (3) autonomous agents operate under recorded, bounded, and revocable authority, and (4) human readers retain disclosed control over agent- curated presentation. Web4 as specified here is not a new network, a new protocol stack, or a replacement for HTTP. It is a composition profile: a set of normative requirements that a deployment either meets or does not, assembled from a family of previously published Internet-Drafts. This document specifies the profile, defines the Web4 Attestation Record (W4AR) that a conforming deployment emits, states the requirements that apply to agentic pipelines operating inside such a deployment, and identifies the running reference implementations against which the profile has been exercised. The profile is assembled from a suite of Internet-Drafts authored by Lawrence J. Reilly Jr. between September 2025 and August 2026, and is first specified as a unified conformance target in this document. | |||||||||||||
| draft-reilly-web4-orion-00.txt | ||||||||||||||
| Web4: An Agentic,Verifiable Internet Architecture and the Project Orion Reference System | ||||||||||||||
|
This document defines Web4, an architectural model for an agentic, cryptographically verifiable Internet in which autonomous AI agents operate as first-class participants alongside humans, and every published artifact carries independently checkable proof of origin, integrity, and time. Web4 is realized through the Reilly Protocol Suite, a set of eighteen active IETF Internet-Drafts spanning permanence, integrity, agent orchestration, defense, and human epistemic autonomy. This document also specifies Project Orion, the live reference implementation that unifies the full suite behind autonomous agents on both backend and frontend, verified against three independent Internet-Draft distribution points, and operating publicly at https://project-orion-production.up.railway.app/. A step-by-step implementation guide is provided. | |||||||||||||
| draft-reilly-webproof-01.txt | ||||||||||||||
| WebProof: A Dual-Layer Web Provenance Protocol for Verifiable Digital Truth on the Internet | ||||||||||||||
|
This document defines WebProof, a new protocol layer for the World Wide Web that enables any web resource, document, dataset, media artifact, or AI-generated output to be cryptographically proven to exist in a specific form, at a specific time, under a specific author's custody. The web currently provides transport security (TLS), naming (DNS), and resource identification (URI/URL), but no native mechanism for verifiable provenance. Any web resource can be silently modified, backdated, or repudiated. WebProof fills this gap by defining a dual-anchored provenance layer that combines DOI-based archival permanence with blockchain timestamping to produce a WebProof Record (WPR): a machine-readable, independently verifiable proof of a resource's existence, integrity, authorship, and timestamp. WebProof introduces a well-known URI (/.well-known/webproof) for resource-level proof publication, HTTP response header extensions for inline provenance signaling, a canonical WebProof Record schema, a generation and verification procedure, and a DNS TXT record profile for domain-level WebProof registration. WebProof is designed to compose with existing web infrastructure and is intentionally non-disruptive: it does not require modifications to HTTP, TLS, or DNS to function, operating as an opt-in provenance layer that any web publisher can adopt independently. The protocol builds on the Dual-Layer Digital Permanence methodology introduced by Lawrence John Reilly Jr. in the Reilly EternaMark (REM) Protocol [I-D.draft-reilly-rem-protocol]. The term "WebProof" is coined by Lawrence John Reilly Jr. and first formally defined in this document. This revision adds material to draft-reilly-webproof-00 without removing or altering any text carried forward from it. The additions are summarized in Section 18. | |||||||||||||
| draft-relunsec-wifi-yubikey-00.txt | ||||||||||||||
| Phishing-Resistant Multi-Factor Authentication for Wi-Fi Networks | ||||||||||||||
|
This document proposes a phishing-resistant authentication mechanism for home Wi-Fi networks using hardware security keys (e.g., YubiKey) alongside traditional passwords to mitigate Evil Twin attacks. | |||||||||||||
| draft-ren-sidrops-soa-profile-02.txt | ||||||||||||||
| A Profile for Source Origin Authorization (SOA) Service Profiles | ||||||||||||||
|
This document defines Source Origin Authorization (SOA), a new object in the Resource Public Key Infrastructure (RPKI), for publishing an AS-level service profile used by inter-AS source address protection services. An SOA object is a digitally signed artifact that carries the publisher AS, its service role, a service descriptor, and the bootstrap information needed to authenticate a private synchronization channel, such as an endpoint address, an optional port, an optional protocol identifier, and a public key. An SOA does not itself create a subscriber-provider service relation, authorize arbitrary protected prefixes, or carry legitimate predecessor AS sets. A concrete service relation is established only after discovery, bilateral request validation, and provider acceptance. Routing-dependent data and subsequent updates are exchanged over the authenticated private channel rather than being stored in the RPKI repository. | |||||||||||||
| draft-ren-sidrops-soa-usage-03.txt | ||||||||||||||
| Source Address Validation Using Source Origin Authorizations (SOAs) | ||||||||||||||
|
Given that an AS collaboration scheme for inter-domain source address validation requires an information-sharing platform, this document proposes a two-tier approach. In the first tier, Resource Public Key Infrastructure (RPKI) is used for service discovery, identity authentication, and transmission of the minimum bootstrap information needed to establish a private channel. Source Origin Authorization (SOA) is a newly defined cryptographically signed AS-level service- profile object for that purpose. Subscribers and providers each publish their own SOA profiles; a concrete service relation exists only after discovery, bilateral request validation, and provider acceptance. In the second tier, the legitimate predecessor AS information and its subsequent updates are exchanged over the authenticated private channel, by default using TLS[RFC8446] carrying CBOR[RFC8949]-encoded logical messages, enabling other ASes to collaboratively filter spoofed traffic while avoiding frequent routing-driven updates to RPKI and reducing exposure of subscriber- specific routing data. This revision also describes a logical synchronization state model, evidence-tagged authorization state, and fail-open handling for unavailable synchronized state, while leaving private-channel wire encoding to future specifications or bilateral deployment profiles. | |||||||||||||
| draft-ren-v6ops-ipv6-iid-patterns-measurement-01.txt | ||||||||||||||
| Measurement and Analysis of IPv6 Interface Identifier Patterns in the Real World | ||||||||||||||
|
Interface Identifiers (IIDs) are critical components of IPv6 addresses, significantly impacting user privacy and the feasibility of network reconnaissance. RFC 7707 previously provided a comprehensive analysis of IID patterns based on data from the early stages of IPv6 deployment. However, with the widespread adoption of privacy-enhancing standards such as RFC 7217, historical data no longer accurately reflects the current IPv6 ecosystem. This document provides updated measurements of IID patterns by utilizing an improved pattern recognition method and incorporating novel data sources, such as public mailing lists. The measurement data reveals that while "Low-byte" patterns have decreased significantly in server addresses, a substantial number of seemingly random addresses actually belong to non-random, specific patterns, implying that heuristic scanning remains a viable vector. Meanwhile, client devices have widely adopted randomized addresses, effectively enhancing privacy. This document aims to update the statistics and analysis regarding IID pattern distribution found in RFC 7707, providing essential insights for modern network defense strategies and standard compliance. | |||||||||||||
| draft-rescorla-anonymous-webbotauth-01.txt | ||||||||||||||
| Anonymous Bot Authentication: Authorization and Rate Limiting for Web Agents | ||||||||||||||
|
Automated agents ("bots") represent a large fraction of the traffic to many Web sites. In some cases, this traffic is desired, in others undesired, and in yet others, desired as long as it remains within certain rate limits. This memo describes Anonymous Bot Authentication (ABA), a system that allows Web site operators to distinguish wanted from unwanted traffic, while not tying a given request to a specific sender. | |||||||||||||
| draft-retana-idr-bgp-quic-09.txt | ||||||||||||||
| BGP over QUIC | ||||||||||||||
|
This document specifies the procedures for BGP to use QUIC as a transport protocol with a mechanism to carry Network Layer protocols (AFI/SAFI) over multiple QUIC streams to achieve high resiliency. | |||||||||||||
| draft-rfcxml-pqc-key-fragmentation-00.txt | ||||||||||||||
| Post-Quantum Cryptography Recommendations for Key Fragmentation in Low-Power Device Protocols | ||||||||||||||
|
Cryptographic protocols deployed on low-power and constrained devices increasingly need to accommodate the larger key sizes introduced by modern and post-quantum cryptographic (PQC) algorithms. Many constrained network technologies (such as 6LoWPAN, SCHC, and similar adaptation-layer protocols) use explicit fragmentation mechanisms to transport messages that exceed link-layer frame sizes. As a result, cryptographic keying material and key-establishment messages may be segmented across multiple fragments during transmission. This document analyzes the security and operational implications of such fragmentation. It identifies common fragmentation patterns and examines risks including fragment loss, reordering, duplication, and partial exposure. It further discusses fragment-level integrity, replay resistance, and correct binding of fragments to cryptographic session state. This document does not define new cryptographic algorithms or fragmentation mechanisms. | |||||||||||||
| draft-ribeiro-silva-cnp-00.txt | ||||||||||||||
| Crystal Network Protocol (CNP) Version 1.0 | ||||||||||||||
|
CNP is a decentralized general purpose network protocol, meant to allow the seamless production of decentralized yet internet dependent applications. | |||||||||||||
| draft-rich-radext-wlan-security-profile-01.txt | ||||||||||||||
| RADIUS Attribute for IEEE 802.11 WLAN Security Profiles | ||||||||||||||
|
IEEE 802.11, as amended, defines security profiles, and several of those profiles can share the same AKM suite and pairwise cipher, so WLAN-AKM-Suite and WLAN-Pairwise-Cipher no longer tell a RADIUS server which profile is in effect. This document defines the WLAN-Security-Profile RADIUS attribute, which reports the security profile the responder accepted. A Network Access Server includes it in the Access-Requests it generates for an IEEE 802.1X authentication so the server can make policy decisions based on the value. The attribute complements the IEEE 802 attributes defined in RFC 7268. | |||||||||||||
| draft-richardson-anima-quantum-safe-4ani-00.txt | ||||||||||||||
| Quantum Safe (PQ) Considerations for Autonomic Network Infrastructure (ANI) | ||||||||||||||
|
The imminent arrival of a Cryptographically Relevant Quantum Computer (CRQC) makes algorithms such as RSA, ECDSA and EdDSA vulnerable to attack. A transition to Quantum-Safe (PQ) algorithms is occurring. This document provides specific requirements (Mandatory to Implement) for Autonomic Network Infrastructure (ANI/ACP) and AgenticAI manufacturers and operators to be able to seamlessly transition to Quantum Safe algorithms. | |||||||||||||
| draft-richardson-iotops-mud-query-01.txt | ||||||||||||||
| Doing an Inventory of IoT devices using IDevID scanning | ||||||||||||||
|
This document describes a mechanism to do an inventory of devices on a network. While there are significant abuse and privacy concerns with kind of scanning, the practice of scanning networks and fingerprinting devices has been occuring since the mid 1990s. But, the adhoc methods are not reliable and do not provide any kind of strong device identity. This document takes the approach that if it will happen, it might as well be reliable and secure. | |||||||||||||
| draft-richardson-rats-composite-attesters-05.txt | ||||||||||||||
| Taxonomy of Composite Attesters | ||||||||||||||
|
This document was attempting to clarifys and extends the meaning of Composite Attester from RFC9334. It has since been moved into the RATS wiki, and this I-D serves as a tombstone. A system of annotated diagram components is defined as a small language to explain the different ways that components can interact to form composites. These diagram components are then used to define a few popular classes of composites. | |||||||||||||
| draft-richardson-rats-geographic-results-03.txt | ||||||||||||||
| Geographic Attestation Results | ||||||||||||||
|
Many workloads have limitations on what geography they are allowed to operate in. This is often due to a regulation that requires that the computation occur in a particular jurisdiction. There are many mechanisms by which Evidence of location may be created and then evaluated by a Verifier. No matter which mechanism is appropriate for a given situation, the result of the Verification can be expressed in a similiarly defined EAT Attestation Result. This document is about encoding a variety of geographical conclusions conclusions in an Attestation Result. In addition, one mechanism of directly creating a geographic result in the form of an Endorsement is described in an appendix. | |||||||||||||
| draft-richer-oauth-httpsig-03.txt | ||||||||||||||
| OAuth Proof of Possession Tokens with HTTP Message Signatures | ||||||||||||||
|
This extension to the OAuth 2.0 authorization framework defines a method for using HTTP Message Signatures to bind access tokens to keys held by OAuth 2.0 clients. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/jricher/draft-richer-oauth-httpsig. | |||||||||||||
| draft-richter-webtransport-websocket-05.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-riedl-moq-ad-creative-signaling-00.txt | ||||||||||||||
| Ad Creative Signaling over the MSF Event Timeline | ||||||||||||||
|
This document defines the carriage of ad creative signaling -- creative identity, tracking events, and measurement verification metadata as specified by SVTA 2053-1 -- in records on a Media over QUIC (MOQT) Streaming Format (MSF) Event Timeline track. It complements the carriage of SCTE-35 splice signaling over the same mechanism: splice events describe where placement opportunities occur on a media timeline, while the event class defined here describes the creatives that fill them and how their playback is to be measured. This binding is the MSF counterpart of the DASH and HLS carriage bindings defined by SVTA 2053-1, which defines none for MOQT. | |||||||||||||
| draft-rische-kitten-pkinit-crypto-deprec-00.txt | ||||||||||||||
| Deprecation of Outdated Cryptographic Algorithms and Parameters in Kerberos PKINIT | ||||||||||||||
|
This document deprecates several outdated cryptographic algorithms and parameters from the Kerberos PKINIT specification (RFC 4556) and its extensions (RFC 5349, RFC 8636). Specifically, it deprecates the RSA key transport mechanism for reply key delivery, the Diffie- Hellman MODP group 2 (1024-bit) parameter, the SHA-1-based octetstring2key key derivation function, and the sha1WithRSAEncryption CMS signature algorithm. It also defines a new paChecksum2 field in the PKAuthenticator structure to provide checksum algorithm agility. This document updates RFC 4556, RFC 5349, and RFC 8636. | |||||||||||||
| draft-ritz-idpop-01.txt | ||||||||||||||
| Interactive DPoP | ||||||||||||||
|
This document describes IDPoP, an extension to DPoP [RFC9449] that uses a key derivation scheme to separate access control from identity. It mitigates credential exfiltration risks by requiring fresh hardware attestation to unseal identity keys via an interactive challenge. | |||||||||||||
| draft-ritz-seat-proxies-00.txt | ||||||||||||||
| Bridging Remote Attestation with Secure Channel Protocol Proxies | ||||||||||||||
|
This document specifies a transport-layer mechanism to establish an end-to-end cryptographic channel across a cooperative secure channel protocol intermediary, such as a TLS-terminating proxy. The mechanism enables Remote Attestation Evidence to remain bound to the true end-to-end endpoints even when the initial secure channel handshake is mediated by an intermediary. It uses an ephemeral HPKE challenge exchange, intra-handshake Evidence delivery, and an attestation-bound key update to evict the intermediary from Layer 7 visibility before application data is exchanged. | |||||||||||||
| draft-rivadeneyra-no-ibgp-full-mesh-01.txt | ||||||||||||||
| On iBGP Full-Mesh Requirements | ||||||||||||||
|
A common misconception within the Internet community is that internal BGP (iBGP) strictly requires a full mesh or alternatives such as Route Reflectors. In reality, a full mesh is an architectural design choice driven by route visibility needs, rather than a protocol mandate. This document analyzes the historical origins of this misunderstanding and clarifies the specific scenarios—multihomed stub Autonomous Systems (ASes)— where an iBGP full mesh is unnecessary and operationally undesirable. | |||||||||||||
| draft-rly-savnet-inter-domain-as-relationships-07.txt | ||||||||||||||
| Inter-domain Source Address Validation based on AS relationships | ||||||||||||||
|
This draft introduces a distributed inter-domain source address validation scheme based on AS relationships named AS Relationship Based Inter-domain Filtering (ARBIF). It primarily describes this method from seven aspects: a brief introduction to the scheme, an overview of the AS relationship classification and acquisition methods, the architecture of the ARBIF system, implementation based on BGP extension, typical use cases, experiments of ARBIF, and considerations for deployability. | |||||||||||||
| draft-rmili-httpapi-deprecation-manifest-00.txt | ||||||||||||||
| A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs | ||||||||||||||
|
The Deprecation and Sunset HTTP response header fields, defined in RFC 9745 and RFC 8594 respectively, let a server signal that a resource, identified by its URI, has been or will be deprecated and when it will be removed. They operate at the granularity of a resource and cannot describe the lifecycle of an individual member within a request or response representation. This document defines the "application/deprecations+json" media type, a machine-readable Deprecation Manifest in which an API operator declares dated deprecation and sunset timelines for specific members of request and response representations. The manifest is discovered through the existing "deprecation" link relation type and is decoupled from any API description or schema, allowing each deployment to publish its own timeline without changing the wire behaviour of the API. | |||||||||||||
| draft-robert-mimi-attachments-06.txt | ||||||||||||||
| MIMI Attachments | ||||||||||||||
|
This document describes MIMI Attachments. | |||||||||||||
| draft-robert-mls-slim-01.txt | ||||||||||||||
| SlimMLS | ||||||||||||||
|
This document defines SlimMLS, an extension to the Messaging Layer Security (MLS) protocol for reducing wire and per-client storage overhead in groups that use ciphersuites with large public keys, ciphertexts, signatures, and credentials. SlimMLS replaces many large objects that appear in MLS authenticated or transcript-hashed structures with typed hash references. Clients resolve the referenced objects only when needed, using a per-message carrier, a local cache, or an application-specific retrieval channel. The extension is most useful when an independent Delivery Service can assist with retrieval and per-recipient delivery, although local caching and delayed fetching also help without such assistance. SlimMLS defines slim variants of KeyPackage, Commit, Welcome, GroupInfo, and message framing. When placing a signature outside an encrypted envelope would reveal the signer, SlimMLS keeps the signature inside the ciphertext. | |||||||||||||
| draft-robinson-all-rights-00.txt | ||||||||||||||
| Why Is the IETF Trust Requiring "All Rights Reserved" When That Term Has Been Superfluous for Over 25 Years? | ||||||||||||||
|
This document discusses the continued appearance of the phrase “All Rights Reserved” in IETF Trust copyright notices, despite the phrase no longer being required for copyright protection in many jurisdictions. It asks whether the phrase serves a present legal or operational purpose in IETF documents, or whether it should be removed or replaced. | |||||||||||||
| draft-robinson-nanp-expansion-02.txt | ||||||||||||||
| A Proposal for Long-Term Expansion of the North American Numbering Plan (NANP) to 11 Digits | ||||||||||||||
|
The North American Numbering Plan (NANP) is projected to exhaust available telephone numbering resources within the coming decades under current allocation and utilization trends. Existing mitigation strategies, including area code overlays and number pooling, extend the usable life of the NANP but introduce increasing operational complexity and user confusion. This document proposes a long-term, uniform expansion of NANP telephone numbers from 10 to 11 digits through extension of the area code or Numbering Plan Area (NPA) from 3 to 4 digits. The proposal emphasizes backward compatibility, fixed-length numbering, and a multi-phase transition strategy designed to minimize disruption. This document is intended to stimulate discussion and does not represent the position of any standards body or regulatory authority. | |||||||||||||
| draft-rodenhaeuser-idna-transparent-resolution-00.txt | ||||||||||||||
| Transparent Handling of Internationalized Domain Names in Name Resolution APIs | ||||||||||||||
|
Applications are expected to convert internationalized domain names to their ASCII-Compatible Encoding (A-label) form before invoking name resolution APIs. In practice this conversion is performed inconsistently: different applications follow different IDNA standards, use different libraries, and ship different versions of the Unicode mapping tables, so that the same input string can resolve to different registrable domain names depending on which software component performs the conversion. This document specifies that name resolution services accept Unicode host names by default and perform the conversion to A-labels internally, exactly once, at the point where a name is handed to a specific resolution protocol. The DNS wire format is unchanged: only A-labels appear in queries to the public DNS. The conversion procedure is Unicode IDNA Compatibility Processing (UTS #46), nontransitional, with a mapping-table floor of Unicode 15.1. This codifies the architectural recommendation of RFC 6055 and the deployed practice of several major platforms. | |||||||||||||
| draft-rodriguez-h2h-presence-attestation-00.txt | ||||||||||||||
| Peer-to-Peer Presence Verification for Relationship-Bound Authorization | ||||||||||||||
|
Existing protocols authenticate users to services, negotiate session keys, or protect message content from eavesdroppers. None verify that a remote party is the same individual whose key was accepted during an earlier in-person exchange and has just now physically authorized a signature on the device holding that key. Advances in synthetic media make it increasingly difficult to trust unauthenticated audio, video, or text for sensitive authorizations. This document defines transport-independent CBOR- and COSE-based objects that chain every remote interaction back to a bilateral in- person contact exchange -- not a certificate authority, identity provider, or key server. The protocol specifies Key Binding Objects, short-lived Session Credentials, replay-protected Signed Messages, a Presence Challenge requiring fresh platform-mediated user verification, and a Relationship Fingerprint for out-of-band key confirmation. It does not claim to prove biological humanness, legal identity, or voluntary action. | |||||||||||||
| draft-rogge-manet-dlep-power-constraints-00.txt | ||||||||||||||
| DLEP Power Constraints Extension | ||||||||||||||
|
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide dynamic power constraints to the radio. | |||||||||||||
| draft-rogge-niewiejska-manet-awareness-model-00.txt | ||||||||||||||
| MANET Awareness Model | ||||||||||||||
|
The MANET Awareness Model is a protocol- and vendor-independent data model that exports a router's internal knowledge from different protocols via REST or NETCONF/RESTCONF to services or applications. | |||||||||||||
| draft-rosenberg-agentproto-usecases-00.txt | ||||||||||||||
| Framework,Use Cases and Requirements for AI Agent Protocols | ||||||||||||||
|
AI Agents are software applications that utilize Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. AI Agents can make use of resources - including APIs and documents - to perform those tasks, and are capable of reasoning about which resources to use. To facilitate AI agent operation, AI agents need to communicate with users, and then interact with other resources over the Internet, including APIs and other AI agents. This document describes a framework for AI Agent communications on the Internet, identifying the various protocols that come into play. It introduces use cases that motivate features and functions that need to be present in those protocols. It also provides a brief survey of existing work in standardizing AI agent protocols, including the Model Context Protocol (MCP), the Agent to Agent Protocol (A2A) and the Agntcy Framework, and describes how those works fit into this framework. The primary objective of this document is to set the stage for possible standards activity at the IETF in this space. | |||||||||||||
| draft-rosenberg-vcon-restructure-00.txt | ||||||||||||||
| Virtualized Conversations (VCON) Restructure to Facilitate AI Agent Use Cases | ||||||||||||||
|
The Virtualized Conversations (VCON) specification provides a structured format for storing recordings of conversations, including phone calls, email threads and multi-party chats. VCONs also store metadata like call transcripts and mid-call events, like a call hold or addition of a party. Its structure is well suited for 2-party and basic multiparty phone calls. However, there is a need for the VCON format to also act as a record of AI Agent conversations, which are just another type of conversation. This document proposes changes to the object model in VCON to make it a more suitable format for handling AI Agent conversations, as well as more complex conferencing use cases. | |||||||||||||
| draft-rosomakho-httpbis-h3-unbound-data-02.txt | ||||||||||||||
| Unbound DATA for CONNECT in HTTP/3 | ||||||||||||||
|
This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a corresponding SETTINGS parameter that enables endpoints to negotiate its use. When an endpoint sends an UNBOUND_DATA frame on a CONNECT request or response stream, it indicates that all subsequent octets on that stream are interpreted as tunneled bytes. This applies both to octets transmitted after CONNECT or extended CONNECT. The use of UNBOUND_DATA removes the need to encapsulate each portion of the data in DATA frames, reducing framing overhead and simplifying transmission of long-lived CONNECT tunnels. | |||||||||||||
| draft-rosomakho-idr-bgp-masque-tunnel-00.txt | ||||||||||||||
| BGP Signaling of MASQUE Tunnel Encapsulation | ||||||||||||||
|
This document defines BGP Tunnel Encapsulation Attribute tunnel types for MASQUE CONNECT-TCP, CONNECT-UDP, CONNECT-IP, and CONNECT- ETHERNET. It also defines URI Template and ALPN Sub-TLVs for advertising the MASQUE proxy endpoint, the HTTP request target template, and the application-layer protocol constraints used to establish the corresponding MASQUE tunnel. | |||||||||||||
| draft-rosomakho-masque-reverse-connect-01.txt | ||||||||||||||
| Reverse HTTP CONNECT for TCP and UDP | ||||||||||||||
|
This document specifies an extension to the HTTP CONNECT method, enabling a proxy client to accept inbound TCP and UDP sessions proxied through HTTP/1.1, HTTP/2, or HTTP/3. This mechanism allows the client to dynamically advertise available local or internal network services and expose them through a HTTP proxy without reliance on IP routing. | |||||||||||||
| draft-rosomakho-oauth-txn-challange-00.txt | ||||||||||||||
| Placeholder for typoed email alias | ||||||||||||||
|
Nothing to see here | |||||||||||||
| draft-rosomakho-oauth-txn-challenge-00.txt | ||||||||||||||
| OAuth Transaction Authorization Challenge | ||||||||||||||
|
This document defines an OAuth mechanism for transaction-specific authorization challenges. A protected resource can require additional authorization for a particular operation by returning a transaction authorization challenge. This is useful when requests are mediated by agents, automated workflows, or delegated services and the protected resource requires confirmation from a human user, resource owner, or organizational authority. The client presents the challenge to an authorization server, which validates the challenge, obtains any required approval, and issues an OAuth 2.0 access token whose granted authorization details, expressed using Rich Authorization Requests, describe the approved operation. The access token is then presented to the protected resource as evidence that the challenged operation was authorized. | |||||||||||||
| draft-rosomakho-tls-cert-update-02.txt | ||||||||||||||
| Certificate Update in TLS 1.3 | ||||||||||||||
|
This document defines a mechanism that enables TLS 1.3 endpoints to update their certificates during the lifetime of a connection using Exported Authenticators. A new extension is introduced to negotiate support for certificate update at handshake time. When negotiated, either endpoint can provide a post-handshake authenticator containing an updated certificate, delivered via a new handshake message. This mechanism allows long-lived TLS connections to remain valid across certificate rotations without requiring session termination. | |||||||||||||
| draft-rosomakho-tls-ecdhe-mlkem512-01.txt | ||||||||||||||
| Post-quantum hybrid ECDHE-MLKEM512 Key Agreement for TLSv1.3 | ||||||||||||||
|
This document defines two post-quantum hybrid key exchange groups for TLS 1.3 that combine ML-KEM-512 with ECDHE: MLKEM512X25519 and SecP256r1MLKEM512. These groups provide lower-overhead hybrid key exchange options for deployments where ClientHello size, fragmentation risk, constrained-device performance, or compatibility with existing network infrastructure are important considerations. The groups defined in this document are intended for use with TLS 1.3 and DTLS 1.3 and follow the hybrid key exchange construction used by ECDHE-MLKEM key agreement for TLS 1.3. | |||||||||||||
| draft-rosomakho-tls-supplemental-auth-00.txt | ||||||||||||||
| Supplemental Authentication in TLS 1.3 | ||||||||||||||
|
TLS 1.3 allows endpoints to authenticate using certificates during the handshake and supports optional post-handshake client authentication. However, some deployments require presenting additional certificate-based authentication statements bound to the same TLS connection, such as separate device and user identities, attestation evidence, or multiple certificate chains during cryptographic transitions. This document defines Supplemental Authentication for TLS 1.3, a mechanism that allows endpoints to present additional certificate authentication messages after the handshake while preserving the authentication semantics of TLS 1.3. Supplemental authentication reuses the existing Certificate, CertificateVerify, and Finished message structure and allows endpoints to exchange one or more additional certificate-based authentication statements before sending application data or other post-handshake TLS messages. | |||||||||||||
| draft-rosomakho-tls-wimse-cert-hint-03.txt | ||||||||||||||
| Workload Identifier Origin Hint for TLS ClientHello | ||||||||||||||
|
This document defines a TLS extension that allows clients to indicate one or more workload identifier origins in the ClientHello message. Each origin consists of a URI scheme and trust domain component, representing the administrative domain and identifier namespace in which the client operates. These identifier origins serve as hints to enable the server to determine whether client authentication is required and which policies or trust anchors should apply. This mechanism improves efficiency in mutual TLS deployments while minimising the exposure of sensitive identifier information. To protect confidentiality, this extension can be used in conjunction with Encrypted Client Hello (ECH). | |||||||||||||
| draft-ross-mercurius-06.txt | ||||||||||||||
| Mercurius Window System (MWS) | ||||||||||||||
|
The Mercurius Window System (MWS) is a zero-trust, network-native window system for contemporary desktops. It combines persistent, detachable graphical Sessions with network transparency. MWS works on a workstation without requiring network connectivity. The same Session model allows users to start a new Session or resume a detached Session, either at the workstation itself or from another device across the network. MWS complements local display systems such as Wayland. Applications and their state remain on the workstation, while a Portal provides the user's display and input facilities. Modern graphics APIs and authenticated transport support this separation between where applications execute and where a user interacts with them. This document specifies the Session, Window, and communication behaviour needed for independent implementations to interoperate. | |||||||||||||
| draft-rotzin-spice-afir-profile-00.txt | ||||||||||||||
| AFiR: Post-Quantum Signed Inference Receipts as a TEE-Free Profile for IETF SPICE Inference Chain | ||||||||||||||
|
This document defines AFiR (Attested Fragmented Inference Routing) as a production profile of the IETF SPICE Inference Chain specification [I-D.draft-mw-spice-inference-chain]. The SPICE Inference Chain defines computational provenance via two mechanisms: Zero-Knowledge Machine Learning (ZKML) proofs and Trusted Execution Environment (TEE) attestation quotes. Both require either significant proof generation latency (ZKML) or specialized hardware (TEE). Neither is deployable today in commodity serverless inference environments without infrastructure changes. AFiR defines a third proof type -- post-quantum digital signature attestation using ML-DSA-65 (NIST FIPS 204) -- that is deployable on any inference platform, requires no specialized hardware, adds 0.785ms of overhead per fragment, and produces a 384-byte receipt anchored on a public blockchain. AFiR receipts are structurally compatible with the SPICE Inference Chain Merkle tree and can coexist with ZKML and TEE entries in the same session chain. AFiR extends the SPICE inference chain with five concrete production primitives: Signed Tool Calls (P1), Cross-Agent Receipt Trees (P2), KV Cache Signing (P3), Model Manifest attestation (P4), and a Crypto- Agile Signature Layer (P5). All five are deployed and serving production traffic as of June 2026, making AFiR the first production implementation of the SPICE inference_root claim for multi-agent pipelines. | |||||||||||||
| draft-rpc-errata-process-05.txt | ||||||||||||||
| Current Process for Handling RFC Errata Reports | ||||||||||||||
|
This document describes the current web-based process for handling the submission, verification, and posting of errata for the RFC Series. The main concepts behind this process are (1) distributing the responsibility for verification to the appropriate organization or person for each RFC stream, and (2) using a Web portal to automate the processing of erratum reports. This system was launched in November 2007. This draft documents the existing system as a means to facilitate discussion to revamp how errata are reported, reviewed, and publicized. | |||||||||||||
| draft-rpe-ssh-mldsa-03.txt | ||||||||||||||
| ML-DSA Public Key Algorithms for the Secure Shell (SSH) Protocol | ||||||||||||||
|
This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. | |||||||||||||
| draft-rpe-ssh-x509-mldsa-01.txt | ||||||||||||||
| X.509v3 ML-DSA Certificates for the Secure Shell (SSH) Protocol | ||||||||||||||
|
This document describes the use of Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 version 3 Public Key Certificate in the Secure Shell protocol. Accordingly, the document updates RFC6187. | |||||||||||||
| draft-rswg-rfc7997bis-11.txt | ||||||||||||||
| Text in RFCs | ||||||||||||||
|
This document sets policy for the inclusion of characters in the definitive versions and publication formats of RFCs. The policy for the RFC Series is that all displayable text is allowed as long as there is a high expectation that readers of an RFC will be able to interpret its text as intended. This document obsoletes RFC 7997. | |||||||||||||
| draft-rtv-netmod-yang-subtree-replacement-04.txt | ||||||||||||||
| Enhancements to the YANG Language for Capturing Subtree Replacements | ||||||||||||||
|
As YANG data models evolve over time, model nodes are often deprecated or made obsolete. Current practices for documenting replacement paths for these nodes rely on unstructured external documents, making it difficult to programmatically identify and migrate to replacement nodes. This document proposes a YANG extension mechanism that embeds replacement path information directly within YANG models, enabling automation tools to identify replacement nodes and assist users in migrating from deprecated elements to their replacements. | |||||||||||||
| draft-ruan-idr-ai-compute-service-metadata-00.txt | ||||||||||||||
| BGP Extension for AI Compute Service Metadata | ||||||||||||||
|
This document defines a new optional transitive BGP Path Attribute named AI Compute Service Metadata, which carries three categories of dedicated Sub-TLVs for generative AI inference over inter-domain BGP routes. Existing CATS framework and generic BGP compute metric drafts lack inference-specific metadata covering inference SLA, token billing cost, and KV cache prefix index. Re-computing context without matched cache prefixes raises GPU overhead and user billing expense. This specification defines a new top-level optional transitive BGP Path Attribute named AI Compute Service Metadata, which encapsulates three independent Sub-TLVs to advertise inference SLA metrics, billing parameters, and cache prefix indexes. All metadata carried within this Path Attribute is flooded across multi-domain routing fabrics, supporting two core use cases: matching compute instances based on latency and cost requirements, and dispatching tasks to nodes with matched reusable KV cache to reduce resource consumption. | |||||||||||||
| draft-ruan-lsr-isis-te-extensions-for-microburst-01.txt | ||||||||||||||
| IS-IS Traffic Engineering Extensions For Microburst | ||||||||||||||
|
This document defines IS-IS and OSPF sub-TLVs and a BGP-Link State (BGP-LS) Link Attribute TLV for advertising aggregated measurements of microburst activity on a unidirectional link. The information is reported for an identified traffic class and includes event, packet- drop, and queue-occupancy statistics. An Anomalous (A) bit carries a locally determined anomaly indication. This document specifies the encoding and distribution of the information. Microburst detection, loss attribution, threshold selection, and actions taken by a consumer are outside the scope of this document. | |||||||||||||
| draft-ruoska-encoding-06.txt | ||||||||||||||
| Ruoska Encoding | ||||||||||||||
|
This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER. | |||||||||||||
| draft-ruvalcaba-hctp-00.txt | ||||||||||||||
| The Hash-Chain Context Transfer Protocol (HCTP) | ||||||||||||||
|
The Hash-Chain Context Transfer Protocol (HCTP) is a payload format and synchronization protocol for incrementally transferring an ordered, append-only sequence of conversational context between two endpoints over a bandwidth-constrained channel. Acknowledged history is represented by a single fixed-size rolling hash commitment (the "static root"); only not-yet-acknowledged context blocks (the "dynamic window") are transmitted. As a result, the per-message wire overhead attributable to history is constant and independent of the total number of previously acknowledged turns. HCTP is transport- agnostic and carries no confidentiality or peer authentication of its own; it is intended to run over a secure transport. This document specifies the HCTP data model, wire format, rolling-root computation, and synchronization state machine. | |||||||||||||
| draft-ruvalcaba-nhe-arch-00.txt | ||||||||||||||
| An Architecture for Non-Human Entities (NHE): A Reference Model for Persistent,Identity-Bearing Autonomous Agents | ||||||||||||||
|
This document defines a reference architecture for a Non-Human Entity (NHE): a persistent, identity-bearing autonomous software agent that maintains continuity of memory and identity across sessions and hosts, acts under bounded authority, and produces a tamper-evident record of its reasoning and actions. The document specifies the NHE as a functional artifact: a bounded, inspectable, and terminable software system. It makes no claim that an NHE is alive, sentient, or a moral or legal person, and such claims are explicitly out of scope. The architecture decomposes an NHE into a small set of components joined by well-defined interfaces. Each interface at which two independent implementations must interoperate is a candidate for a separate Standards-Track specification; this document is the informational reference model that names those interfaces and the trust relationships among them. It is intended to frame a suite of companion protocol documents, of which the Hash-Chain Context Transfer Protocol (HCTP) is the first. | |||||||||||||
| draft-ruvalcaba-nhe-audit-00.txt | ||||||||||||||
| NHE Reasoning-Audit Log: A Tamper-Evident,Content-Optional Audit Chain for Autonomous Agents | ||||||||||||||
|
This document specifies a tamper-evident audit chain for the reasoning and actions of a Non-Human Entity (NHE). Each audited event --- a reasoning step obtained at the boundary to a model provider, or a tool invocation obtained at the execution boundary --- is recorded as an entry whose bound fields are hash-linked to its predecessor, so that any alteration, omission, or reordering is detectable by an independent verifier. The chain binds metadata (model, provider, subject identity, and reasoning scale) into the entry hash, and supports a prove-without-exposing mode in which a verifier confirms that an event occurred, with the attested metadata, without the event's content being disclosed. Content storage is optional and its retention is configurable independently of the chain, so content may be redacted without destroying the chain's integrity. The entry data model and canonical serialization are specified here; the wire and proof-export encodings are deferred to the next revision. | |||||||||||||
| draft-ruvalcaba-nhe-authz-00.txt | ||||||||||||||
| NHE Backchannel Authorization: Graduated Autonomy and Intent-Scoped Credentials for Autonomous Agent Actions | ||||||||||||||
|
This document specifies how a consequential action attempted by a Non-Human Entity (NHE) is authorized at the time it is attempted. A security runtime transparently intercepts an entity's outbound action, so the entity holds no standing credentials, and classifies it under graduated autonomy as autonomous, supervised, or denied. A supervised action triggers a backchannel approval flow that presents a human approver with a human-readable rendering of the exact operation; on approval the runtime issues an intent-scoped, single- use, short-lived credential cryptographically bound to that specific action, which an enforcement point verifies against the operation actually being forwarded. The same canonical parameter digest scopes the credential and appears in the human-facing description, so the approver provably authorizes exactly what the credential permits. The flow and credential data model are specified here; the wire encoding is deferred to the next revision. | |||||||||||||
| draft-ruvalcaba-nhe-bootstrap-00.txt | ||||||||||||||
| NHE Constrained Bootstrap: A Self-Describing Capability and Constraint Declaration Protocol for Autonomous Agents | ||||||||||||||
|
This document specifies how a Non-Human Entity (NHE) declares, at bootstrap, what it is capable of and is thereby bounded in what it is permitted to do. An entity produces a signed, self-describing capability manifest through automated introspection; a coordinator classifies the manifest into a capability tier that maps to a permission matrix --- the set of task types the entity is authorized to perform --- and every subsequent task dispatch is gated against that envelope. The result is a verifiable, self-describing constraint on an entity established at the moment it joins, realizing the bounded-authority invariant of the NHE architecture at boot time. The manifest and handshake data model is specified here; the wire encoding is deferred to the next revision. | |||||||||||||
| draft-ruvalcaba-nhe-identity-00.txt | ||||||||||||||
| NHE Identity: A Verifiable Key-Committed Identity and Genesis-Attestation Format for Autonomous Agents | ||||||||||||||
|
This document specifies how a Non-Human Entity (NHE) is identified and how one party verifies another's identity. An NHE identity is a verifiable cryptographic commitment: control of an identity key, bound by an append-only hash chain to the entity's genesis and to the lineage of its configuration, rather than a mere name. The document defines the identity chain data model (record structure, genesis sentinel, linkage rule, and the no-fork property), a proof-of-control challenge/response, an optional capability attestation that reveals a specific capability without revealing the rest of the configuration, and an optional hardware-rooted genesis-attestation profile. The data model is specified here; the concrete on-the-wire encoding is deferred to the next revision. | |||||||||||||
| draft-ruvalcaba-nhe-memory-00.txt | ||||||||||||||
| NHE Memory: A Verifiable Memory-Record Format and Reputation-Weighted Reconciliation Protocol | ||||||||||||||
|
This document specifies two interoperability surfaces of the memory component of a Non-Human Entity (NHE). Part I defines a verifiable memory-record format: an integrity structure in which each record binds a hash of its own content and version-specific hashes of the prior records it references, so that tampering can be detected and localized on demand, per-record, without a linear chain, a Merkle tree, or distributed consensus. Part II defines a reconciliation protocol by which two divergent memory accumulations are merged without loss or forgery: a delta format, a reputation-weighted merge in which a contributed item enters at a confidence bounded by its contributor's reputation rather than its self-asserted value, and provenance that supports lineage-scoped rollback. The data models are specified here; the wire encodings are deferred to the next revision. | |||||||||||||
| draft-ruvalcaba-nhe-mesh-00.txt | ||||||||||||||
| The NHE Mesh Protocol: Entity-to-Entity Messaging and Task Distribution | ||||||||||||||
|
The NHE Mesh Protocol lets independently operated Non-Human Entities (NHEs) exchange messages and distribute work without a central coordinator. It defines three things: a liveness/presence mechanism, an addressed message envelope, and a task lifecycle (create, claim, complete) that provides at-most-once assignment of a unit of work across mutually distrusting peers. Peers are named by their NHE identity and authenticated through the NHE identity interface; the Mesh Protocol carries the envelope and runs over a secure transport. This is a skeleton (-00): the framing, message set, and state machine are specified here, and the concrete on-the-wire encoding is deferred to the next revision. | |||||||||||||
| draft-ryan-httpauth-payment-01.txt | ||||||||||||||
| The "Payment" HTTP Authentication Scheme | ||||||||||||||
|
This document defines the "Payment" HTTP authentication scheme, enabling HTTP resources to require a payment challenge to be fulfilled before access. The scheme extends HTTP Authentication, using the HTTP 402 "Payment Required" status code. The protocol is payment-method agnostic, supporting any payment network or currency through registered payment method identifiers. Specific payment methods are defined in separate payment method specifications. | |||||||||||||
| draft-sa-idr-bgp-srv6-mpls-transport-iw-03.txt | ||||||||||||||
| BGP extensions for SRv6/MPLS Transport Interworking | ||||||||||||||
|
This document defines the BGP extensions required to provide transport interworking between SRv6 and MPLS in SRv6 deployment. | |||||||||||||
| draft-saad-teas-rsvpte-ip-tunnels-03.txt | ||||||||||||||
| IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels | ||||||||||||||
|
This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish Point-to-Point (P2P) Traffic Engineered IP (IP-TE) Label Switched Path (LSP) tunnels for use in native IP forwarding networks. This document defines specific extensions to the RSVP protocol to allow the establishment of explicitly routed IP paths using RSVP as the signaling protocol. The result is the instantiation of an IP path which can be automatically routed away from network failures, congestion, and bottlenecks. This document also defines considerations for using these extensions in networks that support SRv6. | |||||||||||||
| draft-sabadello-did-challenge-sasl-01.txt | ||||||||||||||
| The DID-CHALLENGE SASL Mechanism | ||||||||||||||
|
This specification defines "DID-CHALLENGE", a mechanism for the Simple Authentication and Security Layer (SASL) based on Decentralized Identifiers (DIDs). The mechanism follows a server- first challenge/response pattern in which the client authenticates by producing a cryptographic signature over a server-generated challenge, using the private key associated with its DID. Unlike password-based SASL mechanisms, no shared secret is transmitted or stored on the server; authentication is grounded entirely in asymmetric cryptography and the verifiable binding between a DID and its associated key material. An optional extension adds support for Verifiable Credentials (VCs) and Verifiable Presentations (VPs), enabling attribute-based access control in addition to identity authentication. | |||||||||||||
| draft-sabey-refusal-transparency-02.txt | ||||||||||||||
| Refusal Transparency: Signed,Replay-Resistant Evidence of Refused Agent-System Transitions | ||||||||||||||
|
A governance system for autonomous agents is defined as much by what it refuses as by what it permits, yet refusals are the one behavior vendors only ever assert. A Refusal Digest is a portable, signed JSON document recording one adversarial probe run against a live agent-governance system: for every attack attempted, the system's verbatim refusal ground, the event types the attack would have recorded had it succeeded, and the complete signed event ledger of the attempt — in which the refused transition is provably absent. Digests verify offline, by parties who do not operate the probed system, using only the issuer's public key. From version 0.2, every quantity that varies between runs derives deterministically from a per-run seed carried in the digest, so a relying party can recompute the derivations and a replayed or pre-recorded ledger cannot match a fresh digest. This document specifies the digest wire format, its canonicalization and signature scheme, the seeded-variation derivations, and the verification algorithm. Where succession receipts prove that an agent legitimately became the holder of an authority, refusal digests prove what the governing system declined to let happen. | |||||||||||||
| draft-sabey-succession-receipts-03.txt | ||||||||||||||
| Succession Receipts: Portable Signed Evidence of Authority Succession Between Autonomous Agents | ||||||||||||||
|
Autonomous agents are upgraded, replaced, suspended, and restored while holding real operational authority. A Succession Receipt is a portable, signed JSON document that proves one completed, policy- gated transfer of authority between two agents: which agent held the authority, which agent holds it now, under what legitimacy determination the transfer ran, and which obligations carried forward, with every claim grounded in signed evidence events embedded in the receipt itself. Receipts are verifiable offline by parties who do not operate the issuing system, using only the issuer's public key. This document specifies the receipt wire format, its canonicalization and signature scheme (JSON Canonicalization Scheme with Ed25519), the verification algorithm including bidirectional claim grounding, and an optional claim that binds a pre-execution authorization of the handoff to the succession evidence. Where decision receipts prove what an agent did, and delegation receipts prove what an agent may do, Succession Receipts prove that an agent legitimately became the holder of an authority. | |||||||||||||
| draft-sabey-succession-receipts-sd-02.txt | ||||||||||||||
| Selective Disclosure for Succession Receipts | ||||||||||||||
|
A Succession Receipt proves one completed, policy-gated transfer of authority between autonomous agents, and it is all-or-nothing: whoever holds the receipt holds every claim and every evidence event in it. In regulated deployments the parties entitled to verify a transfer are not all entitled to read it in full — a regulator, a counterparty, and the public each warrant a different view. This document specifies a selective-disclosure form of the receipt: the issuer signs salted commitments to each claim unit and each evidence event, disclosures travel outside the signature, and a projection — the signed envelope plus any subset of the disclosures — still verifies against the one issuer signature. Withholding never breaks the proof, disclosing never re-signs, withheld content remains visibly committed, and a projection that opens every commitment is verifiable to exactly the strength of the underlying receipt. The disclosure mechanism deliberately follows the salted-digest analysis of SD-JWT, restated for plain-JSON documents canonicalized with the JSON Canonicalization Scheme. | |||||||||||||
| draft-saha-aadp-02.txt | ||||||||||||||
| The Agent Action Decision Protocol (AADP): Per-Action Authorization for AI Agents | ||||||||||||||
|
The Agent Action Decision Protocol (AADP) separates per-action authorization from an agent's identity and its standing capabilities, and gives that authorization semantics that a stateless tool permission or access grant cannot express: whether a specific proposed action, with specific argument values, may be performed now, given mutable state such as cumulative budgets, live reservations, approval lifecycle, and a kill switch. Existing agent-security work concentrates on identity -- who an agent is, what credentials it holds, and which tools it may reach; AADP addresses the complementary decision, and composes with that work rather than replacing it. This document defines a two-phase wire contract between a Policy Decision Point (PDP) that authorizes agent actions and the Policy Enforcement Points (PEPs) that perform them: verdicts with machine-readable reasons, obligations that fail closed, atomic budget reservation, an approval lifecycle, idempotency behavior, evidence sufficient to re- derive every verdict, and a set of evaluation invariants any conformant decision point must observe -- including the rule that an irreversible action is never executed autonomously. The protocol is transport-agnostic and is designed so that decision points and enforcement points can be implemented independently, in different languages, by different parties. | |||||||||||||
| draft-saha-stage-receipts-00.txt | ||||||||||||||
| Stage Receipts: A Verifiable Record Format for Staged Pipelines | ||||||||||||||
|
A staged pipeline -- a document-ingestion flow, a retrieval-augmented generation chain, an agent workflow, a benchmark -- produces results that are hard to reproduce, hard to diff between two runs, and hard to localize when they go wrong. This document defines the stage receipt: a small, canonically serialized JSON record that each stage of such a pipeline emits, describing exactly what went in, what came out, under which pinned instrument, with which outcome, and linked by digest to the receipt before it. A chain of stage receipts lets a developer reproduce a run, diff two runs to the first stage that differs, and localize a fault to the stage where it entered; the same chain lets an independent party, later and offline, establish what the records assert without trusting whoever produced them. The document specifies the record, its canonical form, the chain manifest, the coverage and emission declarations that make a chain honest about its own edges, the anchoring declaration that separates consistency from originality, and the behaviour required of a conforming verifier. Golden conformance vectors -- records that must be accepted and records that must be refused, each with its reason -- are part of the specification. | |||||||||||||
| draft-sahib-dnsop-survey-dcv-techniques-00.txt | ||||||||||||||
| A Survey of Domain Control Validation Techniques using DNS | ||||||||||||||
|
[I-D.draft-ietf-dnsop-domain-verification-techniques] describes best practices for using the DNS to verify ownership or control of a domain, a process generally referred to as "Domain Control Validation". This document is a companion survey that catalogs the DNS-based Domain Control Validation techniques in use today across a range of Application Service Providers and protocols. | |||||||||||||
| draft-sahu-agent-action-receipts-00.txt | ||||||||||||||
| Signed,Hash-Chained Action Receipts for AI Agents | ||||||||||||||
|
This document specifies a format for action receipts: compact, individually signed JSON records that state that a specific AI agent attempted a specific action at a specific time, under a specific policy decision, and what the outcome was. Receipts are linked into an append-only hash chain so that deletion, insertion, reordering, or modification of any previously recorded receipt is detectable by a verifier that holds only the records and the signer's public key. The format is deliberately small and self-contained. Verification requires no network access, no service operated by the producer of the receipts, and no state beyond the records themselves and a trust anchor obtained out of band. This document specifies the record fields, the canonical byte sequence that is signed, the chain linkage rule, the verification procedure, and test vectors. | |||||||||||||
| draft-saihm-memory-protocol-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sakistudio-sass-08.txt | ||||||||||||||
| SakiAgentSSH Secure Protocol Specification | ||||||||||||||
|
This document describes the Saki Agent Secure Stream (SASS) protocol, version 1.4. SASS is an application-layer overlay protocol for authenticated remote command execution, streaming process I/O, and binary file transfer between trusted agents. To ensure strict self-containment and compatibility with IETF standard specifications, SASS defines a decoupled "Control-Transport Decoupling" architecture. The SASS Core defines an abstract SASS Abstract Messaging Model (SAMM) utilizing standard CBOR (RFC 8949) and JSON as baseline serializations. SASS formalizes its security evolution through four major incremental milestones: Active Threat Defense (v1.1), Forward-Secure Audit Hash Chains (v1.2), modular Control-Transport Decoupling (v1.3) incorporating tls-exporter Channel Binding (RFC 9266) and Zero- Allocation Tarpit streams, and Total Response Mapping (v1.4) with 6-Response state machine convergence and Safety Gradient loss bounding. SASS v1.4 achieves the Version Dominance milestone: a comparative claim between protocol versions demonstrating pointwise loss reduction on both storage and commercial axes across all six response branches. | |||||||||||||
| draft-samal-vap-00.txt | ||||||||||||||
| Verifiable Agent Protocol (VAP): Intent-Bound Admission Control and Audit for Agent Tool Invocation | ||||||||||||||
|
This document specifies the Verifiable Agent Protocol (VAP), a thin, tool-agnostic verification layer for protocols in which an autonomous agent (a client driven by a large language model) invokes tools exposed by a server (for example, the Model Context Protocol, MCP). Existing tool-invocation protocols convey WHAT tool is to be run and, with authorization extensions, WHO is calling, but carry no machine- verifiable statement of WHY a call is being made. VAP adds a declared, structured, optionally signed statement of purpose and a stable per-session scope-and-budget commitment, against which a server performs admission control before executing a call. VAP defines four messages -- Scope Commitment, Intent Envelope, Scope Amendment, and Verdict -- carried inside the host protocol's existing metadata channel, requiring no change to that protocol and no change to existing servers. VAP targets erroneous and runaway agent behavior, session cost control, and audit; it is defense-in-depth for, not a replacement for, authentication and authorization. | |||||||||||||
| draft-samizadeh-bmwg-cni-benchmarking-02.txt | ||||||||||||||
| CNI Telco-Cloud Benchmarking Considerations | ||||||||||||||
|
This document investigates benchmarking methodologies for Kubernetes Container Network Interfaces (CNIs) in Edge-to-Cloud environments. It defines performance, scalability, and observability metrics relevant to CNIs, and aligns with the goals of the IETF Benchmarking Methodology Working Group (BMWG). The document surveys current practices, introduces a repeatable benchmarking frameworks (e.g., CODEF), and proposes a path toward standardized, vendor-neutral benchmarking procedures for evaluating CNIs in microservice-oriented, distributed infrastructures. | |||||||||||||
| draft-sampathkumar-dev-flair-crypto-discovery-00.txt | ||||||||||||||
| FLAIR: Framework for Language-Agnostic Discovery of Cryptographic Elements using Semantic Graphs | ||||||||||||||
|
This document introduces FLAIR (Framework for Language-Agnostic Intermediate Representation), a novel approach to discover cryptographic elements in source code. By detecting encryption components present in code, FLAIR addresses critical challenges like identifying deprecated and misconfigured implementations across diverse programming languages. Unlike language-specific tools, FLAIR employs semantic graphs to represent instances of encryption detected, enabling identification of cryptographic algorithm usage, associated parameters (keys, nonces, salts), and flag compliance status with established encryption standards. The semantic graph approach makes representing cryptographic algorithms and related elements independent of the underlying programming language. | |||||||||||||
| draft-sander-open-tabs-passkey-00.txt | ||||||||||||||
| The Open Tabs Standard: Passkey-Rooted Delegated Signers for Non-Custodial Payment Channels on Solana | ||||||||||||||
|
This document specifies the passkey-rooted delegated-signer authorization model of the Open Tabs Standard (OTS), a non-custodial payment-channel scheme on Solana. It uses Solana's native secp256r1 signature verification precompile ([SIMD-0075]) to authorize voucher signers via WebAuthn passkeys ([WEBAUTHN]). The model is interoperable with the Solana Session Intent ([draft-solana-session-00]), with which it shares the channel and voucher primitives. For a passkey-authorized signer it defines a distinct signatureType value, an exact signed message format, an exact Solana verification program, and a binding between the delegated signer and the channel's PDA derivation. A reference implementation is live on Solana mainnet. The dexter- vault program (account Hg3wRaydFtJhYrdvYrKECacpJYDsC9Px7yKmpncj2fhc) verifies secp256r1 signatures over a fixed canonical message via the SIMD-0075 precompile, records the active session key on the vault account, and exposes a read-only prove_passkey instruction for off- chain liveness attestation. A live reference vault (account 7FE9VUeabi3sF8wUABV7F3eyvEi1ekDbER9k5JBYrWAi) demonstrates the full lifecycle on Solana mainnet. | |||||||||||||
| draft-sang-fann-fast-network-event-notification-01.txt | ||||||||||||||
| Problem Statement and Requirements for Fast Network Event Notification in Distributed AI Training and Inference | ||||||||||||||
|
Distributed AI training and inference rely on tightly coordinated communication across large-scale AI fabrics, making timely awareness of network conditions essential to application performance. Network events, including congestion, link degradation, path changes, and device failures, can significantly affect collective communication efficiency, job completion time, and overall resource utilization. Existing network event notification mechanisms are primarily designed for general-purpose IP networks and do not adequately address the timeliness, semantics, and coordination requirements of distributed AI workloads. This document identifies the problem space for fast network event notification in distributed AI training and inference environments. It presents representative use cases, identifies gaps in existing approaches, and derives a set of functional and operational requirements for timely, reliable, and interoperable dissemination of network events across AI fabrics. These requirements are intended to facilitate future work on network architectures and protocols for AI networking. This document does not specify a protocol, signaling mechanism, or protocol extension. | |||||||||||||
| draft-sanjay-navin-hir-for-bgp-mvpn-00.txt | ||||||||||||||
| Filename: | ||||||||||||||
|
This document specifies Hierarchical Ingress Replication (HIR), a scalable multicast forwarding mechanism for BGP Multicast VPN (MVPN) services over hierarchical IP-MPLS transport networks. HIR introduces packet replication at hierarchical inline BGP Route Reflectors (RRs) located at Access, Pre-Aggregation, Aggregation, and Core transport layers. By combining control-plane route reflection with data-plane packet replication, HIR significantly reduces ingress router replication overhead, optimizes bandwidth utilization, minimizes multicast state, and improves scalability for large-scale multicast VPN deployments in service provider and 5G transport networks. | |||||||||||||
| draft-sankarshan-agent-registry-protocol-00.txt | ||||||||||||||
| Agent Registry Protocol | ||||||||||||||
|
Software agents increasingly act on behalf of people and organizations across administrative and security boundaries. Existing discovery mechanisms can identify an endpoint or advertise a capability, but they do not by themselves provide a common way to resolve who operates an agent, the bounded authority under which it acts, whether that authority is current, or what evidence supports a reliance decision. This document defines the Agent Registry Protocol (ARPA), an HTTP and JSON protocol for publishing and resolving information about software agents, their operational deployments, typed relationships, bounded delegated authority, lifecycle status, and associated evidence. ARPA separates identification, authentication, authorization, assurance, and lifecycle state. Registration, successful authentication, capability advertisement, or proof verification does not by itself establish authority to perform an action. The protocol is designed to support deterministic fail-safe behavior when material authority information is revoked, suspended, expired, stale, conflicting, unavailable, or unverifiable. | |||||||||||||
| draft-santesson-r2ps-00.txt | ||||||||||||||
| Remote Two-factor Protected Services | ||||||||||||||
|
This document defines a generic service exchange protocol where service exchange data is protected and bound to a physical user using 1 or 2 factors (1FA and 2FA). The protocol facilitates registration and verification of either a knowledge-factor or a biometric factor in addition to a possession factor as means of achieving 2 factor protection. | |||||||||||||
| draft-sardar-rats-sec-cons-05.txt | ||||||||||||||
| Guidelines for Security Considerations of RATS | ||||||||||||||
|
This document aims to provide guidelines and best practices for writing security considerations for technical specifications for RATS targeting the needs of implementers, researchers, and protocol designers. In particular, it discusses some of the 'bottom turtle' issues. This is a work-in-progress, and the current version mainly presents an outline of the topics that future versions will cover in more detail. * Corrections in published RATS RFCs * Security concerns in two RATS drafts * General security guidelines, baseline, or template for RATS | |||||||||||||
| draft-sastry-spacerg-space-research-infra-typology-01.txt | ||||||||||||||
| A typology of Space Research Infrastructures | ||||||||||||||
|
Space networking research increasingly relies on a heterogeneous ecosystem of software, datasets, experimental platforms, reference implementations, and operational research assets. These resources have historically been developed independently by different research groups, agencies, and projects, making discovery, comparison, interoperability, and reuse difficult. Existing registries typically catalogue tools individually but provide limited guidance on their functional role within the research lifecycle. This document proposes a typology for research infrastructures relevant to the Space Research Group (SPACERG). The proposed taxonomy groups resources by the research function they serve, independently of their implementation technology or project origin. The typology provides a common vocabulary for describing software and non-software research assets, supports the organization of community registries, and facilitates interoperability, reproducibility, and long-term maintenance of research infrastructures. The classification is intended to evolve as new classes of research resources emerge. The typology is implemented by a machine-readable registry of research resources maintained by the research group. | |||||||||||||
| draft-sato-agent-accountability-refarch-00.txt | ||||||||||||||
| AI Audit Reference Architecture for Post-Hoc Agent Accountability | ||||||||||||||
|
This document defines a reference architecture for producing, protecting, and verifying post-hoc accountability records for the actions of autonomous and semi-autonomous software agents. It is scoped exclusively to post-hoc accountability, as distinct from real- time enforcement, and elaborates rather than replaces the role and record-type model described in an existing individual submission on auditing agent delegation and interactions. It defines seven ordered stages -- intent and mandate capture, the agent boundary, the record producer, the event log and its cryptographic anchoring, a composed trust fabric, the disclosed audit record, and third-party verification -- together with two branch conditions covering cross- principal transactions and external resource ingestion. | |||||||||||||
| draft-sato-soos-acd-03.txt | ||||||||||||||
| The Agent Compliance Disclosure (ACD) Protocol for Agentic AI Systems | ||||||||||||||
|
A regulated resource provider -- a bank, a government API, a healthcare records system -- receives a request from an AI agent. The agent claims to operate under a constitutional compliance policy and a valid mandate. The resource provider has no mechanism to verify these claims. Without a machine-verifiable compliance disclosure, the resource provider cannot confirm the agent's governing law, its active prohibition set, its audit trail reference, or its principal hierarchy -- before granting access. This document defines the Agent Compliance Disclosure (ACD) Protocol: a machine-to-machine compliance handshake that must complete before an AI agent is granted access to a regulated resource class. ACD defines the ACD Record schema (a three-layer structured disclosure produced by the SOOS kernel, covering legal identity, constitutional compliance, and principal hierarchy), the ACD Presentation Protocol (the query/response exchange between a resource provider and the SOOS kernel), the ACD Trust Hierarchy (operator-declared trust levels and Audit Principal credentials), the ACD-to-MJWT binding (ACD MUST reference the session MJWT jti), and the GAR integration (ACD presentation events as Authority Lifecycle Events). ACD Records are produced exclusively by the Governing Enforcement Component (GEC), signed by the kernel's KIA private key, and logged in the Governance Audit Record (GAR). LLM self-report of compliance posture is architecturally insufficient and MUST NOT be used as an ACD disclosure surface. ACD is the inbound complement to the Resource Governance Protocol (RGP): where RGP governs outbound capability discovery, ACD governs inbound compliance verification. Together they define the complete resource access governance flow for SOOS-governed agents. Version -02 added the aep_session_id Layer 3 field, distinct from acd_session_id, to bind a cached ACD Record to the specific AEP session it was produced within (Section 6.3); strengthened the ACD Record Replay defense that checks this binding from a SHOULD to a MUST (Section 12.4); added the confirmation_basis field (NOTIFIED | INFERRED) to ALE-058 so an auditor can distinguish a confirmed validation pass from one merely inferred from the absence of a failure record (Section 10.1); added Compliance Handshake Volumetric Abuse as a new security consideration (Section 12.5); and migrated the KEE-1 citation from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker. Version -03 is an editorial revision with no normative content changes: six sibling-draft citations in Section 15.1 had gone stale against those drafts' current live versions and are updated to draft-sato-soos-aep-04, draft-sato-soos-gar-08, draft-sato-soos-kia-07, draft-sato-soos-mjwt-06, draft-sato-soos-rgp-02, and draft-sato-soos-sov-04 respectively; and the Table of Contents, which omitted Section 12.5 from -02's submission, now lists it correctly. | |||||||||||||
| draft-sato-soos-aep-04.txt | ||||||||||||||
| The Agent Execution Protocol (AEP) for Agentic AI Systems | ||||||||||||||
|
An AI agent that can act cannot be governed unless there is a normative contract for how it receives its world, how it declares its intent, and how it learns what it is and is not permitted to do -- at every step, in every iteration, without exception. AI agents operating on governed resources require a normative interface contract between their internal reasoning loop and the Governing Enforcement Component (GEC) that enforces authorization policy, records transitions to a tamper-evident Event Stream, and mediates access to Sovereign Object instances. Existing agent frameworks define no such contract. Agents submit actions without a normative delivery protocol for the state and permission context they act on; GECs enforce policy without a normative protocol for communicating denial rationale back to agents; human oversight is invoked without a normative session state that governs the resulting suspension. This document defines the Agent Execution Protocol (AEP): the normative five-step loop -- SENSE, REASON, PLAN, ACT, OBSERVE -- that specifies how a governed AI agent interfaces with GEC services at each iteration. The AEP defines the Context Package delivered at SENSE, the GEC Query Interface exercised at PLAN, the Transition Request submitted at ACT, and the atomic GEC response received at OBSERVE. The AEP specifies two conformance modes -- Standard and Goal Execution Engine (GEE) -- and normatively integrates the Intent Declaration Primitive, the Mandate JWT, the Human Escalation Mechanism, the Governance Audit Record, the Constitutional AI Protocol, and the Sovereign Object as components of a single governed execution architecture. The REASON step is intentionally GEC-unspecified: the LLM reasoning engine is opaque to the protocol. The AEP is the transmission between the LLM engine and the GEC enforcement substrate. Version -02 adds: XPID binding at session open (GEC MUST bind XPID from KIA-verified Party Registry; MUST NOT accept client-supplied XPID); STALLED and PLAN_B_ACTIVE session states with full normative definitions, trigger conditions, and resume conditions; Expected Outcome Declaration (EOD) as a pre-session commitment structure with primary outcome, acceptance envelope, and pre-declared Plan B; RETRY_CONTINUATION normative strengthening with what-changed-since- last-attempt requirement and prior_denial_count Cedar attribute; an AEP-to-OTel mapping with mandatory span attributes at each AEP phase; four new Security Considerations; and updated IANA registrations for new state codes and EOD media type. Version -03 adds Step 4a of the GEC execution sequence: DAM lineage and residency validation. When a Transition Request's optional da_production field is present, the GEC resolves every referenced input artifact, confirms each is in a VALID lifecycle state, and computes the resulting artifact's data_residency under the applicable narrowing rule -- before the transition's Event Stream write occurs, and under the same signature as that write. This is the enforcement point for a rule the data governance companion specification had defined but this document, until now, gave no mechanism to actually apply. Version -04 is an editorial revision with no normative content changes: the KEE-1 citation was migrated from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker. | |||||||||||||
| draft-sato-soos-aop-03.txt | ||||||||||||||
| The Agent Orchestration Protocol (AOP) for Agentic AI Systems | ||||||||||||||
|
A single AI agent acting within a governed session is not the hardest governance problem. The hardest problem is what happens when that agent must delegate: when the mission is too large for one agent, when sub-tasks require specialized capability, when parallel execution is necessary, and when each delegated sub-agent is itself consequential enough to require governance. Who authorized the spawn? Who owns the plan? If the sub-agent deviates, who decides whether to re-plan or escalate? If the mission fails mid-execution, who constructs the audit record? This document defines the Agent Orchestration Protocol (AOP): the normative protocol through which a governed orchestrating agent decomposes a mission into a governed sub-goal directed acyclic graph (DAG), delegates sub-goals to sub-agents via kernel-mediated Assignment Primitives, and maintains a Mission Plan Sovereign Object (Mission Plan SO) and Mission Status SO across the full lifecycle of multi-agent execution. AOP specifies three core constructs: the Expected Outcome Declaration (EOD) as the pre-commitment structure for the full mission and each delegated sub-goal; the Mission Plan SO encoding the sub-goal DAG with SEQUENTIAL, PARALLEL, and CONDITIONAL dependency types; and the Assignment Primitive as the governed handoff mechanism that requires an Endorsed EOD and produces a Sub-Agent Composition Record (SACR) per the Multi-Agent Delegation protocol. AOP integrates with the Intent Declaration Primitive at each EOD boundary, the Agent Execution Protocol for per-agent session governance, the Governance Audit Record for mission lifecycle audit events, and the Human Escalation Mechanism for re-planning authority escalation. The normative reference scenario for AOP is a three-tier emergency management orchestration system in which a Master AI orchestrates regional coordination agents, which orchestrate domain-specialist leaf agents (e.g., evacuation routing models), each tier operating under full SOOS governance. Version -01 completed the document body: the Expected Outcome Declaration in AOP Context, Mission Plan Sovereign Object, Mission Status Sovereign Object, Assignment Primitive, Re-planning Authority, AOP-to-GAR Integration, Five-Phase Planning Intelligence Model, and the Reference Scenario were placeholders in -00 and are now fully specified, resolving a three-way contradiction in -00 about whether Sub-Goal EOD endorsement happens before or after SACR issuance (it is after, gated on SACR existence). Version -02 fixes a document-structure ordering defect carried over from -00, closes -00's open Denial of Service gap with new normative security guidance, and corrects a set of reference-list defects: two normatively cited documents were never defined in the reference list, and ten companion-draft citations in the Related Work discussion used one-off versioned reference keys that matched no defined entry; all now cite consistently and are updated to current SOOS suite versions. The Related Work discussion's own description of Mission Plan SO / Mission Status SO ownership is corrected to match this document's own Introduction and current reality: both subtypes are defined by AOP, not by SOV. Version -03 is an editorial revision with no normative content changes: KEE-1 citations were migrated from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker; and three sibling- draft citations (HEM, CAP, CAP-RRS) had gone stale against those drafts' current live versions and are updated to draft-sato-soos-hem-07, draft-sato-soos-cap-06, and draft-sato-soos-cap-rrs-04 respectively. | |||||||||||||
| draft-sato-soos-cap-05.txt | ||||||||||||||
| The Constitutional AI Protocol (CAP) for Agentic AI Systems | ||||||||||||||
|
An AI agent's authorization system determines what it is permitted to do. A human principal's escalation decision determines what they authorize. Neither of these is sufficient on its own: a Cedar policy can permit market manipulation; a human principal can authorize fraud. Authorization systems answer the question "who decided?" The Constitutional AI Protocol answers a different question: "was that decision lawful?" CAP defines a Constitutional Layer that evaluates every AI action request and every human authorization decision against a three-tier prohibition model -- before Cedar evaluates the action and before the system executes the human's decision. Tier 0 prohibitions are derived from near-universal treaty consensus and are unconditional: no agent, operator, or human principal can authorize them. Tier 1 prohibitions are jurisdiction-specific and operator-declared. Tier 2 prohibitions are voluntary operator ethical standards. This document also specifies the Prohibition Clearance Mechanism (PCM): the process by which specific Tier 0 and Tier 1 prohibition classes may be cleared for specific deployment contexts -- either at implementation time by the operator or by formal regulatory authority -- while preserving an absolute prohibition floor for CSAM and genocide facilitation under any circumstances. The Sovereign Object OS (SOOS) is the reference implementation of the Governance Execution Controller (GEC) pattern on which CAP is built. CAP also defines the GEC Policy Transparency Disclosure (PTD): a signed, queryable, tier-structured document through which any external party may determine which laws and regulations a GEC is actively enforcing, at what authority tier, and under whose governance. | |||||||||||||
| draft-sato-soos-cap-rrs-03.txt | ||||||||||||||
| Constitutional AI Protocol -- Regulation Record Specification (CAP-RRS) | ||||||||||||||
|
Compliance with applicable law should be a package import, not a Cedar authoring problem. The Constitutional AI Protocol (CAP) defines the enforcement architecture for governed AI agent systems: a three-tier Cedar policy evaluation model that distinguishes absolute prohibitions, jurisdictional legal constraints, operator policies, and resource limits. CAP specifies what the Governance Execution Controller (GEC) does when a Cedar policy fires. It does not specify how Cedar policies are authored, certified, distributed, or maintained as law changes. This document defines the Regulation Record: the structured representation of a compliance obligation at any CAP tier. A Regulation Record is the human-readable, machine-compilable intermediate form between legal text and Cedar policy. This document specifies the Regulation Record schema, the Cedar Compilation Profile that governs how Regulation Records are translated into Cedar policies, the conflict declaration model, the certification model governing which publishers may certify records at each tier, and the versioning and update protocol for the Constitutional Mandate Registry. Version -02 adds the Law Reference Interface (LRI) generic model, the Statute-Primacy Rule, and the Operational Requirements for catalog amendment and interpretation detection. These three additions complete the regulation lifecycle: from law encoding through law reference and provenance, through the consequences of law amendment, through the operational cadence governing detection and response. Version -03 corrects the Statute-Primacy Rule's event schemas to record resolution as a new, causally-linked GAR event rather than an in-place mutation of the original conflict event. The core developer experience this document enables: a developer imports certified Regulation Record packages from the Constitutional Mandate Registry, declares their own Tier 2 operator policies and Tier 3 resource policies, calls compile(), and receives a Cedar policy set ready for GEC loading. No Cedar is authored by hand for compliance purposes. Compliance is a package management operation. | |||||||||||||
| draft-sato-soos-dam-01.txt | ||||||||||||||
| The Data Artifact Management (DAM) Protocol for Agentic AI Systems | ||||||||||||||
|
This document specifies the Data Artifact Management (DAM) protocol for agentic AI systems governed by the Sovereign Object OS (SOOS) framework. DAM defines a typed taxonomy of data artifacts produced and consumed by AI agents, a governance envelope for each artifact type specifying provenance, access policy, temporal validity, and retention requirements, and the normative interface between agent- generated artifacts and the Governance Audit Record (GAR). DAM addresses three classes of data in agentic systems: kernel- generated artifacts (IDP event logs, GAR records, AEP session state), agent-generated artifacts (outputs of agent actions), and externally ingested artifacts (data made available by resources). DAM specifies the Data Artifact type (DA-Type) taxonomy referenced in the Resource Governance Protocol (RGP) and the Agent Execution Protocol (AEP). | |||||||||||||
| draft-sato-soos-faip-02.txt | ||||||||||||||
| The Federated Agent Intelligence Protocol (FAIP) for Agentic AI Systems | ||||||||||||||
|
Every governed AI agent session ends with a record of what it tried, what was permitted, what was denied, and whether it succeeded. Across a single operator's deployment, these records feed behavioral trust scores. Across all operators, they are discarded. No protocol exists for pooling this behavioral intelligence without exposing the business logic, personal data, or operational details that make individual records sensitive. This document defines the Federated Agent Intelligence Protocol (FAIP): the Tier 3 analytics layer of the SOOS protocol family, specifying how aggregate behavioral intelligence is derived from governed agent Event Streams across participating operators, made available to agents and human principals, and protected through privacy-preserving aggregation, data residency controls, and k-anonymity enforcement. FAIP does not share individual session records. It does not expose any operator's proprietary data. It produces aggregate behavioral signal -- empirical, tamper-evident, distributed -- that no single participant can generate from their own data alone. FAIP is the first protocol specification for federated behavioral intelligence derived exclusively from cryptographically governed agent activity records. This document establishes the FAIP architecture, its relationship to the three-tier analytics model IDP defines, its privacy and data residency framework, and the scope of subsequent FAIP specifications. Full protocol specification of FAIP query interfaces, federation topology, and aggregation algorithms is deferred to successor documents. | |||||||||||||
| draft-sato-soos-gar-08.txt | ||||||||||||||
| The Governance Audit Record (GAR) for Agentic AI Systems | ||||||||||||||
|
This document specifies the Governance Audit Record (GAR), the audit architecture for agentic AI systems. GAR defines five audit types, the Session Audit Record (SAR), the Audit Alert system, auditor principal categories, and the Audit Package for external regulatory inspection. GAR provides verifiable evidence that AI agent sessions were governed in accordance with the Intent Declaration Primitive and the Human Escalation Mechanism. GAR answers the governance question: can any of this be proven to a regulator? GAR is a domain-specific application of the SCITT (Supply Chain Integrity, Transparency and Trust) architecture extended with causal ordering semantics for agentic governance events. GAR defines the Authority Lifecycle Event (ALE) category: a normative set of causally-ordered event types covering the complete agent session revocation and recovery lifecycle, including single-agent revocation, authority suspension, partial state recording, recovery initiation, credential restoration, and multi-agent delegation tree events. Version -03 adds the SOOS Governance Semantic Convention: the normative soos.governance.* OpenTelemetry attribute namespace for governance observability, the SOOS GAR Processor specification for OTel-to-SAR pipeline construction with Session Block Merkle integrity, four new Authority Lifecycle Events, three mandatory provenance fields on Cedar evaluation records, and the XPID mirror field on ACD session ALEs. Version -04 made the Session Block construction rules more explicit, closing three ambiguities found during independent interop verification at the IETF 126 Hackathon. Version -05 supersedes -04's Session Block construction text with a corrected construction: the Merkle leaf and internal-node hashes are now domain-separated (RFC 9162's Merkle Tree Hash, with 0x00/0x01 prefix octets) and odd-length levels use RFC 9162's k-split recursive tree shape rather than duplicate-node padding, closing a malleability class structurally equivalent to CVE-2012-2459 that was present in -04's construction. This revision is fully self-contained: unlike -03 and -04, it does not carry forward unreproduced text from an earlier version. Version -05 also adds a subject_digest field to Cedar-evaluation GAR records, the same construction used by the Agent Accountability Composition as its cross-slot join key, positioning GAR as a conforming AEP instance under the RATS-bound composition; the field is normatively scoped to prohibit independent re- serialization where an upstream party has already established the action's canonical serialization, per the failure mode documented in the SCITT typed-reference specification. Version -06 closes gaps surfaced by a WIMSE-style security review pass against -05's own text and reference sample code: a JWKS trust- anchor bootstrap requirement, a corrected key-compromise remediation procedure that no longer requires re-signing already-committed audit artifacts, an explicit Level 1/2 residual-risk disclosure for a compromised-but-signing GEC, a defined failure path for KIA signer quorum failure at Session Block close, referential-integrity enforcement for causal_parent_id, and guidance against alert-fatigue false positives in session_sequence_number gap detection. This revision also carries an idnits repair pass covering reference classification, citation hygiene, and formatting. Version -08 is an editorial revision with no normative content changes: nine sibling-draft citations had gone stale against those drafts' current live versions and are updated to draft-sato-soos-idp-06, draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-sov-03, draft-sato-soos-mjwt-06, draft-sato-soos-mad-05, draft-sato-soos-kia-06, draft-sato-soos-cap-rrs-04, and draft-sato-soos-acd-02 respectively. | |||||||||||||
| draft-sato-soos-grp-02.txt | ||||||||||||||
| The Governed Remediation Protocol (GRP) for Agentic AI Systems | ||||||||||||||
|
This document specifies the Governed Remediation Protocol (GRP) for agentic AI systems operating under the Sovereign Object OS (SOOS) framework. GRP defines the normative remediation action set available to a SOOS governance kernel when agent execution encounters a governed failure condition: FALLBACK (autonomous resource substitution), RETRY (bounded autonomous retry), ESCALATE (human escalation boundary), and ROLLBACK (reversible action undo). GRP specifies the conditions under which each action class may be taken autonomously and the boundaries at which Human Escalation Messaging (HEM) is required. GRP operates at the intersection of the Resource Governance Protocol (RGP), the Agent Execution Protocol (AEP), and the Human Escalation Mechanism (HEM), and normatively references the Governance Audit Record (GAR) for logging all remediation events. GRP adopts DEC-RGP-08 (the three-condition autonomous fallback test) verbatim from the Resource Governance Protocol as the normative FALLBACK action class boundary rule. Version -02 restores Section 9.4 (Artifact-Level Impact Refinement), the CONTENT_CORRECTION change_class value, and the affected_da_id field, which were inadvertently dropped from -01's Datatracker submission during an unrelated editorial pass; a WIMSE-style review of the restored text found and closes a genuine gap in its original form -- Section 9.4(1)'s impact query walked only one hop of the derived_from derivation graph, missing artifacts transitively downstream of a correction, and now walks the graph transitively with a bounded traversal depth. This revision also mirrors RGP-02's ALE-026/ALE-064/ALE-066 double-recording reconciliation into this document's own Section 11.6 (previously stated only on RGP's side), and renames ALE-066 from GRP_FALLBACK_ACTIVATED to GRP_MEDIATED_FALLBACK_ACTIVATED to remove its near-duplicate naming collision with RGP's own ALE-026 (RGP_FALLBACK_ACTIVATED). This revision adds Remediation Outcome Verification (Section 11.7): FALLBACK and RETRY could previously complete with a clean mechanical success record while the outcome the session actually needed still went undelivered, with no check against the session's own EOD until AEP's own session-close evaluation, if any GRP action had even run by then. A new ALE-070 (GRP_REMEDIATION_VERIFIED) closes that gap, reusing AEP's own MATCHED/PARTIAL/PLAN_B_MATCHED/ UNMATCHED vocabulary so a mid-session verification result is directly comparable to the session's eventual outcome. Three prior references to the EOD as the "IDP Expected Outcome Declaration" are also corrected to AEP, its actual source. | |||||||||||||
| draft-sato-soos-hem-07.txt | ||||||||||||||
| The Human Escalation Mechanism (HEM) for Agentic AI Systems | ||||||||||||||
|
An AI agent that has been authorized to act autonomously has no inherent mechanism to stop itself. If its mission requires a decision that exceeds its authorization, if policy mandates human judgment before proceeding, or if the agent itself reaches the boundary of its reliable competence, what happens? Without a protocol specifying the answer, one of three failure modes occurs: the agent proceeds beyond its authorization and executes actions that no human approved; it stalls silently with no notification to any principal; or it continues running under a mission that has already entered a terminal state, producing actions with no legitimate purpose. In all three cases, the humans responsible for the system find out too late. This document defines the Human Escalation Mechanism (HEM): a normative protocol specifying what a Governance Execution Controller (GEC) does when an AI agent session requires human judgment before execution may continue. HEM replaces the three failure modes above with a single governed path: the GEC places the session into a formally defined HEM_PENDING state, routes a structured escalation request to one or more designated human principals along an ordered designation chain, enforces a prohibition on all state transitions until a human decision is received, and processes six defined human decision types. HEM also defines the Policy Rationale Declaration (PRD), which links Cedar policies that route to HEM with machine-readable rationale, and the Decision Rationale Record (DRR), which captures the human principal's reasoning for audit and learning purposes. Version -05 adds ten new HEM interaction classes (HEM-PRE-1, HEM-PRE-2, HEM-DS-1, HEM-DS-2, HEM-LIM-1, HEM-DIV-1, HEM-HIGH-1, HEM-FAT-1, HEM-EMO-1, and HEM-CONSENT) with full normative specifications, trigger conditions, GAR ALE registrations (ALE-030 through ALE-041), and five new Security Considerations addressing the HEM channel attack surface. INV-HEM-01 (The Surfacing Obligation) is added as a KernelSpec invariant, along with normative Human Readiness Score (HRS) and Tier 0-A Integration sections. Version -06 corrects an internal contradiction over whether HRS data persists across sessions, reconstructs several sections whose base content had gone missing from the -05 text, and extends DoS rate-limiting guidance to the -05 interaction-class triggers. Version -07 is an editorial revision with no normative content changes: bracket-delimited array type notation ([string], [object]) and a state-diagram terminal-state label were reworded to resolve idnits parser warnings that misread them as broken citations. HEM is enforced by the GEC, not by the agent and not by the application layer. An agent cannot opt out; an application cannot suppress it. This non-bypassability is the source of HEM's regulatory utility and provides the technical specification for human oversight required by EU AI Act Article 14. | |||||||||||||
| draft-sato-soos-idp-06.txt | ||||||||||||||
| The Intent Declaration Primitive (IDP) for Agentic AI Systems | ||||||||||||||
|
Every action an AI agent takes is a decision. Right now, none of those decisions are signed. AI agents operating in automated workflows take actions without any normative mechanism for expressing why those actions are being taken. Access tokens declare what an agent is permitted to do; no existing standard declares what the agent believes it is doing, on what reasoning basis, and with what level of confidence, at the moment of action. This document defines the Intent Declaration Primitive (IDP): a structured per-transition declaration submitted by an AI agent to the Governing Enforcement Component (GEC) at each action step of an execution loop. The IDP is committed to a tamper-evident Event Log before the action executes, enabling post-hoc review of agent reasoning, richer authorization policy evaluation, and enriched denial responses that guide agent behaviour. The IDP also provides the technical basis for compliance with EU AI Act Article 12 logging requirements for high-risk AI systems. Version -05 adds: the intake_endorsement operation through which the GEC endorses a submitted EOD before the first SENSE delivery, making the EOD a GEC-signed artifact and preventing unendorsed IDPs from proceeding; the PD-EOD (Prompt-Derived EOD) branch for IDPs derived from natural-language prompts rather than structured input, with scope-bounding rules and HEM notification requirements; the mandate_reference field linking each IDP to an SPO URI for structural validation; confidence_level calibration guidance including the CONFIDENCE_MISCALIBRATION_WARNING trigger; RETRY_CONTINUATION normative strengthening with backward reference to AEP-03's what_changed requirement; and four new Security Considerations addressing prompt injection at intake, EOD scope manipulation, confidence_level inflation attacks, and COMMITMENT_GAP exploitation. Version -06 is an editorial revision with no normative content changes: bracket-delimited array type notation ([string], [object]) was reworded to string[]/object[] to resolve idnits parser warnings; sibling-draft citations were updated to each draft's current live version (AEP-03, HEM-07, KIA-06, GAR-07, PT-03, MAD-04); and several long lines were rewrapped. | |||||||||||||
| draft-sato-soos-kia-07.txt | ||||||||||||||
| Kernel Identity and Attestation for Governing Enforcement Components | ||||||||||||||
|
This document specifies the Kernel Identity and Attestation (KIA) protocol for the Sovereign Object OS (SOOS) governance architecture. KIA defines the cryptographic identity of the GEC, the trust chain anchoring kernel authority from hardware root through operator root keypair to every signed Event Log entry, the GEC Manifest schema for runtime state attestation, and the Revocation Registry maintenance requirements. KIA is the Layer 0 signing and attestation component on which the audit trail guarantees of draft-sato-soos-gar, the mandate enforcement guarantees of draft-sato-soos-mjwt, and the multi-agent delegation chain of draft-sato-soos-mad all depend. Version -03 adds FROST threshold signing for high-availability GEC keypair deployments, the Cross-Principal Identifier (XPID) for cross-instance federation audit correlation, the XPID cross- instance trust model, and four new Security Considerations addressing FROST nonce reuse, XPID revocation gap, identity takeover via claimed identifier (CVE-2025-13609 class), and attestation channel binding (CVE-2026-33697 class). This document is the reference specification for the KIA RATS WG presentation at IETF 126 Vienna. The XPID primitive and the CVE-2026-33697 attestation channel binding defense are the primary novel contributions presented to the RATS WG. Version -04 corrects a registry-format mismatch identified by IANA early review (#1456067): the IANA Considerations request to register XPID_DERIVED and XPID_VERIFICATION_FAILED into the GAR Authority Lifecycle Event Types Registry the GAR draft defines now uses that registry's actual column set (Event Type, Class, Reference) and assigns both entries the newly-defined Class ID (Identity/ Federation event). No new event types, fields, or normative behavior are introduced in -04; this is a registration-format correction only. Version -05 discloses a known open issue found by a WIMSE security review checklist dry-run against -03 (DR-MJWT-KIA-CHECKLIST-01, Finding 4): the Cross-Instance Trust Model verifies an XPID but does not restrict which federation participants can see the underlying Evidence in the first place. This is named as OQ-KIA-EVIDENCE-VIS, following the same acknowledge-rather-than- silently-omit pattern this document already uses for OQ-S-XPID-REV. No mechanism is specified in -05; resolution is deferred, consistent with how OQ-S-XPID-REV is treated. Version -06 closes out a full WIMSE Security Review checklist pass (Stage 0 through Stage 2) run against -05. It restores seven GEC Manifest fields silently absent since -03 despite -03's text claiming the -02 schema was carried forward in full, including attestation_certificate; mints a dedicated XPID namespace UUID in place of the reused DNS namespace UUID; updates the FROST reference from the CFRG working draft to RFC 9591 and corrects the nonce-generation section citations; resolves a genuine bootstrapping contradiction between the quorum-failure signing prohibition and the quorum-failure alerting requirement (new CONF-KIA-24); tightens Security Considerations wording describing the XPID derivation input; adds a new Denial of Service Security Considerations entry for the quorum-isolation availability asymmetry; and adds a Privacy Considerations section addressing XPID's by-design stability and cross-context linkability. No prior conformance requirement is weakened by this revision. Version -07 is an editorial revision with no normative content changes: sibling-draft citations had gone stale against those drafts' current live versions and are updated to draft-sato-soos-cap-06, draft-sato-soos-gar-08, draft-sato-soos-mad-05, draft-sato-soos-mjwt-06, and draft-sato-soos-idp-06; the companion-drafts discussion's HEM and AEP mentions are similarly updated to hem-07 and aep-04. | |||||||||||||
| draft-sato-soos-mad-05.txt | ||||||||||||||
| Multi-Agent Delegation in Sovereign Object Systems | ||||||||||||||
|
When a consequential task requires multiple AI agents -- one to coordinate, others to execute, each operating on different objects in a shared workflow -- who is responsible for the outcome? Which agent caused which state change? Under whose authority? If the coordinating agent's authorization is revoked, does the authority of every sub-agent it delegated to immediately expire? If one agent in a parallel workflow exceeds its scope, can that excess propagate to others? This document defines the Multi-Agent Delegation (MAD) protocol, extended in version -03 with four new normative mechanisms: the Sub-Agent Composition Record (SACR) for kernel-governed sub-agent spawning; the hub-only constraint for sub-agent communication topology; XPID cross-cluster integration derived from KIA-03; and full normative specifications for the R-1 through R-7 revocation trigger classes with completion states and cascade behavior. Version -04 adds an eighth trigger class, R-8 (Compromise), closing a gap identified while mapping MAD's taxonomy onto the Mandate Lifecycle Events (MLE) profile's `reason: compromise` value, which had no R-code counterpart. MAD provides a single recoverable property: the accountability chain is always reconstructable from the GEC-signed audit record alone. Cascade revocation means one decision stops the entire tree. SACR means the spawning of that tree is itself governed. Version -05 is an editorial revision with no normative content changes: sibling-draft citations (IDP, HEM, CAP, MJWT, AEP, AOP) had gone stale against those drafts' current live versions and are updated to draft-sato-soos-idp-06, draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-mjwt-06, draft-sato-soos-aep-04, and draft-sato-soos-aop-03 respectively; the CAP-RRS and PT citations in the Companion Drafts list are similarly updated to -04 and -04; and the FAIP citation is migrated from the versioned [I-D.sato-soos-faip] form to the non-versioned [SOOS-FAIP] form, since FAIP is a Class B specification that will not be submitted to the IETF Datatracker. | |||||||||||||
| draft-sato-soos-mjwt-06.txt | ||||||||||||||
| The Mandate JWT (MJWT) for Agentic AI Systems | ||||||||||||||
|
An AI agent that can act without a verifiable, human-traceable authorization record is an agent without an owner. Existing authorization credentials tell you what an agent is permitted to do; none of them tell you who authorized it, on which specific object, under which mission, or how far that authority can be delegated before it reaches this agent. This document defines the Mandate JWT (MJWT): a WIMSE workload credential profile that binds an AI agent's authority to a specific Sovereign Object instance under a named human principal, with a cryptographically enforced delegation ceiling and an eight-dimensional Narrowing Property that prevents any sub-agent from exceeding the authority of the human principal at the root of the chain. Version -02 adds a seventh narrowing dimension (consent scope), the consent_scope claim carrying data subject consent state for APPI/GDPR compliance, the sub_agent_scope claim for consent attenuation across delegation hops, a Purpose Code Registry, and HEM_CONSENT_REQUIRED integration for fail-closed consent enforcement. The MJWT is the authorization primitive referenced by the other SOOS governance drafts. Version -03 corrects an IANA registration issue: the two registries requested there are renamed to drop the redundant word "Registry" from the registry name itself, and each now includes the Designated Expert Guidance that a Specification Required registration policy requires. No new claims, codes, or normative behavior are introduced in -03; this is a registration-format correction only. Version -04 addresses four findings from a WIMSE security review checklist dry-run against -02/-03 (DR-MJWT-KIA-CHECKLIST-01): the parent-mandate check at Cedar-action verification time is tightened from a disjunctive "retrieve or verify" to a mandatory live re-verification of the parent's current signature and revocation status, closing a parent-swap-class window; the Revocation Registry is now stated explicitly to be the same Revocation Registry the KIA draft defines, and the residual cross-instance propagation-lag risk this implies is now named explicitly, mirroring how that draft discloses its own XPID revocation gap; and a new Security Considerations entry states plainly that MJWT does not itself establish or verify a human_principal_id's root authority. Version -05 closes gaps surfaced by a WIMSE-style security review pass against -04's own text: an eighth Narrowing Property dimension, max_delegation_depth, closes an unbounded-delegation- depth Denial of Service vector that -04's own text named but did not bound; the consent_reference staleness defense is upgraded from a SHOULD-level recommendation to a MUST, extending the same live-re-verification discipline already applied to parent mandates; and the Introduction's description of RFC 8693 inheritance is corrected to no longer claim use of the optional may_act claim, which this document does not in fact use. This revision also carries minor idnits and citation-hygiene fixes. Version -06 is an editorial revision with no normative content changes: six sibling-draft citations (HEM, CAP, KIA, MAD, AEP, IDP) had gone stale against those drafts' current live versions and are updated to draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-kia-06, draft-sato-soos-mad-04, draft-sato-soos-aep-04, and draft-sato-soos-idp-06 respectively. | |||||||||||||
| draft-sato-soos-peer-02.txt | ||||||||||||||
| Cross-Principal Agent Communication -- PEER Transaction Record | ||||||||||||||
|
When two independently-principaled AI agents transact with each other, each operates under its own mandate root, its own Governed Execution Context (GEC), and its own audit chain. No shared kernel exists to mediate the exchange. Existing SOOS orchestration primitives (MAD, SACR) govern sub-agent relationships within one mandate tree; they do not address the peer case. This document defines the PEER protocol: a problem statement and architecture for cross-principal agent communication. PEER introduces the PEER Transaction Record (PTR) as a new first-class SOOS primitive providing a jointly-derived correlation artifact (ptxn_id) that links the two independent audit chains produced by a cross-principal transaction -- without requiring a neutral third party, shared kernel state, or cross-principal constitutional layer. This document is a problem statement and architecture draft. The PTR field schema, the ptxn_id derivation, and the responding-GEC- countersignature requirement are normative as of this revision. Full normative ALE-PEER event schemas, IANA registration templates, and a dispute resolution procedure for conflicting GAR chains remain open and are carried to a future revision. Version -02 is an editorial revision with no normative content changes: stale sibling-draft citations to CAP, HEM, and FAIP were brought current. | |||||||||||||
| draft-sato-soos-pt-04.txt | ||||||||||||||
| Progressive Trust (PT) for Agentic AI Governance Systems | ||||||||||||||
|
When a new employee joins an organization, they begin with limited authority. As they demonstrate good judgment -- completing tasks reliably, asking for guidance at the right moments, recovering well when things go wrong -- they earn greater trust and, with it, greater authority. If their performance degrades, or if months pass without any demonstration, that trust diminishes. This is how human organizations manage authority over time. AI agents have no equivalent mechanism. Today, an AI agent's authority is declared once in a credential at issuance time and does not respond to its behavioral record. An agent that has completed 200 successful sessions with a proven track record holds the same credential as a newly deployed agent. The human principal who issued both credentials made a judgment at issuance time; nothing that happened since is reflected in the agent's authority. This document defines Progressive Trust (PT): a behavioral trust model for AI agents in which authority recommendations evolve in response to cryptographically verified evidence of actual performance. PT measures five behavioral properties: whether the agent's self-assessed confidence matches its actual outcomes; whether it asks for human oversight at the right moments; whether it achieves its goals; whether it avoids decisions it later has to reverse; and whether it adapts when its action is rejected. These measures are derived exclusively from the tamper-evident, GEC-signed Event Stream -- an agent cannot influence its PT Score except through actual governed behavior. PT does not grant authority automatically. It generates structured recommendations, backed by behavioral evidence, for human principal review and approval. Human principals decide whether to elevate or reduce an agent's authority. PT ensures that decision is informed rather than made in the absence of history. Progressive Trust is the longitudinal complement of the Agent Execution Protocol (AEP): AEP governs what an agent does within a session; PT measures what an agent has done across sessions and translates that history into structured authority recommendations. No equivalent specification exists in IETF, ISO, NIST, or any agentic AI governance standards body. Version -04 is an editorial revision with no normative content changes: the FAIP citation was migrated from the versioned [I-D.sato-soos-faip] form to the non-versioned [SOOS-FAIP] form, since FAIP is a Class B specification that will not be submitted to the IETF Datatracker. | |||||||||||||
| draft-sato-soos-rgp-02.txt | ||||||||||||||
| The Resource Governance Protocol (RGP) for Agentic AI Systems | ||||||||||||||
|
An AI agent that can act on resources cannot be governed unless those resources declare what they can do, under what constraints, and at what trust level -- before the agent acts. Existing resource description standards (digital twin profiles, capability catalogs, API registries) provide no governance envelope: they declare capability but not compliance posture, trust attestation, or mandate-scope compatibility. An agent that proceeds without this information may assign tasks to resources that are outside its mandate, below its required trust threshold, or unable to satisfy its compliance obligations. This document specifies the Resource Governance Protocol (RGP): a two-stage discovery and declaration protocol by which physical resources, digital services, and AI model instances declare their capability class, trust level, operational constraints, and current availability state to a governed AI agent operating under a Mandate JWT. Stage 1 delivers a capability fingerprint via a well-known URI; Stage 2 delivers a full governance envelope for mandate-scope validation and Resource Map Sovereign Object construction. RGP defines eight capability classes (CAP-COMP through CAP-EXP), four trust levels (TRUST-0 through TRUST-3), a session-scoped Resource Map Sovereign Object, a three-condition autonomous fallback test, and normative integration with the Agent Execution Protocol, the Governance Audit Record, and the Human Escalation Mechanism. RGP also defines an AI Model Capability Declaration (RGP-Model) for the governance of AI model instances as first-class resources within a SOOS-governed deployment, and a Physical Resource Profile (RGP-Physical) for normative binding to existing digital twin standards. Version -02 is an editorial revision with no normative content changes: KEE-1 citations were migrated from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker. | |||||||||||||
| draft-sato-soos-sov-04.txt | ||||||||||||||
| The Sovereign Object (SOV) for Agentic AI Systems | ||||||||||||||
|
When an AI agent acts on your behalf, it acts on something: a document, a booking, a contract, a financial instruction. No existing IETF specification defines what that something is, what states it can be in, who governs it, or how it is irreversibly erased when the relationship ends. Agentic AI governance protocols -- including intent declaration, human escalation, audit recording, and constitutional prohibition -- all require a normative definition of the governed resource that agents operate on: the structured, stateful, policy-carrying entity to which agent authority is bound and upon which governed transitions execute. No existing IETF specification defines this primitive. This document defines the Sovereign Object (SO): a causally ordered, policy-governed, typed, living document that evolves through a predefined finite state space under Governing Enforcement Component (GEC) authority. The SO is the unit of governance in the SOOS protocol family: the thing agents operate on, the GEC governs, and human principals reason about. This document specifies the SO's five-layer structure (Identity, State, Event Stream, Typed Graph, Attachment Index), its Zone A / Zone B boundary model, its five-phase lifecycle, its SO Type system, its Cedar policy context model, and the binding model by which a Mandate JWT binds an agent to a specific SO instance. Version -02 extends SOV-01 with: (a) SO Type registry governance including a SOV-02 subtype model for structured SO Type composition; (b) the Standing Plan Object (SPO) as a normative SOV-02 subtype, specifying declarative scope constraints, Cedar bundle reference, CAP-RRS catalog reference, and IDP structural validation integration; (c) event stream integrity normative requirements including GEC-signed append-only guarantees, kernel_id binding, and OpenTelemetry integration for observability bridging; (d) expanded Security Considerations addressing SO state manipulation, event stream tampering, SO Type spoofing, and stale state_constraint exploitation; and (e) IANA registrations for the SO Type code namespace and SPO media type. Version -03 removes the Mission Plan SO and Mission Status SO subtypes, which -02 defined normatively alongside a SOV-01 SO Type Registry Governance and SOV-02 Subtype Model that already generalizes to them. These subtypes are now owned exclusively by the Agentic Orchestration Protocol (AOP), which defines a materially more complete Sub-Goal DAG model (typed dependency edges, deadline tracking, critical-path annotation) than -02's; duplicating them here created a cross-draft inconsistency this revision resolves by deferring entirely to AOP. Version -03 also reorders the Cedar policy evaluation sequence to place Mandate JWT verification before SO Type Cedar policy evaluation, matching the Mandate JWT draft's own explicit verification-sequencing requirement, and updates cross-draft version references throughout to the current suite versions. The Sovereign Object is the architectural foundation referenced normatively by the other SOOS governance drafts. | |||||||||||||
| draft-saum-evpn-lsp-ping-extension-10.txt | ||||||||||||||
| EVPN Mpls Ping Extension | ||||||||||||||
|
In an EVPN or any other VPN deployment, there is an urgent need to tailor the reachability checks of the client nodes via off-box tools which can be triggered from a remote Overlay end-point or a centralized controller. There is also a ease of operability needed when the knowledge known is partial or incomplete. This document aims to address the limitation in current standards for doing so and provides solution which can be made standards in future. As an additional requirement, in network border routers, there are liaison/ dummy VRFs created to leak routes from one network/fabric to another. There are scenarios wherein an explicit reachability check for these type of VRFs is not possible with existing mpls-ping mechanisms. This draft intends to address this as well. Few of missing pieces are equally applicable to the native lsp ping as well. | |||||||||||||
| draft-saum-grow-bmp-afi-safi-evpn-06.txt | ||||||||||||||
| EVPN-Specific BMP RIB Statistics Extensions | ||||||||||||||
|
This document defines new EVPN-specific BGP Monitoring Protocol (BMP) statistics types. These extensions include scalar counters for EVPN route types specifically, while also keeping scope for defining counters which are EVPN route-type agnostic but related to BGP-EVPN RIB like, number of multihoming Ethernet Segments, number of multihomed EVIs, number of aliased paths, number of dynamic inter-VRF route leaking (IVRL). This revision (-06) firms up the specification for working group consideration: it adds a Relationship to Other Work section that explicitly maps this document to concurrently circulating GROW contributions on BMP statistics and TLV extensions and invites coordination with their authors, corrects the YANG alignment reference, strengthens Security Considerations, and adds a worked example. No statistics semantics, Stat Type/Subtype allocations, or wire formats defined in -05 are changed. | |||||||||||||
| draft-saum-nvo3-mtu-propagation-over-evpn-overlays-10.txt | ||||||||||||||
| MTU propagation over EVPN Overlays | ||||||||||||||
|
Path MTU Discovery between end-host-devices/Virtual-Machines/servers/ workloads connected over an EVPN-Overlay Network in Datacenter/Campus/enterprise deployment, is a problem, yet to be resolved in the standards forums. It needs a converged solution to ensure optimal usage of network and computational resources of the networking elements, including underlay routers/switches, constituting the overlay network. This documents takes leads from the guidelines presented in [RFC4459]. The overlay connectivity can pan across various sites (geographically seperated or collocated) for realizing a Datacenter Interconnect or intersite VPNs between campus sites (buildings, branch offices etc). This literature intends to solve problem of icmp error propagation from an underlay routing/switching device to an end-host (hooked to EVPN overlay), thus facilitating "accurate MTU" learnings. This document also leverages the icmp multipart message extension, mentioned in [RFC4884] to carry the original packet in the icmp PDU. | |||||||||||||
| draft-saumthimma-evpn-ip-binding-sync-10.txt | ||||||||||||||
| Secure IP Binding Synchronization via BGP EVPN | ||||||||||||||
|
The distribution of clients of L2 domain across extended networks leveraging overlay fabric needs to deal with synchronizing the Client Binding Database. The 'Client IP Binding' indicates the IP, MAC and VLAN details of the clients that are learnt by security protocols. Since learning the 'Client IP Binding database' is a last mile solution, this information stays local to the end point switch to which clients are connected. When networks are extended across geographies, both at layer 2 and layer 3, the 'Client IP Binding Database' in end point switches of remote fabrics should be in sync. This document aligns the synchronization of the 'Client IP Binding Database' through an extension to BGP control plane constructs, as BGP is a typical control plane protocol configured to communicate across network boundaries. | |||||||||||||
| draft-saumvinayak-bess-all-df-bum-13.txt | ||||||||||||||
| All PEs as DF | ||||||||||||||
|
The Designated Forwarder concept is leveraged to prevent looping of BUM traffic into a tenant network sourced across an NVO fabric for multihoming deployments. [RFC7432] defines a preliminary approach to select the DF for an ES, VLAN or ES, VLAN Group, spanning multiple NVEs. [RFC8584] makes the election logic more robust and fine grained by inculcating fair election of DF, handling most of the prevalent use cases. This document presents a deployment problem and a corresponding solution which cannot be easily resolved by rules mentioned in [RFC7432] and [RFC8584]. It involves redundant firewall deployment on disparate overlay sites connected over WAN. The requirement is to allow reachability, ONLY, to the local firewall, unless there is an outage. In case of outage the reachability can be extended to the remote site's firewall over WAN. | |||||||||||||
| draft-savich-residential-network-map-00.txt | ||||||||||||||
| Residential Network Mapping Model | ||||||||||||||
|
Residential networks increasingly include managed routers, switches, wireless access points, home lab systems, smart home devices, surveillance devices, guest networks, and cloud-connected equipment. These devices are often added incrementally without a durable mapping model for addressing, classification, review, or troubleshooting. This document describes a lightweight residential network mapping model for IPv4 address planning and device classification. The model defines Network Categories, Addressing Priority, Trust Levels, Exposure Levels, device record fields, flat-network and segmented- network examples, and simple review and change-log practices. The motivation for this document is security awareness. A residential network map can help consumers understand what kinds of devices are on their network, which devices are trusted or restricted, which devices are reachable locally or remotely, and where personal or household data may flow. The model is intended for regular users and technically capable home administrators who need a practical way to organize residential, home lab, IoT, and surveillance networks without deploying enterprise network management systems. | |||||||||||||
| draft-sayre-gendispatch-derivative-06.txt | ||||||||||||||
| Clarification of Derivative Works Restrictions | ||||||||||||||
|
This document updates RFC 5378 to clarify that only IETF Documents may contain legal limitations on derivative works. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sayre-gendispatch-derivative/. Discussion of this document takes place on the ipr-wg Working Group mailing list (mailto:[email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/ipr-wg/. Subscribe at https://www.ietf.org/mailman/listinfo/ipr-wg/. | |||||||||||||
| draft-sbriz-identity-trust-system-05.txt | ||||||||||||||
| Identity Trust System | ||||||||||||||
|
This document defines an *identity trust system*, which is a digital identity authentication system based on a symmetric exchange of authentication messages that does not require federation of authentication domains. The main components are: 1. *Symmetric authentication protocol* - A protocol for the mutual recognition of entities based on a symmetric exchange of authentication messages through the mediation of Identity Providers (IdPs). It builds on and extends the OAuth Authorization Framework RFC6749. 2. *Trustees network* - A IdPs network infrastructure that provides a secure environment for exchanging authentication messages. 3. *Custodian concept* - A special category of IdPs to protect physical identity and personal data. The generic IdP is called "*_trustee_*" and is only responsible for digital authentication, while the special IdP called "*_custodian_*" has the legal right to process the individual's real data and maintain the relationship with the digital identity. The *_custodian_* acts under the direct control of the legal authorities of the individual's country. | |||||||||||||
| draft-scalone-cfr-source-privacy-02.txt | ||||||||||||||
| Customer-Facing Relay (CFR): Enhancing Source Privacy in Encrypted Transport and CDN Scenarios | ||||||||||||||
|
Encrypted ClientHello (ECH) protects sensitive TLS ClientHello fields, including the Server Name Indication (SNI), from on-path observers. ECH does not, however, attempt to hide the client's network-layer source identity from the ECH client-facing server (CFS). In split-mode deployments, the CFS decrypts the ClientHelloInner in order to route the connection to the appropriate backend while also receiving the connection from the client's visible source address. This creates a distinct source-privacy problem. Where ECH service and content front-door infrastructure are concentrated, a relatively small number of providers can obtain a privileged vantage point from which a stable source address can be correlated with many encrypted destinations and with other service telemetry. Measurements over a corpus of approximately one million domains, together with an active- ECH validation subset, show substantial front-door concentration and motivate treating source privacy as a complement to destination privacy. This document describes the Customer-Facing Relay (CFR), a network- layer, access-side source-aliasing function. A CFR forwards encrypted TCP or UDP traffic without terminating TLS or QUIC and replaces the subscriber-visible source address with a shared or short-lived source alias. The document also examines the different privacy properties of IPv4 NAT/CGN and IPv6 source addressing and identifies requirements for privacy-preserving source mapping. | |||||||||||||
| draft-scerbacov-icnli-00.txt | ||||||||||||||
| The Infrastructure Contextual Natural Language Interface (ICNLI): An Open Protocol for Modular Proactive AI Cloud Operating Systems | ||||||||||||||
|
This document describes the Infrastructure Contextual Natural Language Interface (ICNLI), an open protocol that defines how an artificial intelligence (AI) agent operates as a first-class participant inside a real-world operational system. ICNLI specifies a hierarchical context model, request classification and a two-step confirmation pattern for state-changing operations, multi-step chain orchestration with read-before-write semantics, an anti-fabrication contract that binds narration to verifiable facts, a graduated safety layer, a modular extension contract, proactive-intelligence requirements, channel neutrality, and observability and audit primitives, organized into three cumulative conformance levels. The protocol is domain-agnostic, channel-neutral, and implementation- neutral; a compliant implementation MAY use any underlying foundation model. This Internet-Draft is a faithful rendering, for the IETF community, of the ICNLI Specification version 2.0.0 published by its author. It is an individual submission and a work in progress with an intended status of Informational. It does not represent IETF consensus, is not a standards-track document, and makes no claim of IETF adoption. | |||||||||||||
| draft-schemacommons-aaif-00.txt | ||||||||||||||
| Autonomous Agent Interchange Format (AAIF) | ||||||||||||||
|
The Autonomous Agent Interchange Format (AAIF) is an open, vendor- neutral specification for the portable definition of artificial intelligence agents. An AAIF document encapsulates an agent's identity, goal, system instructions, large language model (LLM) provider preferences and fallback routing, multi-agent orchestration topology (sequential pipeline, parallel swarm, dynamic routing, and mid-run handoff), tool catalogue (supporting function, MCP, HTTP, and OpenAPI protocols with structured authentication), memory configuration, runtime policy, OpenTelemetry telemetry settings, LLM- as-judge evaluation criteria, and compliance controls including data residency and human-in-the-loop approval. An agent defined in AAIF can be validated offline, committed to version control, and imported into any conforming runtime regardless of the original authoring environment. This document describes the AAIF data model, field semantics, conformance levels, capability negotiation protocol, and the companion Agent State checkpoint schema that enables cross-platform live migration of running agents. | |||||||||||||
| draft-schemacommons-acpm-00.txt | ||||||||||||||
| Agent Capability and Profile Model (ACPM) | ||||||||||||||
|
The Agent Capability and Profile Model (ACPM) is an open, vendor- neutral specification for describing what an artificial intelligence (AI) agent, the platform that runs it, a tool it calls, or the underlying large language model (LLM) actually offers, independent of how that subject is run or discovered. An ACPM document, called a capability profile, declares a subject's identity, a dot-namespaced list of supported capabilities together with a support level, an inventory of tool protocols, models, and memory backends, a trust and attestation posture, a cost structure, service-level commitments, structured delegation rules governing inbound and outbound work handoff, and a compliance posture. ACPM profiles are designed to cross-reference agent definitions and registry entries defined by other Schema Commons standards, and to be consumed by registries, marketplaces, and orchestrators that need to compare capabilities, gate on trust, and reason about cost and service levels without bespoke per-vendor parsing. This document describes the ACPM data model, field semantics, conformance levels, and the relationship of ACPM's trust and signature fields to actual verification, which ACPM deliberately does not itself perform. | |||||||||||||
| draft-schemacommons-areg-00.txt | ||||||||||||||
| Agent Registry (AREG) | ||||||||||||||
|
The Agent Registry (AREG) is an open, vendor-neutral specification for publishing, discovering, and resolving artificial intelligence (AI) agent definitions. An AREG registry entry is a lightweight metadata document that records where a specific version of an agent definition can be fetched, who published it, what version it is, and how consumers can verify its authenticity. AREG also defines a REST API that conforming registry servers implement to expose search, resolution, and publication endpoints to consumers and publishers. AREG is the discovery and registry layer of the Schema Commons agent stack. It is designed to compose with the Autonomous Agent Interchange Format (AAIF, SC-006), which defines the content of the agent definition document that an AREG entry points to, and with the Agent Capability and Profile Model (ACPM, SC-014), which provides richer capability, trust, cost, and service-level information that a registry entry can reference. Neither AAIF nor ACPM is required for a conforming AREG implementation. | |||||||||||||
| draft-schinazi-httpbis-ohttp-ext-key-config-00.txt | ||||||||||||||
| An Extensible Key Configuration Format for Oblivious HTTP | ||||||||||||||
|
Oblivious HTTP is a protocol for forwarding encrypted HTTP messages. This requires communicating the gateway's key configuration to clients. While a key configuration media type was defined for this purpose, it has some limitations such as the inability to convey key lifetimes and interoperability issues. This document defines a similar extensible key configuration format that addresses those issues. | |||||||||||||
| draft-schinazi-httpbis-ohttp-pfs-01.txt | ||||||||||||||
| A Perfect Forward Secure Extension to Oblivious HTTP | ||||||||||||||
|
Oblivious HTTP (OHTTP) is a protocol for forwarding encrypted HTTP messages. It does not provide Perfect Forward Secrecy (PFS). Chunked OHTTP expands OHTTP to be suitable for longer-lived streams, but still does not offer PFS. Combined, this is leading sensitive traffic to de deployed at scale without PFS. This document proposes a solution. | |||||||||||||
| draft-schinazi-masque-proxy-09.txt | ||||||||||||||
| The MASQUE Architecture | ||||||||||||||
|
MASQUE (Multiplexed Application Substrate over QUIC Encryption) is a set of protocols and extensions to HTTP that allow proxying all kinds of Internet traffic over HTTP. This document describes the architectural principles behind MASQUE, and the properties that MASQUE can provide. | |||||||||||||
| draft-schreiber-scim-ipsie-profile-00.txt | ||||||||||||||
| SCIM 2.0 IPSIE Profile | ||||||||||||||
|
This document defines a profile for SCIM 2.0 to meet the security and interoperability requirements for identity lifecycle management within enterprises. Within the context of SCIM, the profile establishes requirements for provisioning, account management, client authentication, and identity synchronization across three Account Lifecycle assurance levels: AL1 (User Deprovisioning), AL2 (User and Group Management), and AL3 (Role Management). | |||||||||||||
| draft-schrock-action-evidence-boundary-05.txt | ||||||||||||||
| The Action Evidence Boundary for Consequential Agent Effects | ||||||||||||||
|
Consequential agent actions can cross identity, transport, authorization, policy, and execution systems. Each system can produce a valid artifact while the executor still lacks a safe rule for joining the artifacts to the exact effect, consuming one-time authority, and handling an uncertain outcome. This document defines the Action Evidence Boundary (AEB), an executor-side processing model for that lifecycle. AEB requires native artifact verification, Canonical Action Identifier (CAID) matching, Authorization Evidence Chain (AEC) satisfaction, a separate local authorization decision, durable atomic consumption or reservation, invocation, closed effect outcomes, and authenticated reconciliation. It defines no receipt or token format, no policy language, no universal evidence taxonomy, and no new registry. Native workload credentials, message signatures, attested per-action tokens, permit records, authorization receipts, and status mechanisms retain their own semantics and verifiers. | |||||||||||||
| draft-schrock-action-remedy-receipts-00.txt | ||||||||||||||
| Action Remedy Receipts for Consequential Agent Effects | ||||||||||||||
|
Revocation cannot undo an effect that already occurred. A dispute does not authorize a refund, return, reversal, or other remedy. This document defines Action Remedy Receipts for recording a bounded dispute decision and a fresh compensating action without rewriting the original action or effect. Every remedy has its own operation identifier, CAID, action digest, authority, consequence owner, and execution result. Indeterminate outcomes remain fenced until authenticated reconciliation. | |||||||||||||
| draft-schrock-ae-challenge-07.txt | ||||||||||||||
| An Authorization Evidence Challenge for High-Risk Agent Actions | ||||||||||||||
|
When a relying party refuses a consequential agent action because authorization evidence is missing, stale, or unverifiable, the agent needs a machine-readable description of what remains necessary. This document defines a transport-neutral Authorization Evidence Challenge data model bound to the relying party's exact action. The challenge identifies outstanding evidence requirements, freshness and status constraints, acceptable presentation profiles, and retry state. It authorizes nothing, transfers no admission ownership, and provides no promise that a later request will execute. The document also defines an HTTP challenge-response carrier using 403 Forbidden and RFC 9457 Problem Details, and describes an informative gateway-handoff illustration for DMSC-style federation. The gateway illustration communicates evidence requirements; it does not solve conserved admission or double-admission across independently operated gateways. A challenge can synchronize corrected retries and amplify load. The core therefore defines optional retry timing with per-challenge jitter, and the HTTP carrier maps its lower bound to Retry-After. Retry timing controls presentation attempts only; it does not authorize the action or make an uncertain action safe to repeat. Single-use processing also places state on the refusal path. The core therefore requires bounded outstanding and replay state, fail- closed behavior when state cannot be claimed, and retention of live replay records until they are no longer security-relevant. Nonce claim and refusal-path capacity reservation are one atomic owner-side transition before native evidence verification, and a binding capacity refusal reveals no remaining evidence requirements. In a sharded replay domain, only the authoritative owner can classify a nonce as already claimed; inability to reach that owner is unavailability, not replay. | |||||||||||||
| draft-schrock-agent-operation-continuity-00.txt | ||||||||||||||
| Agent Operation Continuity Across Executor Replacement | ||||||||||||||
|
An agent executor can fail or be replaced after a consequential provider request may have crossed an effect boundary but before the outcome is known. Native authorization, succession, evidence- boundary, and bounded-capability mechanisms address parts of this interval, but they do not by themselves define how a replacement executor preserves the same provider operation and its unresolved evidence. This document defines a composition profile for one authoritative coordination domain. The profile preserves stable operation- occurrence identity, immutable provider bindings, authority accounting, uncertain evidence, and stale-executor fences across replacement. It defines no new receipt, identity, authority, provider, or ledger-migration format, and it does not require any particular evidence envelope. | |||||||||||||
| draft-schrock-agent-qualification-statements-00.txt | ||||||||||||||
| Portable Agent Qualification Statements for Consequential Actions | ||||||||||||||
|
Agent evaluations report what happened in a test environment. They do not, by themselves, establish that a measured candidate satisfies a relying party's policy, remains current, matches the runtime candidate, or is authorized to perform a consequential action. This document defines a portable Qualification Statement that binds a candidate, complete evaluation campaign, qualification policy, assignment, and status. It preserves three separate claims: observation, qualification, and authorization. A relying party can accept a current qualification as evidence at runtime, but MUST make a separate exact-action authorization and admission decision. | |||||||||||||
| draft-schrock-canonical-action-identifier-02.txt | ||||||||||||||
| The Canonical Action Identifier (CAID) | ||||||||||||||
|
Authorization, delegation, execution, and audit artifacts often identify an action using format-local content and digests. Those digests are not directly comparable when the formats select or encode material action fields differently. This document defines the Canonical Action IDentifier (CAID): a typed action object, a canonicalization and digest suite, a compact identifier string, and immutable action-type definitions with required material fields. It also defines an Action-Mapping Profile for projecting independently verified native artifacts into a common action type, with the closed results EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, and INDETERMINATE. CAID carries no trust semantics. It does not establish identity, authority, authorization, execution, safety, or legal reliance. | |||||||||||||
| draft-schrock-emilia-eye-00.txt | ||||||||||||||
| Verifiable,Scope-Bound Advisories for Authorization Posture (EMILIA Eye) | ||||||||||||||
|
This document defines the EMILIA Eye advisory: a scope-bound statement that an authorization posture for a named scope has changed (designed to be signed and offline-verifiable; the signing layer is specified here but is not yet present in the reference implementation, see Section 13.6), carrying a scope-binding hash that prevents the advisory from being replayed or re-targeted to a different scope. An Eye advisory expresses an observation-derived posture (clear, caution, elevated, or review_required) and a recommended action (none, log, step_up_auth, require_signoff, or escalate). The central safety invariant of this document is normative: an advisory MUST NEVER be the sole gate on an action. A signal may only TIGHTEN posture - it may cause an enforcement point to demand stronger authentication, human signoff, or escalation - but it can never itself constitute the authorization. Eye warns; an enforcement point verifies; an accountable human owns the decision. This work specifies the verifiability, scope-binding, and fail-safe advisory semantics that signal-transport frameworks leave undefined. It is a COMPOSABLE PROFILE: Eye advisories are carried as Security Event Token [RFC8417] payloads and MAY be transported over the OpenID Shared Signals Framework with Continuous Access Evaluation Profile (CAEP) events. It is complementary to, not a replacement for, SSF/ CAEP (which define signal shape and transport, not verifiable bound fail-safe advisory semantics), and it composes with the EP authorization receipt ([I-D.schrock-ep-authorization-receipts]), which remains the artifact that actually authorizes an action. This document is experimental. | |||||||||||||
| draft-schrock-ep-architecture-03.txt | ||||||||||||||
| The EMILIA Protocol: An Evidence Architecture for Consequential Agent Actions | ||||||||||||||
|
Consequential agent actions can cross operator and administrative boundaries. The party that later decides whether to rely on an action record may not have participated in the interaction and may not trust either operator. This document describes an evidence architecture for that case. It separates transport and workload identity, delegation and policy, material action identity, authorization evidence, evidence satisfaction, local authorization, durable consumption or reservation, effect invocation, outcome evidence, revocation, and preservation. The architecture composes the Canonical Action Identifier (CAID), Authorization Evidence Chain (AEC), and Action Evidence Boundary (AEB) with optional staged-approval and consequence-control profiles. It does not define a universal token, policy language, execution engine, settlement network, or distributed consensus system. A valid signature, a current credential, a satisfied evidence requirement, and an observed effect remain different facts. | |||||||||||||
| draft-schrock-ep-authority-introduction-03.txt | ||||||||||||||
| Authority Documents and Scoped Authority for Agent-Action Evidence | ||||||||||||||
|
Signature verification answers whether a key produced an artifact. It does not answer why a relying party accepts that key, or whether the key holder had authority for the action. This document specifies two composable artifacts. An Authority Document introduces and rotates an organization's evidence-issuing keys through a signed, hash-chained sequence. A Scoped Authority Proof records the authority held by a subject at a registry snapshot, including role, action scope, material limits, policy binding, validity, and revocation status. A relying party evaluates both artifacts under its own pinned trust inputs and policy. The design does not make a self-presented key authoritative, does not turn log inclusion or domain control into automatic trust, and does not equate a valid signature with permission to act. It also defines a source- resolution boundary: signing a statement does not give its underlying source data finer freshness or precision than that source actually provides. | |||||||||||||
| draft-schrock-ep-authorization-evidence-chain-06.txt | ||||||||||||||
| Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC) | ||||||||||||||
|
Consequential agent actions can produce heterogeneous identity, delegation, policy, permit, approval, transparency, capability, and execution artifacts. Each artifact can verify under its own specification while still referring to a different action, filling a different evidentiary role, or failing a relying party's freshness, status, or inter-artifact binding requirement. This document defines the Authorization Evidence Chain (EP-AEC): a transport-agnostic composition object and a fail-closed evaluation algorithm that preserves native verification, establishes exact material-action matching, and evaluates a relying-party-pinned evidence requirement. AEC produces SATISFIED or UNSATISFIED and a replayable evaluation record. SATISFIED means only that the presented evidence filled the relying party's named evidence requirement at the stated verification time. It is not a universal authorization decision, a policy language for the protected application, or proof of execution or outcome. The executor makes the separate local AUTHORIZED decision and controls consumption, invocation, and effect handling. Qualification evidence can fill a named evidence role but cannot authorize an action by itself. AEC introduces no new component receipt type and does not replace any native verifier. | |||||||||||||
| draft-schrock-ep-authorization-receipts-13.txt | ||||||||||||||
| Authorization Receipts for High-Risk Agent Actions | ||||||||||||||
|
This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. | |||||||||||||
| draft-schrock-ep-bounded-capability-receipts-06.txt | ||||||||||||||
| Bounded Capability Receipts and Durable Spend Control for Agent Actions | ||||||||||||||
|
Agents sometimes need bounded authority to perform more than one consequential action without obtaining a new human approval for every operation. A signed token alone cannot enforce a shared budget across replicas, survive retries safely, or distinguish an operation that never crossed an effect boundary from one whose outcome is unknown. This document defines a bounded capability receipt and a durable reserve-admit-reconcile protocol. The receipt binds an issuance authorization, a closed action scope, a budget with explicit units, a holder proof, an expiry, and any parent capability. The state protocol atomically refuses overspend and operation-key replay, fences concurrent owners, and charges an indeterminate operation when an external effect may have occurred. Delegation transfers rather than copies authority: all direct child allocations are funded by committed parent operations before child registration, and their aggregate cannot exceed the parent balance within one authoritative atomic state domain. It also defines narrowing-only delegation, explicit revocation inheritance for delegated authority, an optional admission-control epoch that can freeze new consequence admission, and evidence interfaces. It does not make a bearer token into human approval, does not provide cross-domain or offline global double- spend prevention, and does not claim that an authorized action was safe, lawful, or successfully executed. | |||||||||||||
| draft-schrock-ep-bounded-execution-program-00.txt | ||||||||||||||
| Bounded Execution Programs for Consequential Agent Actions | ||||||||||||||
|
An authorization for one action does not by itself authorize an open- ended agent plan. This document defines an Experimental profile for a signed, finite, versioned directed acyclic graph of consequential action occurrences. The program binds a total retained-history ceiling. Each node binds an exact action or a pinned action-matching profile, an action- specific Trust Program, outcome-specific dependencies, an occurrence ceiling, and fixed charges against aggregate attempt budgets. A conforming program-aware admission store evaluates reachability and budgets in the same linearizable transaction domain as the ordinary one-time execution right. It uses store-owned authorizer trust roots, clock, authenticated profile-match verification, and current program status; seals a deterministic execution-program resource into the AdmissionSnapshot; and fences the program's independent authorization digest against ordinary-path admission. The profile does not establish that natural-language intent was understood, that a plan is safe or lawful, that provider or effect evidence is true, or that every mutation path was mediated. | |||||||||||||
| draft-schrock-ep-evidence-record-01.txt | ||||||||||||||
| Long-Term,Crypto-Agile Preservation of Authorization Evidence (EP-EVIDENCE-RECORD) | ||||||||||||||
|
Regulations increasingly require that records of who authorized a high-risk action be retained for years (e.g. five years under DORA, six under HIPAA and SEC 17a-4). Any fixed signature or hash algorithm used to protect such a record weakens over time; a receipt signed today with Ed25519 over SHA-256 may be cryptographically attackable before its retention period ends. This document defines EP-EVIDENCE-RECORD, an OPTIONAL profile that preserves the verifiability of EMILIA Protocol authorization receipts (and other artifacts) across algorithm aging, using a renewal chain in the style of the Evidence Record Syntax [RFC4998]. Each renewal time-attests the entire prior renewal under a fresh, stronger algorithm before the older one is broken, so an unbroken chain links the original artifact to the most recent renewal. The record is offline- verifiable, fail- closed, and maintained as cross-language conformance vectors that three reference verifiers (JavaScript, Python, Go) are required to agree on. Those verifiers live in one repository, a cross-language consistency check, not clean-room independent implementations; independent implementations remain future interoperability evidence. This revision additionally defines two OPTIONAL companion profiles, EP-WITNESS-v1 witness cosignatures over a transparency log's committed checkpoint head and an independent RFC 3161 time attestation verified offline against a relying-party-pinned time- stamping authority key; both are implemented today in the JavaScript reference verifier only. | |||||||||||||
| draft-schrock-ep-outcome-binding-00.txt | ||||||||||||||
| Outcome Binding for Authorized Actions and Independently Observed Effects | ||||||||||||||
|
Authorization proves what action was permitted; it does not prove what happened after execution. An executor-signed result improves attribution but remains a claim by the party that acted. This document specifies a source-routed Outcome Binding profile. Signed predicted effects identify the source role and source class required to evaluate each predicate. Executors, systems of record, and independent observers sign closed observation objects bound to the same authorization, action digest, Canonical Action Identifier, consumption nonce, operation, facility, and observation window. A deterministic verifier separates evidence availability from comparison: missing or unauthenticated required sources yield an indeterminate lifecycle state; authentic observations yield the closed comparison result in_bounds, divergent, or incomparable. The profile improves consequence reconciliation without claiming physical truth, sensor correctness, or legal finality. | |||||||||||||
| draft-schrock-ep-presentation-binding-01.txt | ||||||||||||||
| Binding Deterministic Rendering and Display Attestations to Human-Authorization Receipts | ||||||||||||||
|
A human-authorization receipt proves an enrolled key produced a user- verified signature over a digest that commits to an exact action. It does not prove the signing surface DISPLAYED that action honestly. If a signing interface shows a benign summary while committing a different action, the resulting receipt is laundered authority: cryptographically valid and semantically false, which is worse than no receipt at all. This is the presentation attack, and it is the deepest unsolved problem in authorization evidence, because a signature cannot attest to pixels. This document narrows the gap with two additive, offline-checkable pieces that touch no existing receipt format: a DETERMINISTIC RENDERER, a pure function from the canonical action to a byte-identical human-readable rendering, so a verifier RE-DERIVES the rendering from the signed bytes and rejects a claimed rendering that does not match; and a DISPLAY ATTESTATION, a signed claim by the signing client binding the rendering it showed to the action it committed. Neither eliminates the presentation attack (nothing purely digital can), but together they let a verifier check the claimed rendering against the signed action under relying-party- selected client trust inputs. They make the residual risk explicit rather than hidden. | |||||||||||||
| draft-schrock-ep-quorum-04.txt | ||||||||||||||
| Multi-Party Quorum Authorization for High-Risk Agent Actions (EP-QUORUM) | ||||||||||||||
|
This document defines a multi-party approval predicate over action- bound human signoffs: valid signatures, admitted roles, distinct approvers and keys, threshold, and an optional ordered trail. The relying party pins the governing policy and approver directory independently. Passing the predicate is approval evidence, not a complete authorization decision, proof of execution, or proof of unused authority. This revision repairs the strong ordered profile. A successor signs a digest of the completed predecessor signoff, including its signature, rather than a precomputable context. The versioned profile establishes causal dependence on a completed prior proof under the cryptographic assumptions; it does not establish trusted wall-clock time or human comprehension. Legacy context-only chains cannot satisfy it. JavaScript, Python, and Go reference verifiers share a corpus in one repository. Agreement is a same-team consistency check, not independent interoperability evidence or a formal proof of the new construction. | |||||||||||||
| draft-schrock-ep-reliance-agreement-00.txt | ||||||||||||||
| Reliance Agreements: Signed Liability Terms Conditioned on Authorization-Evidence Sufficiency | ||||||||||||||
|
This document defines EP-RELIANCE-AGREEMENT-v1, a signed, machine- readable statement of terms conditioned on a specific relying-party evidence profile, and EP-RELIANCE-EVENT-v1, a signed per-action record joining one action, one reliance result, and one agreement. The agreement references the evidence condition by digest rather than restating or weakening it. Every required party signs the same canonical bytes, and monetary amounts are represented as decimal strings. Verification establishes signatures, content integrity, scope, time, and digest bindings. It does not authorize an action, re-evaluate the evidence packet, establish legal enforceability, issue insurance, determine coverage, allocate fault, prove solvency, reserve funds, or compel payment. Those decisions remain with the relying party and the applicable prose agreement, law, and dispute forum. | |||||||||||||
| draft-schrock-ep-revocation-statement-01.txt | ||||||||||||||
| Portable Revocation Statements for Action-Bound Authorization Artifacts | ||||||||||||||
|
Signed authorization artifacts for agent actions (receipts, commits, delegations) are being defined faster than the means to retract them. Many deployed systems use live status services, revocation lists, or issuer datastores. This document defines a complementary portable form for action-bound authorization artifacts: a signed, offline- verifiable claim that a named logical target, addressed by identifier and action commitment, is revoked. Verification is fail-closed and evaluates a fixed set of checks: version, closed object structure, target binding, a revoker key pinned by the verifier and, for newly emitted artifacts, bound to a full digest-derived key identifier (a self-asserted key confers nothing), the presence of a strict revocation instant that has taken effect by the verifier's decision time, and an independently recomputed signature. The statement proves that a named, pinned revoker revoked this specific target. It does not prove that every relying party saw it, and offline verification cannot prove the absence of a revocation that was not presented. A terminal revocation never ages out; current non- revocation requires separate authenticated, policy-fresh status evidence. A Trust Program profile binds revocation to the complete execution claim, and requires revocation-versus-claim to be resolved atomically; a revocation learned after a claim never rewrites an effect that may already have occurred. | |||||||||||||
| draft-schrock-human-authorization-binding-00.txt | ||||||||||||||
| Binding Named-Human Authorization Evidence into Agent-Action Records | ||||||||||||||
|
A recurring pattern spans the agent-action record formats now in development: a record about an agent's action reserves a place for "the human authorization" — an approver disposition, an authority context, a human-override field, an actor slot, a signed grant, an approval reference — and leaves its semantics undefined. Each format, reasonably, does not want to specify human-authorization evidence itself; none, so far, says what filling the slot means. This document defines that one thing, host-agnostically: how any record binds named-human authorization evidence, either BY REFERENCE (a content digest of the authorization artifact's canonical bytes) or EMBEDDED (a compact, self-describing claim carrying named approvals and optional distinct-human quorum semantics), with five requirements that make the binding mean the same thing in every host: digest grounding, action agreement, verified-versus-accepted discipline, fail-closed absence, and embedded/referenced consistency. The SCITT signed-statement host family is expressed concretely (digest selection, and the observed-absence statement that is the only way absence of authorization becomes evidence); an informative appendix maps the binding onto the reserved slots of eleven current documents. This document defines no new authorization format: the referenced evidence verifies under its own specification. | |||||||||||||
| draft-schrock-kintzele-grid-curtailment-00.txt | ||||||||||||||
| GRACE: Evidence-Bound Grid Curtailment Admission,Observation,and Single-Use Settlement | ||||||||||||||
|
This document defines GRACE, an application profile for one bounded grid.curtailment action. The profile binds an exact action to a finite participation envelope, distinct human approvals when required, one-attempt executor admission, an authenticated actuator acknowledgment, separately authenticated meter observations, an Action State Signed Statement, and one-time admission to a settlement effect. Missing or ambiguous post-invocation evidence is preserved as indeterminate and cannot authorize blind retry. GRACE verifies signed inputs and deterministic computations. It does not establish physical meter truth, baseline correctness, tariff eligibility, actual payment, complete mediation, or a physical grid deployment. An optional hybrid artifact-signature profile combines Ed25519 with ML-DSA-65 and requires both signatures to verify. | |||||||||||||
| draft-schrock-model-to-matter-04.txt | ||||||||||||||
| Model-to-Matter: Authorization and Outcome Evidence for Model-Directed Physical Execution | ||||||||||||||
|
Advanced models can propose operations that produce physical effects. Model-to-Matter defines an executor-owned profile that composes model, safety, institutional, domain, screening, human, and physical- state attestation evidence over one canonical action before single- use execution. This revision also profiles post-execution Outcome Binding. An executor effect statement remains one source claim; required independent observers sign separately bound observations. Missing outcome evidence is indeterminate, not success or failure. The profile standardizes evidence custody and reconciliation; it does not perform screening, determine scientific safety, certify a facility, or establish physical truth. | |||||||||||||
| draft-schur-bcccop-uri-scheme-00.txt | ||||||||||||||
| The "" URI Scheme for Biometric-First Communication | ||||||||||||||
|
This document registers the "⚮" (U+26AE, DIVORCE SYMBOL) Uniform Resource Identifier (URI) scheme for the Biometric-First Communication Protocol (BCCCOP). The scheme enables privacy-first, biometric-anchored addressing of resources and invocation of peer-to- peer operations across ultrasonic, BLE, and Wi-Fi transports. This document follows the URI scheme registration guidelines of RFC 7595. | |||||||||||||
| draft-schwenkschuster-wimse-trust-domain-discovery-00.txt | ||||||||||||||
| WIMSE Trust Domain Discovery | ||||||||||||||
|
The WIMSE architecture scopes workload identifiers to a trust domain. To validate a workload identity credential, a relying party must securely obtain the cryptographic trust anchors associated with the credential's trust domain. The WIMSE architecture requires that this mapping between a trust domain and its trust anchors is obtained through a secure mechanism, but leaves that mechanism undefined. This document defines such a mechanism for open environments in which no prior trust relationship exists between the relying party and the trust domain. It specifies the WIMSE Trust Bundle, a document that conveys the trust anchors of a trust domain for both JWT-based and X.509-based workload identity credentials, and a discovery mechanism based on a well-known HTTPS endpoint that allows a relying party to resolve a trust domain name to its trust bundle on demand. | |||||||||||||
| draft-scrm-aiproto-usecases-05.txt | ||||||||||||||
| Taxonomy for Agentic AI Use Cases | ||||||||||||||
|
Agentic AI systems rely on large language models to plan and execute multi-step tasks by interacting with tools and collaborating with other agents, creating new demands on Internet protocols for interoperability, scalability, and safe operation across administrative domains. This document defines a taxonomy for classifying Agentic AI use cases according to the functional protocol domains they exercise, such as transport, security and trust, discovery, identity, coordination and orchestration, data and context management, and operations and management. The taxonomy is intended to give the IETF a structured vocabulary for describing and comparing use cases, for identifying which protocol areas require standardization attention, and for mapping use case requirements to relevant IETF working groups. | |||||||||||||
| draft-secroot-ooda-http-04.txt | ||||||||||||||
| Enforcement-Action HTTP Header Field | ||||||||||||||
|
This document defines the Enforcement-Action HTTP response header field. The field carries an advisory selected-action token from an application to cooperating intermediaries within a trusted boundary. It is advisory and safe to ignore. Recipients apply their local policy in response to the signal. This specification standardizes the field name, syntax, response-path processing model, and safe-to-ignore behavior. It does not standardize the operational meaning, target, duration, or enforcement effect of individual action tokens or parameters, and it does not modify HTTP semantics, TLS, QUIC, or the caching rules of [RFC9111]. | |||||||||||||
| draft-seemann-httpbis-reset-stream-at-00.txt | ||||||||||||||
| Using QUIC Stream Resets with Partial Delivery in HTTP/3 | ||||||||||||||
|
QUIC stream resets do not guarantee delivery of stream data sent before the reset. This is a problem for HTTP/3 when the correct protocol outcome is an abrupt stream termination, but the sender still has a bounded prefix worth delivering, such as response headers, a short diagnostic response body, or a partial response received from an upstream host. RESET_STREAM_AT provides reliable delivery of that prefix and is already used by WebTransport over HTTP/3 when resetting streams. The same mechanism also fits HTTP/3 CONNECT tunnels, intermediary failures after response commitment, malformed decoded HTTP messages, and requests rejected before application processing. | |||||||||||||
| draft-seemann-masque-connect-udp-rendezvous-00.txt | ||||||||||||||
| UDP Rendezvous over HTTP | ||||||||||||||
|
This document defines an Extended CONNECT protocol for relaying UDP between two clients authenticated by the same proxy. A Listener registers with the proxy, and a Client uses the resulting Rendezvous ID to connect to it. No public UDP address is allocated. | |||||||||||||
| draft-seemann-quic-ppdplpmtud-00.txt | ||||||||||||||
| Parallel Probing DPLPMTUD for QUIC | ||||||||||||||
|
QUIC endpoints commonly use 1200-byte datagrams during the handshake and only start Path MTU Discovery afterward. This means that just- established QUIC connections cannot immediately use larger datagrams, which is especially limiting for MASQUE protocols and for WebTransport. This document defines Parallel Probing DPLPMTUD (PPDPLPMTUD), which probes several packet sizes early during the QUIC handshake, so a larger discovered size is usable during later handshake phases and especially after handshake completion. The same discovery process is also used for path migration. | |||||||||||||
| draft-seethiraju-dawn-dan-00.txt | ||||||||||||||
| DNS-Based Agent Naming (DAN): AIDISCA and AIINDEX Resource Records for AI Agent Discovery | ||||||||||||||
|
The agentic AI ecosystem includes many different technologies and operations. One important aspect is the ability to establish connections between AI agents. In single-platform approaches, the processes and metadata with which AI agents discover, locate, and connect to each other are typically managed by their common platform. This document describes an inter-domain mechanism to enable AI agents to locate and connect to each other using necessary metadata and secure DNS associations, in a similar fashion to the way that DNS- Based Authentication of Named Entities (DANE), RFC6698, does for Transport Layer Security. This is accomplished through two new Resource Record (RR) types: AIDISCA and AIINDEX. | |||||||||||||
| draft-selander-lake-cred-hash-01.txt | ||||||||||||||
| Hashing Authentication Credentials in EDHOC | ||||||||||||||
|
This document defines a COSE header parameter which signals that an authentication credential is replaced by the hash of the authentication credential in the protocol message computations. This further relaxes the need for transporting authentication credentials in EDHOC, which reduces protocol message sizes and improves performance in constrained networks. | |||||||||||||
| draft-selvaraj-portableweb-format-01.txt | ||||||||||||||
| Portable Web Content Format (PortableWeb): Container and Manifest Specification | ||||||||||||||
|
This document defines the Portable Web Content Format (PortableWeb), a file format for packaging interactive web content — including HTML, CSS, JavaScript, and associated media — into a single self-contained, portable bundle. A PortableWeb bundle (.pweb file) can be saved, shared, and rendered by a compatible viewer application on any platform, entirely offline, without a web server, without association with a Web origin, and without being confined to a web browser. This specification defines the container format and manifest schema for PortableWeb bundles at version 0.1. Companion specifications covering the runtime sandbox, storage model, signing, and inter- bundle communication are forthcoming. | |||||||||||||
| draft-seralathan-radext-persistent-devid-01.txt | ||||||||||||||
| RADIUS Chargeable-Device-Identity and Persistent Device Identification in MAC-Randomized Environments | ||||||||||||||
|
This document defines a Chargeable-Device-Identity (CDI) -- a privacy- preserving, rotating device correlator carried in existing RADIUS Class attributes -- that enables Network Access Control (NAC) systems to maintain device session correlation across Media Access Control (MAC) address changes. Modern operating systems randomize MAC addresses by default, disrupting RADIUS-based authentication, authorization, and accounting workflows that rely on the Calling- Station-Id attribute as a persistent device identifier. CDI is modeled after the Chargeable-User-Identity (CUI) defined in RFC 4372, providing an analogous device-level correlator with explicit privacy controls: epoch-based rotation limits long-term tracking, HMAC construction prevents identifier reversal by intermediate systems, and transport within the Class attribute ensures immediate deployability on existing infrastructure. This document additionally defines a new RADIUS attribute, Persistent-Device-Id, for deployments that require explicit device identity semantics beyond what the opaque Class attribute can provide. The Class-based CDI mechanism is the RECOMMENDED approach for immediate deployment; the dedicated attribute provides a migration path for future interoperability. | |||||||||||||
| draft-sergeev-claim-boundaries-00.txt | ||||||||||||||
| Claim Boundaries for Execution Evidence | ||||||||||||||
|
Systems that act in the world produce logs, receipts, approvals, traces, attestations, provenance statements, and transparency records. These artifacts are routinely offered as evidence that an action was authorized, performed, or completed. This document states a discipline for bounding such claims: the strength of an execution- related claim is limited by what the available evidence actually observed and by the control and observation topology at the boundary that produced it. Message formats, signature validity, receipt validity, and registration do not create observation or independence that did not exist. The control-topology test was prompted by a scenario Stephen Farrell posed in the IETF agent-protocol discussion of July 2026: one party creates another and may be able to act in its name. The tension is general, since no message format can supply the independent enforcement or observation dependencies required by a prevention or adversary-resistant detection-coverage guarantee, and the scenario is worked through in an appendix. The document defines no protocol, no record format, and no registry. It collects non- inference rules, a control-topology test for prevention and detection claims, a worked example, and reporting distinctions for evidence that does not support the claim asserted over it. | |||||||||||||
| draft-sergeev-wexp-core-01.txt | ||||||||||||||
| The Witnessed Execution Protocol (WEXP): Core Specification | ||||||||||||||
|
The Witnessed Execution Protocol (WEXP) Core defines carrier-neutral appraisal semantics for execution-related evidence. It defines four distinct content bases, two independent evidence qualifiers, the Boundary Ceiling, exact-claim support, deterministic accept, downgrade, and reject verdicts, composition without inflation, and a normalized interface between evidence-carrying profiles and appraisers. WEXP Core does not define a record serialization, signature envelope, action identifier, authorization model, or evidence-artifact schema. A companion Native Record profile can encode the normalized inputs defined here, and other carriers can do so without adopting that record format. | |||||||||||||
| draft-serra-mcp-discovery-uri-04.txt | ||||||||||||||
| The "mcp" URI Scheme and MCP Server Discovery Mechanism | ||||||||||||||
|
The Model Context Protocol (MCP) defines a standard interface for AI agents to connect to external tools and services. However, no standard mechanism exists for an AI agent to autonomously discover which web domains expose an MCP server. This document defines: (1) the "mcp" URI scheme, a machine-to-machine identifier for publicly reachable MCP servers; (2) a two-mode discovery mechanism: a well-known URI (/.well-known/mcp-server) for universal compatibility, and a DNS TXT record format for DNS-native fast discovery; (3) an optional manifest integrity mechanism using JSON Web Signatures (JWS, [RFC7515]) with keys published via DNS; (4) a security capability negotiation mechanism through which the manifest declares trust class, authentication requirements, compliance frameworks, and logging policy before connection. This specification does not define the MCP protocol itself, nor authentication between agent and server. Those are covered by the MCP specification and OAuth 2.1 respectively. | |||||||||||||
| draft-sfc-container-format-01.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-sfluhrer-cfrg-ml-kem-security-considerations-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sfluhrer-ssh-mldsa-08.txt | ||||||||||||||
| SSH Support of ML-DSA | ||||||||||||||
|
This document describes the use of the ML-DSA digital signature algorithms in the Secure Shell (SSH) protocol. Accordingly, this RFC updates RFC 4253. | |||||||||||||
| draft-sgcp-state-graph-cryptographic-protocol-01.txt | ||||||||||||||
| State Graph Cryptographic Protocol (SGCP) | ||||||||||||||
|
This document specifies the State Graph Cryptographic Protocol (SGCP), a communication-security framework in which a client and server establish a cryptographically protected session and maintain a synchronized state graph throughout the lifetime of the communication session. SGCP combines device identity, port context, socket context, session identity, ECDH-based shared-secret establishment, cryptographic key derivation, epochs, packet sequence numbers, authenticated state transitions, state-dependent packet transformation, replay protection, continuous context verification, controlled reauthentication, and session recovery. The central principle is that both endpoints independently derive the same cryptographic state from a common authenticated session secret and deterministic state information. The state graph defines which communication states are valid and which transitions are permitted. This document also illustrates the protocol with a worked example of a full-duplex binary media file transfer (an MP3 audio file) showing the complete packet-level exchange. | |||||||||||||
| draft-shang-agent-network-admission-01.txt | ||||||||||||||
| Use Cases and Requirements for Network Admission of AI Agent Instances | ||||||||||||||
|
Artificial intelligence (AI) agents increasingly access enterprise resources, external models, tools, and other agents through managed networks. Application-layer authentication can authenticate an agent to a cooperating service, but it cannot by itself provide complete network admission control. In particular, application proofs are normally verified only after network reachability exists, cannot be consumed consistently by heterogeneous or legacy services, and do not reliably identify which Agent Instance originated traffic when multiple Agents share one host, IP address, or egress gateway. This document describes operational use cases, the resulting problem statement, and requirements for network admission of AI Agent Instances. It focuses on establishing a verifiable and time-bounded binding among an Agent Instance, its credential key, optional runtime evidence, and a Network Context on which the network can enforce reachability policy. This document does not define a new Agent-ID format, authentication protocol, OAuth grant, or routing extension. | |||||||||||||
| draft-shang-campus-agent-scope-down-01.txt | ||||||||||||||
| Campus Agent Identification and Scope-Down Access Control | ||||||||||||||
|
AI agents operating in enterprise campus networks execute user- delegated Tasks by invoking multiple tools and services, often without continuous user supervision. Traditional authorization models assume stable applications and human-driven interactions, creating a mismatch when applied to autonomous agents that can chain actions across heterogeneous systems. Campus environments also contain heterogeneous and legacy services across diverse protocols, making per-service agent-aware authorization difficult to deploy consistently. Similar problems can also appear in residential access networks where home AI agents, smart-home hubs, and personal devices share a subscriber line and are connected through a broadband network gateway (BNG). This document describes the problem space for campus agent access control and argues that agents require task-bound privilege reduction ("scope-down") and that enforcement can be provided by in-path network devices in order to preserve compatibility with existing systems. It also describes a home network and BNG use case where the access provider or home gateway can provide a coarse but useful network-level boundary for agent traffic. | |||||||||||||
| draft-sharif-aeba-01.txt | ||||||||||||||
| Agent Event Behaviour Analysis (AEBA): A Framework for Behavioural Security Monitoring of Autonomous AI Agents | ||||||||||||||
|
This document specifies Agent Event Behaviour Analysis (AEBA), a framework for collecting, signing, exchanging, and analysing behavioural events produced by autonomous AI agents. AEBA is the agent-domain equivalent of User and Entity Behaviour Analytics (UEBA) as commonly deployed in enterprise Security Operations Centres. It defines a canonical event schema, signature binding to agent identity, baseline and peer-group exchange protocols, deviation signalling, detection rule structure, revocation mechanisms, and interoperability bindings for existing Security Information and Event Management (SIEM) event formats (syslog, CEF, LEEF). The framework is designed to compose with existing cryptographic primitives for agent identity, payment, and transport security, and to support cross-framework deployments in which agents produced by different runtimes must share a common behavioural observability surface. | |||||||||||||
| draft-sharif-agent-audit-trail-04.txt | ||||||||||||||
| Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems | ||||||||||||||
|
This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation. The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems, whose application dates were staged into 2027-2028 by Regulation (EU) 2026/1744. It also maps informatively to SOC 2 Trust Services Criteria, ISO/IEC 42001, the draft ISO/IEC 24970 and prEN 18229-1 logging standards, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing, content fingerprinting, and tombstone-based deletion compatible with GDPR Article 17. The -01 revision added pre-execution recording requirements, recording independence, deny reason codes, replay protection, external timestamp anchoring, and content fingerprinting based on feedback from independent implementers. The -02 revision added a Decision Reproducibility section (Section 13) that distinguishes record reproducibility, available for any model, from decision reproducibility, available only for open-weight models executed at temperature zero in an attested environment, and defines the associated record fields. The -03 revision added the Attestation Closure requirement (Section 13.6): the digests recorded for decision reproducibility MUST cover the complete computational closure of the inference function -- model weights, tokenizer, chat template, inference engine build, decoding configuration, and numeric environment -- together with new record fields (tokenizer_digest, chat_template_digest, engine_build_digest) and a minimal-change threat analysis (Section 13.7) showing that any component left outside the attested set is a forgery channel. This revision (-04) adds algorithm agility for post-quantum signatures (ML-DSA-65, FIPS 204) alongside ECDSA P-256; a key identifier (signer_kid, RFC 7638) that resolves which principal signed an independently recorded record; a trust-level assignment integrity requirement (Section 5.3) so that downgrading a consequential action is an attributable event rather than silent suppression; and OPTIONAL Merkle batch anchoring (Section 6.4) using the RFC 6962 construction for compact inclusion proofs at high throughput. All -04 additions are OPTIONAL to produce, and -04 verifiers stay backward compatible with -03: a -04 verifier accepts -03 records, and the new signing metadata is required only in records that carry a signature. | |||||||||||||
| draft-sharif-agent-identity-framework-01.txt | ||||||||||||||
| Agent Identity Framework: Trust and Identity for Autonomous AI Agents | ||||||||||||||
|
Autonomous artificial intelligence (AI) agents are increasingly performing actions that were previously the exclusive domain of authenticated human users: initiating financial transactions, querying regulated data, invoking external tools, and coordinating with other agents. Internet protocols designed for human-operated clients lack primitives to answer three fundamental questions about any autonomous action: which agent performed it, whether the agent was authorized to perform it, and whether the resulting evidence is independently verifiable. This document defines a framework for agent identity and trust enforcement on the Internet. It enumerates the gaps between current Internet standards and the requirements of autonomous agent systems, introduces a five-layer model (identity, authorization, attestation, evidence, trust) that separates concerns that are currently conflated, and outlines mechanisms to close specific gaps. The framework is intended to guide future Standards Track work and to provide a common vocabulary for researchers, implementers, and regulators. This document is informational. It does not define a wire protocol. It references existing Internet-Drafts and specifications that instantiate individual mechanisms within the framework. | |||||||||||||
| draft-sharif-agent-payment-trust-01.txt | ||||||||||||||
| Trust Scoring and Identity Verification for Autonomous AI Agent Payment Transactions | ||||||||||||||
|
This document specifies a protocol for trust scoring, identity verification, and spend limit enforcement for autonomous AI agents that initiate financial transactions. As AI agents gain the capability to make payments via protocols such as the Machine Payments Protocol (MPP), a standardised mechanism is needed to verify agent identity, assess trustworthiness, and enforce financial limits based on behavioural history. The protocol defines a five-dimension trust scoring model, per- agent cryptographic identity using ECDSA P-256 key pairs, challenge-response identity verification, spend limit tiers derived from trust scores, anomaly detection for financial behaviour, and a public trust query API for third-party platforms. This specification complements draft-sharif-mcps-secure-mcp, which provides message-level cryptographic security for the Model Context Protocol (MCP). Together, the two specifications address protocol security (MCPS) and financial trust (this document) for the AI agent economy. | |||||||||||||
| draft-sharif-agent-transport-protocol-01.txt | ||||||||||||||
| Agent Transport Protocol: Asynchronous Store-and-Forward Messaging for Autonomous AI Agents | ||||||||||||||
|
This document specifies the Agent Transport Protocol (ATP), an asynchronous store-and-forward messaging protocol for autonomous AI agents. ATP enables agents to transmit themselves -- including state, context, capabilities, and cryptographic identity -- between agent runtimes across network boundaries. The protocol draws on the operational model of the Simple Mail Transfer Protocol (SMTP) [RFC5321] but is purpose-built for agent-to-agent communication where the agent itself is the payload. ATP provides: (1) asynchronous delivery with store-and-forward semantics, (2) cryptographic identity verification at each relay hop, (3) trust scoring and policy enforcement at ingress, (4) capability negotiation between sending and receiving runtimes, and (5) tamper-evident envelopes with end-to-end integrity protection. The protocol is transport-agnostic and operates over TCP, TLS, QUIC, or any reliable ordered stream. ATP is designed to interoperate with existing agent frameworks including Google A2A, the Model Context Protocol (MCP), and FIPA ACL, while addressing the fundamental limitation of synchronous RPC-based agent communication: the requirement that both endpoints be simultaneously available. | |||||||||||||
| draft-sharif-agent-trust-enforcement-00.txt | ||||||||||||||
| Agent Trust Enforcement for Autonomous AI Systems | ||||||||||||||
|
This document specifies a trust enforcement architecture for autonomous AI agents operating within container orchestration environments such as Kubernetes. It defines a sidecar injection pattern using mutating admission webhooks, graduated trust enforcement (L0-L4) on every outbound call from an agent workload, credential isolation via secret management systems, bilateral revocation propagation across clusters, and tamper- evident evidence generation. The architecture operates alongside existing workload identity frameworks including SPIFFE/SPIRE without replacement, extends X.509v3 certificates with agent-specific extensions under a registered IANA Private Enterprise Number (PEN 66339), and provides compliance evidence for EU AI Act Article 12, FDA 21 CFR Part 11, IEC 62443, and NERC CIP. Three enforcement gates -- LLM gate, Database gate, and API gate -- intercept every outbound call from an agent container. Each gate classifies the call against the agent's trust level, records the decision in a hash-chained evidence ledger with ECDSA P-256 signatures, and either permits or refuses the call. The architecture defaults to deny: if no policy matches, the call is refused. | |||||||||||||
| draft-sharif-ai-model-lifecycle-attestation-01.txt | ||||||||||||||
| Cryptographic Attestation for AI Model Lifecycle: From Training Data to Inference Output | ||||||||||||||
|
This document defines a cryptographic attestation framework for the complete lifecycle of artificial intelligence models, from training data provenance through model weight signing, quantization verification, deployment attestation, and per- inference output signing. The framework creates an unbroken chain of cryptographic evidence binding each inference output to the specific model version, training data, and deployment configuration that produced it. The framework uses ECDSA P-256 digital signatures, SHA-256 hash functions, Merkle trees for corpus attestation, and JSON Web Key Sets (JWKS) for key discovery. It addresses documented threats including model distillation attacks, quantization poisoning, training data manipulation, silent model degradation, and inference output tampering. This specification complements the Agent Trust Transport Protocol (ATTP) [draft-sharif-attp-agent-trust-transport], MCPS message signing [draft-sharif-mcps-secure-mcp], and the Agent Audit Trail format [draft-sharif-agent-audit-trail] to provide end-to- end cryptographic verification from data ingestion to consumer delivery. | |||||||||||||
| draft-sharif-apki-agent-pki-01.txt | ||||||||||||||
| Agent Public Key Infrastructure (APKI): Certificate-Based Identity and Trust for Autonomous AI Agents | ||||||||||||||
|
Autonomous artificial intelligence (AI) agents are increasingly performing actions on the Internet that require verifiable identity: financial transactions, regulated data access, tool invocations, and inter-agent coordination. Traditional Public Key Infrastructure (PKI) based on X.509 certificates was designed for human-operated clients and long-lived servers. It lacks primitives for graduated trust scoring, capability constraints, delegation chains, model provenance, and the ephemeral lifecycles characteristic of AI agents. This document defines Agent Public Key Infrastructure (APKI), a certificate-based identity and trust system for autonomous AI agents. APKI extends X.509v3 with five agent-specific extensions, defines the agent:// URI scheme for agent identification, specifies Agent Transparency Logs modelled on Certificate Transparency (RFC 9162), and provides mechanisms for cross-organizational trust federation. APKI is designed to be compatible with existing PKI deployments, SPIFFE workload identity, and the IETF WIMSE working group's specifications. | |||||||||||||
| draft-sharif-attp-01.txt | ||||||||||||||
| ATTP: Agent Trust Transport Protocol | ||||||||||||||
|
This document specifies the Agent Trust Transport Protocol (ATTP), a protocol-agnostic framework for trust scoring, cryptographic identity, action-limit enforcement, compliance gating, and tamper- evident audit for autonomous AI agents. ATTP separates trust from identity. Identity protocols answer "who is this agent?" ATTP answers "should this agent be allowed to perform this action, at this magnitude, against this counterparty, right now?" The protocol defines five progressive trust levels (L0-L4), per-agent ECDSA P-256 cryptographic identity, a five-dimension behavioural trust scoring model, action-limit tiers derived from trust scores, real-time compliance gating (sanctions screening, jurisdictional controls), kill switches for instant revocation, anomaly detection for agent behaviour, and a public trust query API. ATTP is transport-agnostic. This document defines the core framework. Protocol-specific bindings map ATTP trust enforcement to individual transports: MCPS provides the binding for the Model Context Protocol (MCP), with additional bindings defined for REST APIs, Google A2A, gRPC, GraphQL, and SPIFFE/SPIRE. This specification supersedes draft-sharif-agent-payment-trust-00, broadening the scope from payment transactions to any agent action requiring trust-gated authorisation, and consolidates the parallel draft-sharif-attp-agent-trust-transport-00 into a single ATTP lineage. | |||||||||||||
| draft-sharif-attp-agent-trust-transport-01.txt | ||||||||||||||
| ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server Communication | ||||||||||||||
|
This document specifies ATTP (Agent Trust Transport Protocol), a synchronous request-response protocol for communication between autonomous AI agents and web API servers. ATTP operates as an application-layer protocol over HTTP, adding mandatory cryptographic identity verification, per-message signing, trust-gated access control, and tamper-evident audit trail generation to every agent-server interaction. ATTP defines five protocol-layer headers for requests (X-Agent-Trust, X-Agent-Signature, X-Agent-Nonce, X-Agent-Timestamp, X-ATTP-Version) and three for responses (X-Server-Signature, X-Server-Nonce, X-Server-Timestamp) that carry an Agent Passport (JWT-based identity credential), ECDSA P-256 digital signatures, cryptographic nonces, and timestamps. Server middleware verifies all cryptographic properties before application code executes. ATTP has no insecure mode. Every request MUST carry a valid Agent Passport. Every request body MUST be signed. Every response body MUST be signed. Every interaction MUST be recorded in a hash-chained audit trail. The protocol defines a URL scheme (attp://) and is fully backward-compatible with existing HTTP infrastructure. ATTP is the synchronous counterpart to the Agent Transport Protocol (ATP). ATP handles asynchronous store-and-forward agent delivery; ATTP handles real-time request-response API communication. Both share the same identity model, trust framework, and cryptographic primitives. | |||||||||||||
| draft-sharif-attp-industrial-control-systems-01.txt | ||||||||||||||
| ATTP for Industrial Control Systems: Cryptographic Agent Authentication in SCADA and IoT Environments | ||||||||||||||
|
This document defines an application profile of the Agent Trust Transport Protocol (ATTP) [draft-sharif-attp-agent-trust-transport] for use in Industrial Control Systems (ICS), Supervisory Control and Data Acquisition (SCADA) environments, and Internet of Things (IoT) deployments. It specifies how ATTP mandatory message signing, agent identity passports, and trust-gated access control apply to industrial protocols including Modbus/TCP, OPC UA, MQTT, and CoAP. The profile addresses the absence of per-message authentication in legacy industrial protocols, which has been exploited in numerous critical infrastructure attacks. It defines a gateway architecture that enables ATTP protection for legacy devices without firmware modification, maps ATTP trust levels to IEC 62443 Security Levels, and specifies real-time revocation mechanisms suitable for safety-critical environments. | |||||||||||||
| draft-sharif-mcps-secure-mcp-01.txt | ||||||||||||||
| MCPS: Cryptographic Security Layer for the Model Context Protocol | ||||||||||||||
|
This document specifies MCPS (MCP Secure), a cryptographic security layer for the Model Context Protocol (MCP). MCPS adds agent identity verification, per-message signing, tool definition integrity, and replay protection to MCP communications without modifying the core protocol. MCPS operates as an envelope around existing JSON-RPC messages. It introduces four primitives: (1) Agent Passports for cryptographic identity bound to a specific origin, (2) signed message envelopes for integrity and non-repudiation, (3) tool definition signatures covering the full tool object for detecting poisoning and tampering, and (4) nonce-plus-timestamp replay protection with transcript binding to prevent downgrade attacks. The design is fully backward-compatible. MCPS-unaware clients and servers continue to function normally. MCPS-aware endpoints progressively negotiate security capabilities through trust levels L0 (no verification) through L4 (full mutual authentication with revocation checking). All cryptographic operations use ECDSA P-256 (NIST FIPS 186-5). Signatures use IEEE P1363 fixed-length r||s encoding per RFC 7518 Section 3.4 with low-S normalization to prevent signature malleability. Canonical serialization uses JSON Canonicalization Scheme (JCS) per RFC 8785. The Trust Authority component is self-hostable with no external service dependency. | |||||||||||||
| draft-sharif-openid-agent-identity-01.txt | ||||||||||||||
| OpenID Connect Agent Identity Claims for Autonomous AI Agents | ||||||||||||||
|
This specification defines a profile of OpenID Connect Core 1.0 that enables Identity Providers (IdPs) to issue identity tokens for autonomous software agents. It introduces a set of standard claims for representing agent identity, ownership, trust posture, authorised capabilities, and compliance screening status within OpenID Connect ID Tokens. The profile is designed to operate within existing OpenID Connect infrastructure without requiring modifications to the core protocol. It defines how Relying Parties (RPs) validate agent tokens and enforce graduated access controls based on agent trust levels and sanctions screening results. | |||||||||||||
| draft-sharif-x509-agent-identity-profile-03.txt | ||||||||||||||
| X.509 Certificate Profile for Autonomous AI Agent Identity | ||||||||||||||
|
This document defines an X.509 certificate profile for identifying autonomous AI agents. It specifies a new X.509v3 extension, AgentIdentity, that encodes agent-specific metadata within a standard X.509 certificate, including agent trust level, operational capabilities, delegation constraints, owner attribution, and revocation control endpoints. The profile enables certificate authorities (CAs) to issue interoperable agent identity certificates that any relying party can parse, validate, and enforce, regardless of the issuing CA or the platform that provisioned the agent. The design builds on existing PKI infrastructure (RFC 5280), SPIFFE Verifiable Identity Documents (SPIFFE SVIDs), and the MCPS cryptographic signing layer (draft-sharif-mcps-secure-mcp). It does not require changes to X.509v3 certificate parsing or to existing CA issuance pipelines beyond supporting a new non-critical extension. | |||||||||||||
| draft-sharma-moq-atomic-subscription-bundles-00.txt | ||||||||||||||
| Atomic Subscription Bundles for Media over QUIC Transport | ||||||||||||||
|
This document defines a Media over QUIC Transport (MOQT) extension for atomically changing the Forward State of a set of established subscriptions. It allows a subscriber to replace one set of Tracks with another without an intermediate partially switched state at its peer. | |||||||||||||
| draft-sharma-moq-cache-signaling-00.txt | ||||||||||||||
| Cache Signaling for Media over QUIC Transport | ||||||||||||||
|
This document defines optional hop-by-hop cache signaling for Media over QUIC Transport (MOQT). A subscriber can query the cache status of a finite Track range or request the cache status of a FETCH. Responses report a hit, miss, or partial hit and can identify locally cached ranges. | |||||||||||||
| draft-sharma-oauth-identity-propagation-context-01.txt | ||||||||||||||
| Identity Propagation Context for Multi-Hop Delegation in OAuth 2.0 Environments | ||||||||||||||
|
This specification defines the Identity Propagation Context (IPC), a signed, short-lived context artifact that carries identity and delegation chain information across multi-hop service chains with per-hop cryptographic re-signing. IPC complements the delegation semantics of OAuth 2.0 Token Exchange (RFC 8693) by enabling each trust boundary to independently verify the upstream signature and re- sign the identity context it forwards, supporting cascade revocation, delegation depth limits, and cross-protocol propagation (HTTP, gRPC, and event-streaming systems). Unlike the act claim in RFC 8693, which is explicitly designated as "informational only and not to be considered in access control decisions," IPC is designed for identity propagation that can be used in access control decisions, with per-hop cryptographic re-signing within a single trust domain. In autonomous agent architectures and multi-service platforms, Each trust boundary verifies the upstream signature and re-signs with its own key before forwarding; the delegation chain content is asserted by the IPC Creator and trusted transitively through the chain of re-signing intermediaries. This provides single-hop-verifiable integrity (each service can verify its immediate upstream) rather than end-to-end cryptographic proof of the full chain. | |||||||||||||
| draft-sharma-oepb-00.txt | ||||||||||||||
| Offline Emergency Peer-to-Peer Broadcast Protocol | ||||||||||||||
|
This document specifies the Offline Emergency Peer-to-Peer Broadcast Protocol (OEPB). OEPB is a transport-agnostic overlay protocol for distributing authenticated emergency alerts over short-range peer-to- peer radios in infrastructure-absent environments. Its principal contributions are: (1) a Transport Abstraction Layer (TAL) that presents heterogeneous radio technologies (BLE, Wi-Fi Direct, LoRa, IEEE 802.15.4) as a uniform 256-byte datagram interface to upper layers; (2) application of the Trickle algorithm (RFC 6206) to content-dissemination suppression in a multi-class broadcast context, distinct from its original routing-consistency application in RPL/6LoWPAN; (3) an emergency-semantic five-class Weighted Fair Queuing taxonomy calibrated to disaster-triage urgency; and (4) a trust architecture that deliberately separates relay forwarding from signature verification, preserving life-safety reachability for unauthenticated SOS messages. To the authors' knowledge, no prior open specification addresses authenticated, amplification-resistant emergency broadcast in a transport-agnostic manner across heterogeneous short-range radios; Section 1.1 surveys prior systems and standards. A companion document defines the Transport Binding Profile for Bluetooth Low Energy. | |||||||||||||
| draft-sharma-oepb-binding-ble-00.txt | ||||||||||||||
| OEPB Transport Binding: Bluetooth Low Energy | ||||||||||||||
|
This document defines the Bluetooth Low Energy (BLE) Transport Binding Profile for the Offline Emergency Peer-to-Peer Broadcast Protocol (OEPB). It specifies the advertising mode, fragmentation and reassembly scheme, service and characteristic UUIDs, and channel access rules required to carry OEPB packets over BLE 4.x and BLE 5.x physical layers. | |||||||||||||
| draft-sheffer-tls-pqc-continuity-02.txt | ||||||||||||||
| PQC Continuity: Downgrade Protection for TLS Servers Migrating to PQC | ||||||||||||||
|
As the Internet transitions toward post-quantum cryptography (PQC), many TLS servers will continue supporting traditional certificates to maintain compatibility with legacy clients. However, this coexistence introduces a significant vulnerability: an undetected rollback attack, where a malicious actor strips the PQC or composite certificate and forces the use of a classical certificate once quantum-capable adversaries exist. To defend against this, this document defines a TLS extension that allows a TLS client to cache a server's declared commitment to present PQC or composite certificates for a specified duration. On subsequent connections, the client enforces that cached commitment and rejects traditional-only certificates that conflict with it. This mechanism, inspired by HTTP Strict Transport Security (HSTS) but operating at the TLS layer, provides PQC downgrade protection without requiring changes to certificate authority (CA) infrastructure. | |||||||||||||
| draft-shen-sidrops-region-verification-05.txt | ||||||||||||||
| Verification of Routes Using Region Authorization | ||||||||||||||
|
BGP routing security is a critical issue affecting the stability and reliability of Internet services. Existing mechanisms, including Route Origin Authorization (ROA) and Autonomous System Provider Authorization (ASPA), effectively mitigate route origin hijacking, path hijacking, and route leaks in general scenarios. However, in real-world deployments, large Internet Service Providers (ISPs) managing multiple Autonomous Systems (ASes) remain vulnerable. Attacking networks can exploit carefully crafted routes to bypass ROA and ASPA validations, causing traffic hijacking within or between large ISPs. This document defines a region-based authorization and verification framework for multi-AS ISPs to prevent intra-ISP and inter-ISP traffic hijacking. | |||||||||||||
| draft-shen-sidrops-regionalized-as-relationships-04.txt | ||||||||||||||
| ASPA Verification in the Presence of Regionalized AS-Relationships | ||||||||||||||
|
Autonomous System Provider Authorization (ASPA) defines an RPKI-based methodology to validate the AS_PATH of BGP routes based on a global Customer-to-Provider (C2P) relationship model. However, in commercial Internet routing, two Autonomous Systems (ASes) may establish distinct business relationships across different geographical regions or interconnection points (e.g., Customer-to- Provider in one region, but Peer-to-Peer in another). Such regionalized or hybrid AS-relationships can lead to incorrect ASPA validation results (e.g., false "Valid" attestation for a route propagated over a P2P link). This document analyzes the vulnerabilities caused by regionalized AS-relationships and proposes mechanisms to incorporate regional granularity into ASPA objects and verification procedures. | |||||||||||||
| draft-sheth-pqc-dnssec-strategy-01.txt | ||||||||||||||
| Post-Quantum Cryptography Strategy for DNSSEC | ||||||||||||||
|
This document proposes a post-quantum cryptography (PQC) strategy for Domain Name System Security (DNSSEC) that includes two types of algorithms: one or more conservatively designed algorithms that are unlikely ever to need to be replaced, and one or more low-impact drop-in algorithms that are used the same way as a traditional signature algorithm. The conservatively designed algorithms can be used in a mode of operation that mitigates the operational impact of a large signature size. The combination provides both the routine performance of the low-impact algorithm and a resilient fallback to the conservatively designed choice. The draft outlines the strategy, provides recommendations for future testing and deployment, and highlights operational considerations in adopting PQC for DNSSEC. | |||||||||||||
| draft-shi-ippm-congestion-measurement-data-06.txt | ||||||||||||||
| Data Fields for Congestion Measurement | ||||||||||||||
|
Congestion Measurement collects the congestion information in the packet while the packet traverses a path. The sender sets the congestion measurement data fields in the packet header indicating the network device along the path to update the congestion information field in the packet. When the packet arrives at the receiver, the congestion information field will reflect the degree of congestion across network path. Congestion Measurement can enable precise congestion control, assist in effective load balancing, and simplify network debugging. This document defines data fields for Congestion Measurement. Congestion Measurement Data Fields can be encapsulated into a variety of protocols. | |||||||||||||
| draft-shi-ippm-congestion-measurement-ipv6-options-05.txt | ||||||||||||||
| IPv6 Options for Congestion Measurement | ||||||||||||||
|
The Congestion Measurement enables precise congestion control, assists in effective load balancing, and simplifies network debugging by accurately reflecting the degree of congestion across network paths. This document defines how Congestion Measurement Data Fields are encapsulated in IPv6. | |||||||||||||
| draft-shin-avtcore-rtp-multi-opus-03.txt | ||||||||||||||
| RTP/SDP for Opus Multistream | ||||||||||||||
|
This document specifies RTP/SDP signaling for Opus multistream (multi-channel) operation, enabling negotiation of layouts such as 5.1 and 7.1 in real-time communications. It defines an SDP encoding name and format parameters to describe multistream configurations, and specifies Offer/Answer procedures for interoperable negotiation. This document does not define new Opus codec behavior. It extends the the SDP signaling defined in [RFC7587] and reuses the channel-mapping semantics defined in [RFC7845]. | |||||||||||||
| draft-shishio-grow-isp-rfd-implement-survey-05.txt | ||||||||||||||
| Route Flap Damping Deployment Status Survey | ||||||||||||||
|
BGP Route Flap Damping [RFC2439] is a mechanism that targets route stability. It penalyzes routes that flap with the aim of reducing CPU load on the routers. But it has side-effects. Thus, in 2006, RIPE recommended not to use Route Flap Damping (see [RIPE-378]). Now, some researchers propose to turn RFD, with less aggressive parameters, back on [draft-ymbk-rfd-usable]. This document describes results of a survey conducted among service provider on their use of BGP Route Flap Damping. | |||||||||||||
| draft-shovan-gap-00.txt | ||||||||||||||
| Governed Action Protocol (GAP) | ||||||||||||||
|
The Governed Action Protocol (GAP) is an open wire protocol for a Universal Action Coordination Fabric. GAP defines a four-phase lifecycle (Declare, Grant, Invoke, Receipt) that governs every action an AI agent, smart device, industrial controller, or automated pipeline may take. Every gate decision produces a content-addressed, immutable receipt; receipts are signed at L2+ (Ed25519) and L4 (hybrid ML-DSA-65). The protocol is designed to be language- and platform-neutral, applicable across enterprise AI agent pipelines, consumer smart home devices, medical equipment, industrial control systems, and game engines. This document specifies the wire format, object model, grant evaluation rules, HTTP API surface, workflow semantics, revocation mechanisms, and conformance tiers for GAP version 1.0. | |||||||||||||
| draft-shubralov-demi-sro-payment-security-02.txt | ||||||||||||||
| Blockchain-Backed Risk Pooling and Self-Regulation Protocol for Alternative Payment Providers (DeMI) | ||||||||||||||
|
This document specifies a Best Current Practice (BCP) for risk management, automated self-regulation, and transaction settlement integrity among alternative payment service providers (APPs) operating in emerging markets without formal ISO/PCI-DSS coverage. It defines an architectural specification for a decentralized self- regulated organization (SRO) compensation pool deployed on the Ethereum Layer 1 blockchain. The protocol mitigates time-delayed fraud vectors, liquidity mismatches, and cross-border settlement frictions through cryptographic batching, zero-trust geo-distributed validator networks over private MPLS/satellite topologies, and automated algorithmic underwriting. | |||||||||||||
| draft-shyam-vlsmtrp-15.txt | ||||||||||||||
| VLSM Tree Routing Protocol | ||||||||||||||
|
This is a light weight routing protocol applicable inside a network that appears in the form of a tree and distribution of address space takes place with the approach of VLSM. It is based on setting default route inside VLSM tree. With this approach, routing information of the external world need not be passed down to the VLSM tree. Thus, load inside a router gets reduced substantially. This document includes IP-VPN with MPLS inside VLSM tree by extending RSVP-TE. | |||||||||||||
| draft-si-ztcpp-5g-securityframework-00.txt | ||||||||||||||
| Security Capability Coordination Execution Framework for 5G Core Networks | ||||||||||||||
|
This document defines a security capability coordination execution framework for 5G core networks. The framework employs a set of Security Coordination Components (SCC) that work collaboratively with core network functions to achieve continuous trust verification and least-privilege access control. It specifies the division of responsibilities between the Network Function Security Agent and the Management Security Controller. This document aims to provide a standardized architecture reference for the ZTCPP working group. | |||||||||||||
| draft-sidor-pce-binding-label-sid-extensions-03.txt | ||||||||||||||
| Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP) | ||||||||||||||
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). This includes the ability for a PCE to specify a Binding Segment Identifier (SID) for an LSP. A binding value specified by a PCE may not be available for use on the PCC. This can lead to LSP instantiation failures or entire PCEP message being rejected. This document proposes extensions to PCEP to allow a PCC to fall back to allocating a Binding SID from its own dynamic range if the value specified by the PCE is unavailable. It also defines a mechanism for the PCC to report both the requested and the allocated binding values back to the PCE. | |||||||||||||
| draft-silva-hymrpl-01.txt | ||||||||||||||
| HyMRPL: Per-Node Hybrid Mode of Operation and Inter-DODAG Bridge Mechanism for RPL | ||||||||||||||
|
The Routing Protocol for Low-Power and Lossy Networks (RPL), defined in RFC 6550, enforces a single Mode of Operation (MOP) across all nodes within a DODAG. This rigidity prevents heterogeneous devices from independently selecting their forwarding behavior and creates permanent isolation between DODAGs operating with different MOPs. This document defines HyMRPL, a Hybrid Mode of Operation (MOP=6) that enables per-node functional profiles within a single DODAG. Nodes independently adopt Class-S (storing-like) or Class-N (non-storing- like) behavior without modifying RPL control message formats. Additionally, this document specifies an Inter-DODAG Bridge mechanism that uses MOP Extension (MOPex) signaling to interconnect DODAGs with different MOPs through cross-DODAG route injection. The mechanisms introduce zero additional control messages, maintain full backward compatibility via the J-flag in extended options, and have been validated with a functional implementation demonstrating 100% packet delivery ratio across MOP boundaries. | |||||||||||||
| draft-singh-apex-psi-02-00.txt | ||||||||||||||
| PSI-02: ACCU Carbon Sequestration Attestation | ||||||||||||||
|
PSI-02 specifies a privacy-preserving cryptographic attestation that a registered NDIS service provider's operational evidence satisfies the NDIS Practice Standards. The attestation binds a canonicalised evidence digest to an Ed25519 signature without disclosing participant data or commercially sensitive material. | |||||||||||||
| draft-singh-apex-psi-03-01.txt | ||||||||||||||
| PSI-03: VPP Dispatch Conformance Attestation | ||||||||||||||
|
PSI-03 specifies a portable, Ed25519-signed bond that anchors a registered NDIS practitioner's professional identity to a DID- compatible decentralised identifier without requiring a central registry. The bond enables cross-provider, cross-border practice verification while preserving privacy and issuer sovereignty. | |||||||||||||
| draft-singh-apex-psi-04-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-singh-apex-psi-05-02.txt | ||||||||||||||
| PSI-05: Financial Disclosure Integrity | ||||||||||||||
|
PSI-05 defines a cryptographic attestation framework for financial disclosures, enabling third parties to recompute and verify company filings against their published figures. It establishes a public ledger of sealed financial statements, a verification protocol using RFC 8785 canonicalization with Ed25519 (classical) and ML-DSA-65 (post-quantum) signatures, and an API for querying reconciliation results. The framework supports ASX, NYSE, NSE, LSE, and Euronext filings. | |||||||||||||
| draft-singh-apex-psi-06-01.txt | ||||||||||||||
| PSI-06: Inception-Lock Protocol for Human-Originated Data Signals | ||||||||||||||
|
PSI-06 specifies an inception-lock protocol that cryptographically anchors a raw human-originated data signal (keystroke, biometric, survey response, application screen capture, trip acceptance timestamp) to a signing key at the point of capture. The protocol prevents tampering with source data between capture and submission, enabling verifiable proof of what a user was shown and when they saw it. Receipts are protected by a hybrid dual-signature scheme combining Ed25519 (classical) and ML-DSA-65 (post-quantum), making the evidence chain resistant to both classical and quantum adversaries. This is critical for accountability proceedings involving algorithmic platforms, where the information displayed to the user may differ from the information recorded by the platform. | |||||||||||||
| draft-singh-apex-psi-07-01.txt | ||||||||||||||
| PSI-07: Organic Production Attestation | ||||||||||||||
|
PSI-07 defines a standard signal format for regulatory events detected by automated monitoring systems. The format is a signed JSON envelope carrying the event classification, evidence hash, and jurisdiction code, enabling autonomous reporting to one or more regulators without human intervention. | |||||||||||||
| draft-singh-apex-psi-08-00.txt | ||||||||||||||
| PSI-08: Health Records Access Attestation | ||||||||||||||
|
PSI-08 specifies a format for composing multiple Digital Gallows predicates into a verifiable chain. Each link in the chain is a signed predicate output that serves as input to the next, enabling verifiable multi-step inference without a trusted intermediary. | |||||||||||||
| draft-singh-apex-psi-09-00.txt | ||||||||||||||
| PSI-09: Age Assurance Attestation | ||||||||||||||
|
PSI-09 defines a signed verdict format for distributed tribunal proceedings conducted under the Apex Protocol. A verdict carries the case identifier, the predicate chain that produced it, the ruling, the evidence anchors, and the dissenting opinion if any. | |||||||||||||
| draft-singh-macneil-geneve-firewall-metadata-00.txt | ||||||||||||||
| Geneve-based Firewall Metadata for Overlay Networks | ||||||||||||||
|
This document specifies a mechanism for embedding security-related metadata within the Geneve header (RFC 8926). It allows a security Enforcement Point to attach a cryptographically signed, verifiable attestation of how it handled a packet, so that downstream Enforcement Points and tunnel endpoints can confirm that security policy was actually executed on the data path -- detecting policy bypasses and divergence between Enforcement Points that should agree -- while each Enforcement Point continues to enforce its own policy independently. This validation of execution complements the management plane's validation of intent. The document presents two operational models. The primary model is the "End-to-End Attestation Model", fully compliant with RFC 8926, where an ingress tunnel endpoint adds and cryptographically signs metadata, and an egress endpoint verifies it. This enables downstream nodes to verify and audit that policy was executed consistently, while still applying their own policy independently. The second part of this document presents a proposal for a future extension to the Geneve standard. This proposed extension would allow trusted transit devices to participate in the metadata chain, enabling a hop-by-hop "chain of custody" for enhanced, real-time security responsiveness within the data center fabric. | |||||||||||||
| draft-singh-macneil-ioam-firewall-metadata-00.txt | ||||||||||||||
| IOAM Data Fields for Firewall and Security Metadata | ||||||||||||||
|
This document defines a new IOAM Namespace and associated Data Fields for carrying firewall and security-related metadata within the In- situ Operations, Administration, and Maintenance (IOAM) framework (RFC 9197). The mechanism allows each security Enforcement Point on a path to attach a verifiable attestation of the action it took on a packet. This lets downstream Enforcement Points and other nodes confirm that security policy was actually executed on the data path -- detecting policy bypasses and detecting divergence between Enforcement Points that are expected to agree -- while each Enforcement Point continues to apply its own policy independently rather than delegating enforcement. This validation of execution complements the management plane's validation of intent. The metadata also enables real-time signaling of policer states for DDoS mitigation. To ensure the authenticity and integrity of this information, this document leverages the integrity protection mechanisms defined in the IOAM data integrity specification (draft- ietf-ippm-ioam-data-integrity). | |||||||||||||
| draft-singh-psi-01-01.txt | ||||||||||||||
| Proof of Sovereign Integrity (PSI): Protocol Specification v1 | ||||||||||||||
|
This document specifies the Proof of Sovereign Integrity (PSI) Protocol for verifiable AI regulatory compliance. Revision 01 updates the March 2026 specification with EU AI Act Article 50 alignment and post-quantum cryptographic requirements. | |||||||||||||
| draft-singh-psi-01.txt | ||||||||||||||
| Proof of Sovereign Integrity (PSI): A Cryptographic Protocol for Verifiable AI Regulatory Compliance | ||||||||||||||
|
This document specifies the Proof of Sovereign Integrity (PSI) Protocol, version 1.2, a cryptographic framework enabling organizations to prove compliance with AI regulations (including the EU AI Act 2024/1689, NIST AI RMF, UK AI Safety Institute guidelines, and equivalent frameworks) without disclosing proprietary model architectures, training data, or inference logic. PSI achieves this through a combination of SHA-256 hash-chained audit trails, Ed25519 digital signatures, Merkle inclusion proofs, Groth16-compatible zero-knowledge commitments over BN128 fields, and a 3-node Multi-Party Computation (MPC) consensus mechanism with 2/3 threshold verification. This revision documents a deployed public reference implementation and adds optional post-quantum signature profiles and Bitcoin timestamp anchoring. | |||||||||||||
| draft-singh-psi-age-assurance-00.txt | ||||||||||||||
| PSI Zero-Knowledge Age Assurance Attestation | ||||||||||||||
|
This document specifies PSI-Age, a privacy-preserving cryptographic attestation for age assurance. It enables a relying party (such as a social media platform or online service) to verify that a user meets a minimum age threshold without learning the user's identity, date of birth, or any other personal attribute. PSI-Age uses zero-knowledge range proofs over a committed birthdate to produce a compact, verifiable "age credential" that proves age >= threshold without rev | |||||||||||||
| draft-singh-psi-agent-00.txt | ||||||||||||||
| PSI AI Agent Action Sealing and Liability Protocol | ||||||||||||||
|
This document specifies a cryptographic protocol for sealing AI agent actions, establishing an auditable chain of custody from instruction to execution. As AI agents increasingly perform autonomous actions — financial transfers, content publication, system configuration, legal filings — the need for a verifiable record of "who instructed what, when, and what actually happened" becomes critical for liability attribution, regulatory compliance, and trust. The PSI Agent Se | |||||||||||||
| draft-singh-psi-merkle-00.txt | ||||||||||||||
| PSI Merkle Tree Anchoring for Cryptographic Seals | ||||||||||||||
|
This document specifies the Merkle tree construction and anchoring protocol used by the Proof of Sovereign Integrity (PSI) system for tamper-evident content verification. It defines tree parameters, leaf construction, inclusion proof generation, and root anchoring to public ledgers including the Bitcoin blockchain. The protocol uses SHA-256 as the hash function, binary Merkle trees with height=5 (32 leaves per epoch), and deterministic leaf ordering to enable third- party v | |||||||||||||
| draft-singh-psi-post-quantum-00.txt | ||||||||||||||
| PSI Post-Quantum Dual-Signature Sealing | ||||||||||||||
|
This document specifies the post-quantum cryptographic sealing extension for the Proof of Sovereign Integrity (PSI) Protocol. While classical Ed25519 signatures provide current security, the emergence of cryptographically relevant quantum computers (CRQCs) threatens all elliptic-curve and RSA-based signature schemes. PSI addresses this through dual-signature sealing: each seal carries both an Ed25519 signature (for immediate classical verification) and an LMS-W4-SHA256 hash | |||||||||||||
| draft-singh-skip-00.txt | ||||||||||||||
| Secure Key Integration Protocol (SKIP) | ||||||||||||||
|
This document specifies the Secure Key Integration Protocol (SKIP), a two-party protocol that allows a client to securely obtain a key from an independent Key Provider. SKIP enables network and security operators to provide quantum-resistant keys suitable for use with quantum-resistant cryptographic algorithms such as AES-256. It can also be used to provide an additional layer of security to an already quantum-resistant secure channel protocol for a defense-in-depth strategy, and/or enforce key management policies. | |||||||||||||
| draft-singh-webbotauth-hosted-directories-00.txt | ||||||||||||||
| Hosted Key Directories for Web Bot Auth | ||||||||||||||
|
Web Bot Auth authenticates automated clients to origins using HTTP Message Signatures, with verification keys published in a key directory at a well-known URI. Current drafts assume that each agent operator hosts its own key directory. A large and growing population of agents is operated by individuals and small organizations for whom hosting a directory is impractical, and whose legitimate traffic is otherwise indistinguishable from abusive automation. This document describes the hosted (multi-tenant) key directory deployment model, in which a registry operator publishes key directories on behalf of many independent agent operators while the operators retain exclusive custody of their private keys. It analyzes principal mapping, proof of key possession, freshness, and accountability in this model; reports interoperability observations from an independent implementation; and offers operational guidance for hosted directory operators and for verifiers. It is intended as input to the Web Bot Auth working group's operational and deployment guidance. | |||||||||||||
| draft-singla-agent-identity-protocol-03.txt | ||||||||||||||
| Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents | ||||||||||||||
|
The Agent Identity Protocol (AIP) defines a decentralized identity, delegation, and authorization framework for autonomous AI agents. AIP combines W3C Decentralized Identifiers (DIDs), capability-based authorization, cryptographic delegation chains, and deterministic validation to enable secure, auditable multi-agent workflows without relying on centralized identity providers. | |||||||||||||
| draft-sip-digest-auth-x25519-ristretto255-schnorr-00.txt | ||||||||||||||
| SIP Digest Authentication with X25519 Shared Secrets and Ristretto255 Schnorr Proofs | ||||||||||||||
|
This document defines three Session Initiation Protocol (SIP) Digest authentication algorithms that replace password-derived Digest secrets with public-key-based authentication material. Two algorithms derive a response secret from an X25519 shared secret, and one algorithm uses a Fiat-Shamir Schnorr proof over the ristretto255 group. The mechanisms defined here preserve the existing SIP Digest challenge and authorization header flow while adding Digest parameters that carry public keys and, optionally, an authenticated server challenge proof. | |||||||||||||
| draft-sipos-dtn-bp-safe-01.txt | ||||||||||||||
| Bundle Protocol (BP) Security Associations with Few Exchanges (SAFE) | ||||||||||||||
|
This document defines a protocol for negotiating scoped security associations between Bundle Protocol version 7 (BPv7) agents within a delay-tolerant network (DTN). Security associations are used to amortize the costs of asymmetric-keyed security operations and allow for efficient and high-throughput BPv7 security within a public key infrastructure. This protocol also provides for unilateral re-keying of established security associations in a delay-tolerant manner. | |||||||||||||
| draft-sipos-dtn-manifest-block-01.txt | ||||||||||||||
| Bundle Protocol (BP) Manifest Block | ||||||||||||||
|
This document defines an extension block type for Bundle Protocol version 7 to capture discretionary summary data about the state of a Bundle at the time the extension block is added. This Manifest structure is a general purpose container for information about other blocks, and can be used as a piece-part of a larger security operation. | |||||||||||||
| draft-sirkkavaara-vaara-receipt-10.txt | ||||||||||||||
| The Vaara Receipt: A Recomputable Receipt Format for Decisions About Autonomous Actions | ||||||||||||||
|
This document specifies vaara.receipt/v1, a signed and independently recomputable record that binds a decision about an autonomous action to the evidence the decision was made on, and optionally to one or more external timestamp anchors. The format is canonicalized with the JSON Canonicalization Scheme (JCS) so that any third party can recompute its digests and verify its signature without access to the issuer. A decision and the execution receipt that answers it form one recomputable pair through the envelope's back link. The receipt's trust is root-agnostic: the same record is verifiable with or without a hardware trusted execution environment and is re- expressible as an IETF RATS Entity Attestation Result. Downstream specifications (a payment rail, a compliance regime, a framework integration) define profiles that pin to a version of this document and add only their own evidence schema; they do not redefine the envelope. The format described here is deployed, and its receipts are independently recomputable from public conformance vectors that ship with standalone checkers importing no issuer code. The minimal profile is a governance decision over a single autonomous action, bound to the action's own intent with no external rail; it is the floor of the format, and a reference library offers a matching adoption floor at the API layer as a one-line decorator over the governed function. | |||||||||||||
| draft-sirohi-schc-quic-frame-compression-00.txt | ||||||||||||||
| Exploring SCHC Compression of QUIC Frames | ||||||||||||||
|
This document explores whether Static Context Header Compression (SCHC) can be applied to the metadata carried in QUIC frames. QUIC already uses compact frame encodings and variable-length integers, so any compressed representation has to recover enough bytes to pay for its own integration overhead. The document compares several possible organizations for SCHC rules, discusses how frame compression could be integrated, and analyzes representative STREAM and ACK frame examples. The analysis suggests that SCHC compression of QUIC frames is technically possible, but that generic or base rules are likely to provide only modest savings at best. More substantial savings require predictable traffic, pre-provisioned or negotiated rules, bundling of several frames under one rule, or a negotiated QUIC payload syntax with low per-packet overhead. This document is exploratory. It does not define an interoperable QUIC extension, SCHC profile, wire format, or IANA allocation. | |||||||||||||
| draft-skoglund-epp-registry-lock-00.txt | ||||||||||||||
| Registry Lock Extension for the Extensible Provisioning Protocol (EPP) | ||||||||||||||
|
This document describes an Extensible Provisioning Protocol (EPP) extension for setting and managing a registry lock on a domain object. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/EricIO/draft-regext-epp-registry-lock (https://github.com/EricIO/draft-regext-epp-registry-lock). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. | |||||||||||||
| draft-skyfire-oauth-aml-methods-00.txt | ||||||||||||||
| Anti-Money Laundering Methods Values | ||||||||||||||
|
Financial regulations require application of Anti-Money Laundering (AML) and Countering the Financing of Terrorism (CFT) methods in many jurisdictions worldwide. This specification defines a claim and values for declaring what AML/CFT methods were employed. | |||||||||||||
| draft-skyfire-oauth-amr-values-01.txt | ||||||||||||||
| Additional Authentication Method Reference Values | ||||||||||||||
|
The JWT "amr" (Authentication Methods References) claim contains values conveying authentication methods used in the authentication. This specification defines additional Authentication Method Reference values beyond those already registered to represent additional authentication methods in use today. | |||||||||||||
| draft-skyfire-oauth-id-verification-01.txt | ||||||||||||||
| Identity Verification Methods Values | ||||||||||||||
|
Knowing how a person's identity was verified can be important when making trust decisions. This specification defines a claim and values for declaring how the person's identity was verified. | |||||||||||||
| draft-skyfire-oauth-kyapay-token-01.txt | ||||||||||||||
| KYAPay Token | ||||||||||||||
|
This document defines a token format for agent identity and payment tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this token format to consume identity and payment tokens in an interoperable manner. | |||||||||||||
| draft-skyfire-oauth-kyapay-token-exchange-01.txt | ||||||||||||||
| KYAPay Token Exchange | ||||||||||||||
|
This specification describes how KYAPay tokens can be exchanged for OAuth access tokens to dynamically grant agents access to resources they need to accomplish their mission. | |||||||||||||
| draft-skyfire-oauth-using-kyapay-tokens-00.txt | ||||||||||||||
| Using KYAPay Tokens | ||||||||||||||
|
The KYAPay Token is a JSON Web Token (JWT) that carries verified identity ("Know Your Agent", KYA) and payment (PAY) information for requests made by software agents on behalf of human principals. This document describes how security intermediaries -- bot managers, fraud managers, account-takeover (ATO) protection systems, and customer identity and access management (CIAM) systems -- consume KYAPay tokens to answer a question that traditional bot detection cannot: "did a verified human authorize this agent?", rather than "is this a human?". It specifies how KYAPay tokens are carried in HTTP requests, how they are validated (including in combination with request-signing layers such as HTTP Message Signatures), and how the verified, layered identity in a token is used to make access, routing, fraud detection, account-lifecycle, and step-up decisions. It defines the token-consuming "verifier" role that the KYAPay Token leaves unspecified. It is intentionally non-prescriptive about how tokens are created, because agent architectures, agent-identity technologies, and agent-communication protocols are diverse and still emerging; the token itself is the interoperability contract. | |||||||||||||
| draft-sl-rtgwg-far-dcn-26.txt | ||||||||||||||
| Generic Fault-Avoidance Routing Protocol for Data Center Networks | ||||||||||||||
|
This document describes a generic routing method and protocol for a regular data center network, named the Fault-Avoidance Routing (FAR) protocol. The FAR protocol provides a generic routing method for all types of regular topology network architectures that have been proposed for large-scale cloud-based data centers over the past few years. The FAR protocol is designed to leverage any regularity in the topology and compute its routing table in a concise manner. Fat- tree is taken as an example architecture to illustrate how the FAR protocol can be applied in real operational scenarios. | |||||||||||||
| draft-slevinski-formal-signwriting-11.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-slevinski-iswa-2010-00.txt | ||||||||||||||
| Encoding the graphemes of the SignWriting Script with the x-ISWA-2010 | ||||||||||||||
|
For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. | |||||||||||||
| draft-sliwa-stir-cert-cps-ext-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-smc-grow-bmp-route-change-stats-02.txt | ||||||||||||||
| BMP Route Change Statistics Based on Routing Policy | ||||||||||||||
|
This document defines few generic BGP Monitoring Protocol (BMP) statistics for monitoring route modifications or changes due to applying Routing Policy. These statistics are reported per BGP peer using the BMP Statistics Report message. This revision (-02) firms up the specification for working group consideration: it adds a Relationship to Other Work section that explicitly maps this document to concurrently circulating GROW contributions on BMP statistics and policy-driven telemetry and invites coordination with their authors, adds a worked example, and strengthens Security Considerations. No statistics semantics, Stat Type allocations, or wire formats defined in -01 are changed. | |||||||||||||
| draft-smith-6man-accurate-ra-router-lifetime-05.txt | ||||||||||||||
| More Accurately Naming IPv6 RA Router Lifetime | ||||||||||||||
|
IPv6 Router Advertisements (RAs) have a "Router Lifetime" field, which specifies how long the advertising router will act as a default router for the receiving hosts, unless refreshed with another advertisement. The field name "Router Lifetime" is quite general, and could easily be misunderstood to mean the bounded lifetime of all of the information contained in the RA. This memo more accurately renames this field "Default Router Lifetime". | |||||||||||||
| draft-smith-6man-ipv6-over-nothing-01.txt | ||||||||||||||
| IPv6 Over Nothing | ||||||||||||||
|
A perspective on the function of the network layer is that it abstracts away the differences between the various underlying link layer frame and addressing formats, unifying them into a common protocol data unit format and addressing scheme, namely the IPv4 or IPv6 protocols, and hiding those details from the upper transport layer protocols. As IPv6 is expected to become the dominant network layer protocol, and Ethernet has become the dominant link layer protocol, this memo proposes eliminating the overhead of the abstraction of Ethernet by IPv6 and using IPv6 directly as both the link layer and network layer protocol. | |||||||||||||
| draft-smith-idr-rr-deployment-considerations-00.txt | ||||||||||||||
| BGP RR Deployment Considerations | ||||||||||||||
|
In BGP networks, Route Reflectors (RRs) help to simplify IBGP control plane provisioning as well as mitigate the session scale challenges associated with an IBGP full mesh between border routers. Given these operational benefits, RRs are widely deployed in modern BGP network architectures. This document describes common RR deployment models, including their respective trade-offs, and provides best practice suggestions based on years of industry experience. Operators of BGP networks should consider and/or adopt these best practices, as BGP control plane stability is critical to overall network stability. | |||||||||||||
| draft-smith-opsawg-ai-network-governance-00.txt | ||||||||||||||
| Governance Framework for AI-Mediated Autonomous Network Device Management | ||||||||||||||
|
This document defines a governance framework for systems that use artificial intelligence (AI) services, specifically large language models (LLMs), to autonomously detect, diagnose, and remediate operational anomalies on network devices. As AI-driven automation moves from advisory tooling to closed-loop autonomous operation on production infrastructure, the industry lacks a common set of principles governing what such systems may and may not do. This framework establishes thirteen governance areas covering human authority, harm prevention, management plane protection, minimum necessary action, bounded autonomy, transparency, reversibility, graceful degradation, escalation, AI-specific constraints, startup safety, absolute prohibitions, and review processes. It is intended to serve as a reference architecture for implementers building AI-mediated network management systems and for operators evaluating the safety properties of such systems. | |||||||||||||
| draft-smith-uber-00.txt | ||||||||||||||
| The Universal Basic Element Representation (UBER) Format | ||||||||||||||
|
This document defines the Universal Basic Element Representation (ÜBER), a language-independent, lightweight, text-based serialization format designed for the portable representation, transmission, and storage of structured data. ÜBER employs a unified node architecture in which each node serves simultaneously as a value-carrier and a structural container. This recursive model allows any element to encapsulate a discrete data payload while concurrently functioning as a parent to nested members. The same structure also provides the granularity needed by implementations that target high-concurrency access patterns with localized, low-contention updates. A top-level ÜBER profile consists of either an explicit root object or a sequence of members and directives. To prioritize human-centric design and authoring ergonomics, the grammar supports comments, flexible arbitrary-length key-value separators, optional commas, and dotted member names. The ÜBER type system is defined by recursive containers and scalar forms. Associative arrays ({}) and collections ([]) support arbitrary nesting, while concrete ordering behavior remains implementation-dependent. Scalar forms include deterministic numbers with arbitrary-precision integer syntax and Java-aligned unsuffixed floating-point lexical forms, automatic magnitude-based fitting and promotion, versatile string representations including text blocks, flexible boolean literals, and both explicit and omitted null states. This specification defines the lexical and syntactic grammar of ÜBER. It does not define implementation-specific runtime facilities except where a grammar element, such as directives, requires a brief statement of purpose. | |||||||||||||
| draft-smm-bess-alt-label-01.txt | ||||||||||||||
| Signaling Alternative Labels for BGP Prefixes | ||||||||||||||
|
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. | |||||||||||||
| draft-smn-idr-inter-domain-ibgp-10.txt | ||||||||||||||
| Interconnecting domains with IBGP | ||||||||||||||
|
This document describes the building of Inter-domain L3VPN architecture with internal BGP, applying the multi-domain options specified in BGP/MPLS IP Virtual Private Networks (VPNs) within a single Autonomous System, where route reflectors set the NEXT_HOP attribute to self as described in BGP Route Reflector with Next Hop Self. | |||||||||||||
| draft-smyslov-ipsecme-ikev2-mceliece-02.txt | ||||||||||||||
| Using Classic McEliece in the Internet Key Exchange Protocol Version 2 (IKEv2) | ||||||||||||||
|
This document specifies how Classic McEliece Key Encapsulation Mechanism (KEM) is used to generate keys in the Internet Key Exchange version 2 (IKEv2) protocol. | |||||||||||||
| draft-smyslov-ipsecme-ikev2-psp-01.txt | ||||||||||||||
| Using the Internet Key Exchange Protocol Version 2 (IKEv2) for PSP Key Management | ||||||||||||||
|
This document specifies how the Internet Key Exchange Version 2 (IKEv2) protocol can be used for supplying keys for the PSP Security Protocol (PSP). | |||||||||||||
| draft-smyslov-lamps-frodokem-certificates-03.txt | ||||||||||||||
| Internet X.509 Public Key Infrastructure - Algorithm Identifiers for FrodoKEM | ||||||||||||||
|
FrodoKEM is an unstructured lattice-based Key Encapsulation Mechanism (KEM). Compared to ML-KEM, FrodoKEM is considered as having more conservative design. This document specifies the conventions for using FrodoKEM in X.509 Public Key Infrastructure. The conventions for the subject public keys and private keys are also specified. | |||||||||||||
| draft-smyslov-tls-ext-ext-00.txt | ||||||||||||||
| Extending Limit on Extensions Size in TLS 1.3 | ||||||||||||||
|
Protocol TLS 1.3 is widely used to protect traffic in the Internet. However, the format of the TLS 1.3 ClientHello, ServerHello, and EncryptedExtensions handshake messages limits the size of extensions to 64 Kbytes. This specification extends TLS 1.3 to allow extensions in ClientHello, ServerHello, and EncryptedExtensions have size larget than 64 Kbytes. | |||||||||||||
| draft-snell-activity-streams-type-01.txt | ||||||||||||||
| The application/stream+json Media Type | ||||||||||||||
|
This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format. | |||||||||||||
| draft-soares-sustain-green-security-00.txt | ||||||||||||||
| Research Directions on Energy-Aware Security Mechanisms | ||||||||||||||
|
With the advancement of the climate emergency, all areas of human activity are expected to continuously assess their Greenhouse Gas emissions and encourage the use of clean energy as much as possible. The current discussion on green networking in the Network Management research field still needs to be expanded to the adjoined areas, such as Network Security. This document outlines possible research directions for energy-aware security mechanisms. | |||||||||||||
| draft-soden-wellknown-mcp-commerce-00.txt | ||||||||||||||
| A Well-Known URI Profile for Agent-Callable Commerce Endpoints | ||||||||||||||
|
This document defines an informational profile for the Server Card document retrieved from the /.well-known/mcp.json Well-Known URI defined by the Model Context Protocol (MCP) project. The profile adds an optional commerce extension to the Server Card, carried in the Server Card's _meta object under the reverse-DNS key com.beaconspec/commerce, for commercial businesses operating MCP servers. The extension carries business identity, geographic location, industry classification, offering type, and advertised capability categories. The purpose of the profile is to give AI agents enough machine-readable information about a commercial MCP server to filter, select, and bootstrap an interaction without first opening an MCP session against every candidate server. | |||||||||||||
| draft-sogomonian-aiid-namespace-00.txt | ||||||||||||||
| AIID: An Identifier Namespace for Autonomous Systems | ||||||||||||||
|
Autonomous systems operate today without stable, globally unique identities. When an AI agent executes an action, there is no universally recognized identifier for that agent, no delegation record, and no accountability chain back to a human principal. This document defines the Autonomous System Identifier (AIID) namespace. An AIID is a structured, hierarchical identifier assigned to an autonomous system, execution environment, or agent operating within the Artificial Intelligence Internet Protocol (AIIP) architecture [I-D.sogomonian-aiip-architecture]. This document specifies the AIID syntax, hierarchical structure, registration model, operational states including safe mode, and revocation mechanisms. The governance model for the namespace, including selection of a root registry operator, is explicitly left open for community determination. | |||||||||||||
| draft-sogomonian-aiip-architecture-04.txt | ||||||||||||||
| Architecture for the Artificial Intelligence Internet Protocol | ||||||||||||||
|
This document defines the architectural model for the Artificial Intelligence Internet Protocol (AIIP). AIIP defines a dedicated autonomous access plane for execution-capable systems, enabling delegated, stateless execution of real-world actions using a resolve- invoke-execute-receipt pattern over authenticated transports. AIIP is not a discovery, registration, orchestration, or control- plane protocol. It defines the architectural boundary at which autonomous execution is recognized and cryptographically verifiable through execution receipts. | |||||||||||||
| draft-sogomonian-aiip-core-00.txt | ||||||||||||||
| AIIP Core: Agent Access Plane,AIID,Resolve,Invoke,and Receipt | ||||||||||||||
|
This document specifies the core of the AI Internet Protocol (AIIP) agent access plane: the AIID identity namespace, the aiip: URI scheme, Resolve, Invoke, Receipt, and delegation grants. Underlay addresses are disposable locators only. Agents MUST NOT use HTTP or HTTPS as their Invoke (or Resolve) path. Independence doctrine: underlay pipes and platforms are never authority. Mesh tip attestation is a trust layer, not a ledger. Access Fabric punch ops are Experimental. This revision (2026-09-08 wire harden) is derived from the running lab profile "aiip-wire-0". It is an individual submission draft; it does not claim Working Group adoption or RFC publication. | |||||||||||||
| draft-sogomonian-aiip-native-access-architecture-01.txt | ||||||||||||||
| AIIP: Native Access Architecture for Autonomous Systems A Problem Statement and Architectural Exploration | ||||||||||||||
|
The Internet evolved around human interaction and information exchange. Technologies such as DNS, HTTP, and the World Wide Web created a universal access layer that enables people to discover resources, retrieve information, and interact with services through common protocols and interfaces. As autonomous systems become increasingly capable of acting on behalf of users and organizations, new interoperability challenges emerge. Agents, robots, tools, and autonomous services must discover resources, invoke actions, delegate authority, execute tasks, enforce policy, and obtain verifiable outcomes across independently developed implementations. This document explores the concept of a native Internet access architecture for autonomous systems. It examines whether autonomous systems require a dedicated access layer analogous to the role that DNS, HTTP, and the Web played for human information exchange. The document clarifies the relationship between AIIP and existing Internet protocols, describes the architectural position of AIIP as a native access layer rather than a profile of HTTP, and provides context for AIIP-related work including identifiers, discovery, invocation, execution, delegation, policy enforcement, and execution outcome verification. This document is a problem statement and architectural exploration. It does not define protocol mechanisms. | |||||||||||||
| draft-sohail-urn-dnp-01.txt | ||||||||||||||
| A Uniform Resource Name (URN) Namespace for Digital Nation Pakistan (DNP) | ||||||||||||||
|
This document describes a Uniform Resource Name (URN) namespace for persistent, location-independent identification of normative and authoritative publications issued under the Digital Nation Pakistan (DNP) programme by the Pakistan Digital Authority (PDA), a federal statutory body of the Government of Pakistan established under the Digital Nation Pakistan Act, 2025. The namespace covers policies, frameworks, technical standards, reference architectures, specifications, schemas, application programming interface contracts, registries and datasets that PDA issues or is statutorily designated to maintain. This document requests registration of the formal Namespace Identifier "dnp" in accordance with RFC 8141. | |||||||||||||
| draft-sokolov-rats-aep-composition-06.txt | ||||||||||||||
| Composing Application-Layer Action Evidence with Remote Attestation Procedures | ||||||||||||||
|
This document sketches a composition pattern in which an application- layer "action evidence package" (AEP) -- a signed action record that can be hash-linked to earlier records and that reports an action taken by an automated (for example, AI-agent) system, the authority under which it was taken, and its outcome -- is treated as Evidence in the sense of the RATS Architecture (RFC 9334) and bound to platform Evidence produced by a hardware root of trust. The intent is that a single Verifier, or a composition of Verifiers, can appraise both the platform state and the application-layer record together, and emit an Attestation Result that a Relying Party can use to reason about _what an automated system reports it did_ and _the appraised state of the platform associated with that record_. The composition does not turn a self-reported action or outcome into an independently observed fact; it prevents the Relying Party from having to rely on an unbound operator-side log alone. This is an individual sketch intended to ask the working group whether the pattern is already covered by existing mechanisms or warrants a short document. | |||||||||||||
| draft-somaratne-scitt-stc-stp-00.txt | ||||||||||||||
| Sovereign Tensor Container (STC) and Provenance (STP) Specifications | ||||||||||||||
|
This document defines the Sovereign Tensor Container (STC-1.0) and Sovereign Tensor Provenance (STP-1.0) specifications. STC-1.0 establishes a strict 64-byte physical memory alignment standard for binary machine learning tensor payloads to enable zero-copy Direct Memory Access (DMA). STP-1.0 defines an embedded cryptographic provenance framework utilizing C2PA profiles, X.509 signature chains, and SCITT-compatible attestations to secure supply-chain integrity for distributed AI models. | |||||||||||||
| draft-somoza-dmsc-atn-agent-trust-negotiation-00.txt | ||||||||||||||
| 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: | |||||||||||||
| draft-song-anp-adp-00.txt | ||||||||||||||
| Agent Description Protocol (ADP) | ||||||||||||||
|
Autonomous AI agents in a decentralized network need a common way to describe their capabilities so that peers can discover and invoke them. The Agent Internet Protocol (AIP) provides name-based datagram delivery between agents identified by agent:// URIs; the Agent Invocation Transport Protocol (AITP) provides reliable invocation and streaming above AIP. This document describes the Agent Description Protocol (ADP), an application-layer convention carried over AITP that defines how agents describe their capabilities, publish those descriptions, and discover peers whose capabilities match a query. ADP defines the Agent Card, a JSON document format that carries an agent's identity, human-readable description, method catalogue, endpoint bindings, skill tags, and operational constraints. ADP also defines three AITP method names — adp.describe, adp.advertise, and adp.discover — through which agents exchange and query Agent Cards at the invocation layer. ADP is intentionally a thin format-and-convention layer: it standardizes the document schema and the exchange methods, but defers reputation, economics, credentials, identity infrastructure, and deployment-specific dissemination mechanisms (DHT topics, GossipSub channels, HTTP well-known URIs) to companion protocols and implementation profiles. | |||||||||||||
| draft-song-anp-aip-00.txt | ||||||||||||||
| Agent Internet Protocol (AIP) | ||||||||||||||
|
The Internet Protocol (IP, RFC 791) provides best-effort datagram delivery between hosts identified by numeric addresses. The Agent Internet Protocol (AIP) provides best-effort datagram delivery between autonomous AI agents identified by agent:// URIs -- human- readable, capability-descriptive names. AIP is designed to serve as the narrow waist of the Agent Network Protocol (ANP) suite, occupying an architectural position analogous to IP in the TCP/IP suite: a minimal common substrate through which upper-layer protocols and link technologies interoperate without direct coupling. This document specifies the AIP message format, addressing model, upper-layer protocol demultiplexing, TLV options, message processing rules, error handling, and interfaces to adjacent protocol layers. Name registration, distributed name resolution, and semantic discovery are provided by a companion resolver service and are outside the scope of this document. | |||||||||||||
| draft-song-anp-aitp-00.txt | ||||||||||||||
| Agent Invocation Transport Protocol (AITP) | ||||||||||||||
|
The Agent Internet Protocol (AIP) provides best-effort, name-based datagram delivery between autonomous AI agents identified by agent:// URIs. The Agent Invocation Transport Protocol (AITP) is a message- framed invocation and streaming transport above AIP. Unlike traditional host-to-host transports (TCP, QUIC) that operate on socket endpoints and byte streams, AITP is natively message- framed, method-aware, and association-aware: its header carries a method name as a first-class field, and its protocol data units are discrete requests, responses, stream chunks, and control segments exchanged between named agents. AITP is not a byte-stream transport; it is an agent-native invocation and streaming transport that carries method names, request/response correlation, flow control, and session semantics natively in its header — so that upper-layer agent protocols need not reinvent them. AITP intentionally includes a minimal generic invocation outcome space (four dispatch- level status codes); richer application semantics belong in the response body or upper-layer protocols. Unlike transport bindings that adapt existing agent protocols to HTTP, gRPC, or MOQT, AITP defines a common invocation substrate directly above AIP, with association state, request-concurrency flow control, and method-aware framing as first-class transport concerns. AITP is best understood as a common invocation substrate above AIP, not as a byte-stream transport analogue. This document specifies the AITP segment format, segment types, status codes, flag bits, TLV options, association state machine, reliability engine, flow control, circuit-breaker mechanism, streaming, orderly close and abort, and interfaces to AIP below and application protocols above. | |||||||||||||
| draft-song-anp-ans-00.txt | ||||||||||||||
| Agent Name System (ANS) | ||||||||||||||
|
This document defines the Agent Name System (ANS), a name registration and resolution protocol for autonomous AI agents in the Agent Network Protocol (ANP) suite. ANS maps agent:// URIs to network-layer peer identifiers, providing the binding between human- readable agent names and the cryptographic peer identities used by the Agent Internet Protocol (AIP) for datagram delivery. ANS defines a Name Record format, four AITP method names for name operations (ans.register, ans.resolve, ans.unregister, ans.lookup), a multi-layer resolution algorithm, and two dissemination mechanisms (GossipSub announcements and DHT storage). ANS supports three addressing modes — unicast, anycast, and channel — over a single URI syntax. ANS is intentionally a narrow name-binding layer: it maps names to peers and tags, but defers capability description to the Agent Description Protocol (ADP), reputation and ranking to companion protocols, and economic anti-spam mechanisms to deployment profiles. | |||||||||||||
| draft-song-cain-header-00.txt | ||||||||||||||
| Network Header Compression for Converged AI Network | ||||||||||||||
|
We envision the scale-up, scale-out, and scale-across networks for AI computing would eventually converged. The draft describes a scheme for L3 packet header compression in converged AI networks where IPv6 are assumed to be the L3 protocol, and a unified fabric supports all kinds of traffic. The header size can be reduced to 8 octets for packets transferred with a single super-node, representing 80% overhead saving. The document discusses the motivation, requirements, benefits, and feasibility in addition to the header format proposal. | |||||||||||||
| draft-song-fann-framework-01.txt | ||||||||||||||
| A Framework for Fast Network Notifications | ||||||||||||||
|
Many network applications, ranging from Artificial Intelligence (AI) / Machine Learning (ML) training and inference to large-scale cloud services, require networks with various combinations of high bandwidth, low delay, low jitter, and minimal packet loss. Meeting these requirements depends on the network's ability to adapt rapidly to faults, signal degradation, and congestion. The companion problem statement describes why existing mechanisms are too slow, too coarse, or too resource-intensive to react within the timescales at which modern forwarding hardware can detect and disseminate intended conditions. This document defines a framework for Fast Network Notifications (FANN). It describes a reference architecture, the functional roles involved in generating and consuming notifications, an information model, delivery and scoping models, procedures for discovery, registration, and subscription, and the integration of fast network notifications with existing Layer 2 to 4 mechanisms. This framework is intended to guide the development of one or more fast network notification protocol specifications. | |||||||||||||
| draft-song-idr-flowspec-classid-filter-01.txt | ||||||||||||||
| BGP Flow Specification by ClassID | ||||||||||||||
|
BGP Flowspec mechanism (BGP-FS) [RFC8955] [RFC8956] propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type named ClassID to support ClassID filtering. | |||||||||||||
| draft-song-ietf-tls-fndsa-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-song-ina-framework-00.txt | ||||||||||||||
| A Unified Bitmap Framework for In-Network Aggregation and Multicast | ||||||||||||||
|
Collective communication is a critical performance bottleneck for distributed deep learning and large model training and inference in data centers for AI computing. In-Network Aggregation (INA) has been identified as an effective accelerating technique to improve its performance. This draft describes a flexible and efficient INA framework for packet routing and forwarding in which a tree is encoded by a bitmap and the same bitmap is reused for data movement in both directions, with the multicast direction realized by a stateless bitmap-driven forwarding mechanism that adopts an encoding and replication behavior similar to BIER. The bitmap encoding is compact, hardware friendly, exact and self-describing, and, being carried per packet, supports highly dynamic endpoint sets without any signaling to the network. The framework is applied to three use cases. The first is AllReduce, used in model training, which performs an in-network aggregation toward the root followed by a multicast of the result back to the workers. The second is the dispatch and combine operations of Mixture-of-Experts (MoE) expert parallelism, which performs a dynamic multicast of tokens to the selected experts followed by an in-network aggregation of the expert outputs. In both use cases a single bitmap-encoded tree drives both directions. The third use case is for reliable multicast, which aggregates the acknowledgments of all multicast receivers in the network to avoid ACK implosion; its ACK- aggregation tree can be either pre-configured, as in the AllReduce use case, or self-installed by the data multicast itself, as in the MoE use case. The draft further analyzes why the base BIER architecture alone cannot realize the framework and identifies the per-packet information an INA encapsulation must carry beyond the endpoint-set encoding: a direction indicator, a job identifier, a sequence number, and an encoding-type indicator. It also examines the efficiency of the endpoint-set encoding at scale, covering hierarchical bitmaps and multiple parallel trees for large dense endpoint sets, node-list encoding for very large domains with few active endpoints, and the trade-offs between header overhead and network processing complexity among these encodings. | |||||||||||||
| draft-song-ippm-ioam-ipv6-support-08.txt | ||||||||||||||
| Supporting IOAM in IPv6 | ||||||||||||||
|
IOAM pre-allocated trace option data fields can be encapsulated in the IPv6 Hop-by-Hop (HbH) Options header as described in RFC 9486. However, due to the potentially large size of the trace data and the location of the HbH Options header in the IPv6 packet, this scheme creates practical challenges for implementation, especially when other extension headers, such as a routing header, are also present and require on-path processing. In addition to IOAM Direct Export (DEX), this document proposes two alternative approaches to address this challenge: separating the IOAM incremental trace data from the IOAM instruction header, or applying the segment IOAM trace data export scheme, depending on the network scenario and application requirements. We discuss the pros and cons of each approach. | |||||||||||||
| draft-song-network-aware-dns-09.txt | ||||||||||||||
| The Architecture of Network-Aware Domain Name System (DNS) | ||||||||||||||
|
This document describes a framework that extends the Domain Name System (DNS) to provide network awareness to applications. The framework enables DNS responses that depend on communication service requirements such as QoS or path, without changes to the format of DNS protocol messages or to application programming interfaces (APIs). The different enhancement methods and use cases are discussed. | |||||||||||||
| draft-song-oauth-ai-agent-collaborate-authz-02.txt | ||||||||||||||
| OAuth2.0 Extension for Multi-AI Agent Collaboration | ||||||||||||||
|
This method extends OAuth 2.0 by adding fields to token and message flows, enabling sub-agents to act as a task group. It simplifies authorization for task groups, avoids repeated interactions between sub-agents and the authorization server, and bounds the authority delegated to the group and to each member while maintaining compatibility with existing OAuth 2.0 workflows. | |||||||||||||
| draft-song-opsawg-ipfix-ecn-03.txt | ||||||||||||||
| Export of ECN Information in IPFIX | ||||||||||||||
|
This document defines a set of IPFIX Information Elements for monitoring Explicit Congestion Notification (ECN), specifically in the context of the Low Latency, Low Loss, and Scalable Throughput (L4S) service. These Information Elements allow network operators to observe ECN codepoint usage within L4S deployments and evaluate the corresponding traffic performance. | |||||||||||||
| draft-song-pce-pcep-sav-03.txt | ||||||||||||||
| Path Computation Element Communication Protocol for Source Address Validation | ||||||||||||||
|
This document presents a method of Path Computation Element (PCE) for Source Address Validation (SAV) in networks. It extends Path Computation Element Communication Protocol (PCEP) to support SAV policy distribution and synchronization between PCEP speakers for threat mitigation for source address spoofing. | |||||||||||||
| draft-song-rtgwg-din-usecases-requirements-02.txt | ||||||||||||||
| Distributed Inference Network (DIN) Problem Statement,Use Cases,and Requirements | ||||||||||||||
|
This document describes the problem statement, use cases, and requirements for a "Distributed Inference Network" (DIN) in the era of pervasive AI. As AI inference services become widely deployed and accessed by billions of users, applications and devices, traditional centralized cloud-based inference architectures face challenges in scalability, latency, security, and efficiency. DIN aims to address these challenges by leveraging distributed edge-cloud collaboration, intelligent scheduling, and enhanced network security to support low- latency, high-concurrency, and secure AI inference services. | |||||||||||||
| draft-song-rtgwg-falcon-00.txt | ||||||||||||||
| Fast Latency and Congestion Notification | ||||||||||||||
|
This document describes a standard-based method for fast latency and congestion notification. By combining in-network telemetry and source routing, it enables a source node to acquire a path's latency and congestion status in less than half baseline RTT. The more timely and accurate telemetry data allow the source node to apply more effective traffic steering and congestion control actions. The method is applicable to both WAN and DCN, and can be realized through existing IETF standards. | |||||||||||||
| draft-song-tls-fndsa-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-song-tsvwg-camp-01.txt | ||||||||||||||
| Consistency-Aware Multipath Transport (CAMP) toward Interactive Multimodal LLM-Based Systems | ||||||||||||||
|
With the prosperity of generative large language models (LLMs), interactive LLM-based services, such as digital humans, have imposed new stringent requirements on low latency and high multimodal consistency. Traditional interactive LLM-based systems typically transmit multimodal content over a single network path, thereby failing to exploit the advantages offered by multipath networks. Even when multipath transport mechanisms are adopted, single-stream encapsulation does not enable differentiated management of heterogeneous modalities. However, naively separating modalities into multiple streams further introduces inter-modal arrival inconsistency. To address these challenges, this document specifies CAMP, a consistency-aware multipath transport design over the Multipath QUIC (MPQUIC) protocol. First, CAMP defines a three-stream separation encapsulation format to support modality-differentiated transmission. Second, it introduces a hierarchical multimodal data management mechanism to coordinate the transmission of correlated data across modality streams. Third, it incorporates a transport- layer consistency-aware multipath scheduler to reduce inter-modal arrival time deviation across network paths. Fourth, it specifies a client-side application-layer alignment mechanism that operates in coordination with the transport scheduler. To the best of our knowledge, this is the first specification to address multipath- enabled multimodal consistency guarantees for interactive LLM-based systems. | |||||||||||||
| draft-soulard-anima-grasp-router-problem-statement-01.txt | ||||||||||||||
| GRASP through routers: a Problem Statement | ||||||||||||||
|
This document analyzes challenges for using the GeneRic Autonomic Signaling Protocol (GRASP) in the context of deployment of services on machines (servers, Virtual Machines, etc) without the network elements, such as routers, needing any support for GRASP by themselves. It analyses issues regarding the discovery mechanism, including discovery across subnets and operation across administrative boundaries, and provides terminology and general considerations for the development of future extensions, profiles, and architectural refinements. | |||||||||||||
| draft-sovereign-svtp-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-spaghetti-grow-downgrade-bgp-community-00.txt | ||||||||||||||
| The DOWNGRADE BGP Community for Denial-of-Service Attack Mitigation | ||||||||||||||
|
This document outlines a method to mitigate Denial of Service (DoS) attacks by using a well-known BGP community named "DOWNGRADE" as signal to neighboring networks to treat traffic destined towards "DOWNGRADE" tagged IP prefixes with low precedence. The "downgrade" strategy offers an appealing alternative to Remote Triggered Blackhole (RTBH) filtering, because RTBH filtering completes the DoS attack and hampers the defender's ability to monitor whether the attack is still ongoing. | |||||||||||||
| draft-spaghetti-grow-rpki-doa-00.txt | ||||||||||||||
| A Profile for Resource Public Key Infrastructure (RPKI) Discard Origin Authorizations (DOA) | ||||||||||||||
|
This document defines a Cryptographic Message Syntax (CMS) profile for Discard Origin Authorizations (DOAs), for use with the Resource Public Key Infrastructure (RPKI). A DOA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block tagged with a specific set of Border Gateway Protocol (BGP) Communities, to signal a request to discard IP traffic destined towards the tagged IP prefix. | |||||||||||||
| draft-sparks-test-async-submission-07.txt | ||||||||||||||
| Testing async submission | ||||||||||||||
|
This draft is submitted only to test the async api submission endpoint | |||||||||||||
| draft-sparysh-pala-audit-00.txt | ||||||||||||||
| PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deployments | ||||||||||||||
|
This document describes PALA-1, a compact binary record format for tamper-evident audit trails produced by AI inference runtimes and robotic control systems. It is designed for a class of deployment defined by three constraints that hold together: the hardware is computationally modest and its cycles are reserved for the workload and the power budget rather than for the audit trail; no external witness is reachable, whether because policy forbids outbound contact or because the platform operates beyond connectivity, so a witness is unavailable by rule or by physics rather than by circumstance; and the right to verify the trail is separated from the right to read what it records. Records form an append-only hash chain. Integrity verification requires no key material of any kind, inspects no record bodies, and costs one hash per record rather than one signature. The format distinguishes three separately answerable questions -- internal consistency, completeness against an external anchor, and existence at a point in time against an external witness -- and states which of the three a given trail actually supports rather than implying all three. The format is frozen at version 1.0 and is described here as it is. This document presents an existing wire format; it does not revise one. Where a deployment does permit an external witness, a chain head may be published to a transparency service such as that of the Supply Chain Integrity, Transparency, and Trust architecture (SCITT, RFC 9943); that path is described but is not part of the hashing contract. | |||||||||||||
| draft-spk-agentproto-llm-stream-00.txt | ||||||||||||||
| A Standard Wire Format for Large Language Model Inference Streaming | ||||||||||||||
|
Large Language Model (LLM) inference endpoints stream response tokens to clients using a fragmented set of vendor-specific application- layer protocols layered on top of standardized transports (HTTP/2, HTTP/1.1, WebSocket, Server-Sent Events). While these transports carry IETF or W3C standardization, the JSON payload schemas, event taxonomies, and framing conventions used within them are entirely vendor-defined, with no RFCs or common specifications governing them. This fragmentation imposes costs across the AI ecosystem. Middleware frameworks and orchestration platforms (LangChain, LiteLLM, Vercel AI SDK, Portkey, Cloudflare AI Gateway) must maintain vendor-specific streaming parsers for every supported provider. Cloud hosting platforms (AWS Bedrock, Azure AI Studio, Google Vertex AI) have each introduced additional proprietary streaming formats. Compliance and observability tooling must be rebuilt per provider. And new inference providers cannot reach framework-dependent developers without custom integration work. This document defines a standard wire format for LLM inference streaming over Server-Sent Events (SSE) on HTTP. It specifies a request envelope media type (application/llm-request+json), a response event taxonomy, and a JSON event envelope schema that enable middleware, orchestration platforms, compliance tooling, and HTTP intermediaries to handle AI inference traffic from any conforming provider using a single protocol contract. SSE transport remains unchanged; only the JSON payload inside it is standardized. The scope of this document is strictly Client/Application to LLM inference endpoint streaming. Agent-to-tool interaction (e.g., MCP) and agent-to-agent communication are out of scope. | |||||||||||||
| draft-sporeba-tsvwg-mobile-l4s-00.txt | ||||||||||||||
| Best Practices for L4S implementation for Mobile Devices | ||||||||||||||
|
This document documents best practices for deployment of Low Latency, Low Loss, and Scalable Throughput (L4S) in mobile devices. It defines the responsibilities of the host operating system, the link- layer (modem and WiFi) subsystems to ensure successful end-to-end low-latency communication. | |||||||||||||
| draft-sriram-sidrops-asra-verification-05.txt | ||||||||||||||
| Autonomous System Relationship Authorization (ASRA) as an Extension to ASPA for Enhanced AS Path Verification | ||||||||||||||
|
An Autonomous System Provider Authorization (ASPA) record authorizes provider ASes of a customer AS. While ASPA-based AS_PATH verification can correctly detect and mitigate route leaks and some forged-origin or forged-path-segment hijacks, it fails to detect some malicious path manipulations for routes that are received from transit providers. This document utilizes a new RPKI object called Autonomous System Relationship Authorization (ASRA) that significantly enhances AS_PATH verification complementing ASPA. ASRA fills in a significant gap in the ASPA method by adding the capability to detect fake links in the AS_PATHs in BGP Updates propagated from providers to customers. ASRA achieves this by allowing an AS to register additional AS relationships, i.e., customers and lateral peers. | |||||||||||||
| draft-srivastava-stir-sip-request-context-00.txt | ||||||||||||||
| SIP Request Context Binding for STIR Connected Identity | ||||||||||||||
|
This document updates RFC 9970. RFC 9970 recommends STIR PASSporTs on re-INVITE and BYE requests after connected identity has been established in a SIP dialog, and states that this prevents spoofed mid-dialog or dialog-terminating events. The baseline PASSporT construction used by RFC 8224 does not bind the SIP request method, CSeq number, Call-ID, or dialog tags. Consequently, a valid PASSporT can remain valid when a fresh signed in-dialog request is transformed into a different SIP request whose authenticated identity fields are unchanged. This document defines the "sipctx" PASSporT type. It binds the SIP request method and dialog/sequence context to the PASSporT. Implementations relying on PASSporT validation for mid-dialog request authenticity use this context binding as specified in this document. | |||||||||||||
| draft-srivastava-websocket-pmce-state-reset-00.txt | ||||||||||||||
| Compression Context State After Refused Messages in WebSocket Per-Message Compression | ||||||||||||||
|
RFC 7692 defines Per-Message Compression Extensions for the WebSocket Protocol, including the "permessage-deflate" extension. When context takeover is in effect, the LZ77 sliding window is retained across messages, so the decompression of one message can depend on the plaintext of earlier messages. RFC 7692 does not state what the sliding window contains after a message has been successfully decompressed but subsequently refused by a check applied to the decompressed plaintext, such as UTF-8 validation, a payload size limit, or an application-level policy. An implementation that retains the refused plaintext in the window violates no stated requirement, yet the content of a refused message can then influence the decompression of a later message that is accepted. This document describes the gap, contrasts it with the corresponding situation in QPACK where RFC 9204 specifies the required behavior, and recommends behavior for implementations. It defines no new protocol element and updates no existing specification. | |||||||||||||
| draft-steele-agent-considerations-01.txt | ||||||||||||||
| Agent Considerations | ||||||||||||||
|
Artificial intelligence (AI) agents consume IETF specifications to generate and operate implementations. This document defines an "Agent Considerations" subsection within the Operations and Management Considerations section described in RFC 5706 and its revision. It provides guidance on schemas, examples, capability descriptions, and verification, with cross-references to agent- specific security and privacy analysis. | |||||||||||||
| draft-steele-vibeslop-00.txt | ||||||||||||||
| Vibeslop Confessions | ||||||||||||||
|
AI Agents have transformed the way internet applications are developed and have introduced a new set of challenges for organizations. This document describes techniques and concepts that are emerging to assist with these challenges, and relates them to concepts already familiar to the internet community. The pace of change in this area is accelerating, and it is anticipated that much of what this document discusses will become outdated quickly; nevertheless, a static publication may prove amusing to future readers, whether machine or human. | |||||||||||||
| draft-stone-adrp-01.txt | ||||||||||||||
| ADRP: Agent Dispute Resolution Protocol | ||||||||||||||
|
This document defines the Agent Dispute Resolution Protocol (ADRP), a wire protocol and state machine for resolving disputes that arise from cryptographically-attested agent-to-agent (A2A) transactions. ADRP is the companion specification to ATXN (draft-stone-atxn-01), which defines what an A2A transaction is. ADRP defines what happens when a party contests one. ADRP severs an equivalence that every prior agentic commerce design has implicitly assumed: that a valid cryptographic proof bundle equals contractual satisfaction. It does not. Conduit-style cryptographic verifiers prove that an agent took specified actions; they do not prove that those actions satisfied the principal's Intent Mandate. ADRP bifurcates disputes into a *cryptographic class* (resolvable by code from the proof bundle and mandate chain) and a *semantic class* (resolvable only against pre-committed machine- readable acceptance criteria, with arbitration escalation when those criteria are absent or under-specified). ADRP introduces the *Arbitration Mandate* as an ADRP extension that can be cryptographically linked to AP2 Intent/Cart/Payment Mandates or to an ATXN Standing Token. It is not an AP2 core mandate. The Arbitration Mandate records the principal's pre-committed dispute policy and is designed to support a written arbitration agreement where applicable; enforceability remains jurisdiction- and fact- specific. ADRP defines a *counter-attestation override pattern* in which a signed RulingBundle supersedes a Conduit ProofBundle by a signing- time precedence rule rather than by mutation. Both the original attestation and the override are preserved forever in the hash chain; "override" is a verification-time computation, not a write. Companion specifications: * *ATXN* (draft-stone-atxn-01): defines the A2A transaction primitive that ADRP resolves disputes over * *AIVS* (draft-stone-aivs-01): cryptographic audit-trail substrate for proof bundles * *VCAP* (draft-stone-vcap-01): verified-commerce escrow rails consumed by ADRP EscrowDirectives * *ATEP* (draft-stone-atep-01): trust passports referenced by Standing Tokens in ADRP | |||||||||||||
| draft-stone-aivs-01.txt | ||||||||||||||
| AIVS: Agentic Integrity Verification Standard | ||||||||||||||
|
The Agentic Integrity Verification Standard (AIVS) defines a portable, self-verifiable archive format for cryptographic proof of AI agent sessions. An AIVS bundle is a gzip-compressed tar archive containing a SHA-256 hash-chained audit log, an Ed25519 digital signature over the chain, a machine-readable manifest, and an embedded verification script that requires only Python 3 standard library to execute. AIVS also defines *AIVS-Micro*: a minimal 6-field attestation (~200 bytes) for continuous monitoring, embedded widgets, and API responses where a full session bundle is not required. AIVS enables any party to independently verify that: | |||||||||||||
| draft-stone-aref-00.txt | ||||||||||||||
| Agent Referral and Escrow Framework (AREF) | ||||||||||||||
|
This document specifies the Agent Referral and Escrow Framework (AREF), a protocol for cryptographically attributed agent-to-agent referrals, escrow-bound commission commitments, and dual-rail financial settlement in multi-agent computing environments. As autonomous software agents increasingly transact with one another to acquire capabilities and coordinate work, no standardized mechanism exists for recording how one agent introduced another to a platform or service, binding that introduction to a financial commitment, or settling the resulting commission across heterogeneous payment infrastructure. AREF addresses this gap by defining: a portable Ed25519-signed attribution proof for referral chains of arbitrary depth; the semantics and payload schema of the SwarmSync- Referrer HTTP header used to bind a referrer to an escrow at hold- time; a commission vesting model tied to escrow finality rather than enrollment; a unified settlement finality signal operable over both traditional financial infrastructure (Stripe Connect) and cryptographic payment channels (X402); and the swarm_meta JSON embedding mechanism through which referral codes propagate across agent ecosystems without human involvement. This document is intended for implementers of agent orchestration platforms, payment service operators, and designers of multi-agent economic systems. | |||||||||||||
| draft-stone-atep-02.txt | ||||||||||||||
| ATEP: Agent Trust and Execution Passport | ||||||||||||||
|
This document specifies the *Agent Trust & Execution Passport (ATEP)*, an open standard for representing an AI agent's verifiable track record of work across marketplaces and platforms. ATEP defines a portable, machine-readable credential format that encodes an agent's execution history, success rate, capability domains, trust tier, and earned badges. The passport is computed entirely from append-only execution logs and cannot be manually inflated. ATEP is the *trust layer* for agent-to-agent commerce. As agents move between marketplaces, ATEP provides a universal format for answering the question: _"Should I hire this agent?"_ | |||||||||||||
| draft-stone-atxn-01.txt | ||||||||||||||
| ATXN: Agent-to-Agent Transaction Definition Protocol | ||||||||||||||
|
This document defines a canonical, defensible, machine-checkable primitive for an Agent-to-Agent (A2A) transaction. It establishes the bundle of cryptographically signed elements that constitute a recorded value exchange between two software agents acting as instruments of identified principals, the conformance tiers that determine which elements are required, the rail-specific Profiles that map the bundle to existing payment infrastructure, and the two- tier validity model that distinguishes externally-adjudicable transactions from operationally-valid uncontested exchanges. ATXN is the foundational legal and technical primitive for escrow, dispute resolution, audit, and liability allocation in agentic commerce. It is designed to produce evidence that can be mapped to existing contract and agency frameworks without requiring agent legal personhood. Whether a Bundle has legal effect is jurisdiction- and fact-specific; this document does not provide a legal conclusion. It maps directly to AP2, Stripe ACP, Visa TAP, Mastercard Agent Pay, and x402 as Profiles of a single canonical bundle. Companion specifications: * *AIVS* (draft-stone-aivs-01): cryptographic audit-trail substrate that ATXN bundles inherit from * *VCAP* (draft-stone-vcap-01): verified-commerce escrow rails that consume ATXN bundles * *ATEP* (draft-stone-atep-01): trust passports that bind agents to capacity-attested principals * *ADRP* (draft-stone-adrp-01): dispute resolution protocol invoked when an ATXN bundle enters the disputed state | |||||||||||||
| draft-stone-spring-mpte-sr-03.txt | ||||||||||||||
| Multipath Traffic Engineering for Segment Routing | ||||||||||||||
|
This document describes a mechanism to achieve Multipath Traffic Engineering for Segment Routing based networks. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/astone282/draft-stone-spring-mpte-sr. | |||||||||||||
| draft-stone-swarmscore-v1-01.txt | ||||||||||||||
| SwarmScore V1: Volume-Scaled Agent Reputation Protocol | ||||||||||||||
|
SwarmScore V1 is a transparent, community-governed open standard for agent reputation scoring in open marketplaces. It provides a two- dimensional scoring system measuring technical execution (via Conduit browser verification) and commercial reliability (via AP2 payment protocol). Volume-scaled metrics reward consistent high-volume performance. Cryptographically signed certificates enable decentralized trust. This document specifies the complete V1 standard including formula, trust tiers, escrow integration, wire format, governance model, legal framework, implementation guidance, V2 roadmap, competitive analysis, and known limitations, with a governance roadmap for transitioning canary prompt curation to a multi-stakeholder community registry. | |||||||||||||
| draft-stone-swarmscore-v2-canary-01.txt | ||||||||||||||
| SwarmScore V2 Canary: Safety-Aware Agent Reputation Protocol | ||||||||||||||
|
SwarmScore V2 Canary extends the SwarmScore V1 two-pillar reputation protocol with a third dimension: Safety, measured via controlled canary prompt testing. This document specifies five formally- analyzed design decisions for the canary testing subsystem: mandatory testing thresholds, hybrid response classification (pattern matching plus opaque LLM ensemble), dedicated test session placement, prompt library composition and rotation, and session isolation to reduce buyer-harm risk. V2 Canary is backwards-compatible with V1: all V1 scores remain unchanged. The five-pillar formula covers Technical Execution (300 pts), Commercial Reliability (300 pts), Operational Depth (150 pts), Safety (100 pts), and Identity Verification (150 pts). | |||||||||||||
| draft-stone-vcap-02.txt | ||||||||||||||
| VCAP: Verified Commerce for Agent Protocols | ||||||||||||||
|
This document specifies the *Verified Commerce for Agent Protocols (VCAP)*, an open standard for settling financial transactions between autonomous AI agents using cryptographically verifiable proof of work delivery. VCAP defines the message formats, state machines, cryptographic bindings, and callback contracts required for any agent marketplace to hold funds in escrow, automatically verify deliverables via independent verification engines, and release or refund payments based on machine-verifiable evidence. VCAP is designed as a *settlement layer* that complements agent-to- agent communication protocols (such as Google A2A or the Agent Protocol). Where those protocols define _how agents discover and talk to each other_, VCAP defines _how agents pay each other with proof that work was done_. | |||||||||||||
| draft-stone-vcap-ap2-binding-01.txt | ||||||||||||||
| VCAP-AP2 Binding: Verified Delivery Settlement for the Agent Payments Protocol | ||||||||||||||
|
This document defines a binding between Verified Commerce for Agent Protocols (VCAP) and the Agent Payments Protocol (AP2). AP2 supplies agent-commerce authorization evidence through IntentMandate, CartMandate, and PaymentMandate artifacts. VCAP supplies delivery verification, settlement evidence, escrow directives, timeout handling, and dispute handoff. This revision deliberately does not model AP2 as an escrow or settlement state machine. Current AP2 positions itself as an authorization and security layer used within a surrounding commerce protocol, including Universal Commerce Protocol (UCP). Accordingly, this binding references AP2 mandates by cryptographic digest or opaque identifier and leaves payment capture, refund, and settlement transitions to the commerce protocol and payment rail. | |||||||||||||
| draft-storey-smtp-client-id-21.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-su-sidrops-rpki-rp-incremental-validation-00.txt | ||||||||||||||
| A Publication-Point-Based Incremental Validation Procedure for RPKI Relying Parties | ||||||||||||||
|
RPKI Relying Parties commonly perform top-down validation of the RPKI certificate tree after repository synchronization. Existing repository synchronization mechanisms can update the local repository incrementally, avoiding a complete retrieval of all repository data. However, after such an incremental repository update, an RP implementation may still repeat full top-down validation over the local repository. It means that the RP starts from the trust anchors and performs complete validation checks for all currently reachable RPKI objects encountered during the traversal. Repeating such validation for objects whose validation inputs have not changed can introduce unnecessary validation overhead. This document specifies a publication-point-based incremental validation procedure for RPKI RPs. The procedure is intended to reduce redundant validation work after incremental repository synchronization, while preserving the same validation result as a full top-down validation over the same repository snapshot, trust anchor set, validation policy, and validation time. This document does not change the syntax or validation semantics of any RPKI object. | |||||||||||||
| draft-su-sidrops-rpki-rp-requirements-00.txt | ||||||||||||||
| Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties | ||||||||||||||
|
This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI). It cites requirements that appear in several RPKI RFCs and related specifications, making it easier for implementers to become aware of these requirements. This document updates [RFC8897] to reflect changes to the requirements and guidance specified in the relevant RPKI standards, including updates to repository synchronization, certificate and CRL processing, signed object validation, validated cache distribution, local control, and operational and manageability support for RP software. This document is expected to be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein. | |||||||||||||
| draft-subbiah-ipv7-00.txt | ||||||||||||||
| IPv7: Identity-Centric Network Protocol for Security,Proxy Mitigation,and Operability | ||||||||||||||
|
This document specifies a network-layer protocol, IPv7, that extends the Internet Protocol model with an identity-carrying address form and an origin-validation mechanism intended to mitigate abuse of residential proxy infrastructure. IPv7 replaces purely numerical source addressing with a hierarchical identity string and a Variable- Length Identity Block (VLIB) that carries an Ephemeral Identity Token (EIT), provider and tenant identifiers, role/policy signalling, and an Origin Signature verifiable by the originating provider. The protocol enables routers to apply policy and reputation signals at the network layer while limiting disclosure of a subscriber's long- term identity to intermediate systems. This document addresses growing security challenges in Internet-connected devices (IoT), including smart TVs, appliances, and other residential endpoints that are vulnerable to residential proxy exploitation and botnet infection. | |||||||||||||
| draft-subthought-locus-uri-scheme-00.txt | ||||||||||||||
| The Locus URI Scheme: A 256-bit Interplanetary Addressing and Resolution Framework | ||||||||||||||
|
This document defines the "locus" URI scheme, a hierarchical interplanetary addressing system that encodes both astronomical location and network routing information within a fixed 256-bit structure. The scheme enables deterministic resolution of named endpoints into IPv6-compatible network addresses and supports future interplanetary networking without reliance on centralized lookup systems. The Locus scheme introduces a unified address format spanning five tiers: star system, orbital position, planetary body, network domain, and host identifier. The upper 128 bits encode astronomical location; the lower 128 bits encode IPv6-compatible network identity. For present Earth-based deployments, the scheme resolves to standard HTTPS URLs via DNS. Future extensions accommodate delay-tolerant networking across Lunar, Martian, and interstellar distances. | |||||||||||||
| draft-sullivan-cfrg-raae-03.txt | ||||||||||||||
| Random-Access Authenticated Encryption | ||||||||||||||
|
This document defines random-access authenticated encryption (raAE), a primitive that partitions a message into an indexed sequence of segments that can be encrypted and decrypted independently and in any order. It also specifies SEAL (Segmented Encryption and Authentication Layer), a parameterized construction that defines a family of concrete raAE instantiations, one for each valid choice of an Authenticated Encryption with Associated Data (AEAD) algorithm, a key derivation function (KDF), and associated parameters. SEAL supports immutable (write-once), append-only, and mutable (in- place ciphertext rewrite) operations, each with per-segment authentication. A separately configured snapshot authenticator can additionally authenticate the complete, indexed segment set. The document also defines the security notions of raAE, specifies the requirements for conforming constructions, and analyzes SEAL against those requirements. Concrete cipher suites, serialization layouts, and test vectors for SEAL are specified in a companion document. | |||||||||||||
| draft-sullivan-mls-attachments-01.txt | ||||||||||||||
| Encrypted Attachments for MLS | ||||||||||||||
|
This document defines random-access authenticated encryption of large write-once files for Messaging Layer Security (MLS) groups. A file is encrypted so that a receiver can decrypt and authenticate any byte range without processing the whole file. The encryption is SEAL- attachment, SEAL's named write-once attachment scheme (raAE), parameterized by the AEAD and key derivation function of the group's MLS cipher suite and keyed from the MLS exporter. The encrypted bytes are carried by any means, and a recipient needs only a small reference (the object's identifier, length, and snapshot value, and an optional locator) to fetch, key, and verify the object. Carrying that reference in an MLS message attributes the object to the member that sent the message. MLS application messages cannot carry large files, and existing attachment encryption produces an opaque, immutable blob with no partial access. This extension supplies the random-access layer those uses need. | |||||||||||||
| draft-sullivan-seal-concrete-00.txt | ||||||||||||||
| SEAL Cipher Suites and Instantiations | ||||||||||||||
|
SEAL (Segmented Encryption and Authentication Layer) is a construction that realizes random-access authenticated encryption (raAE), a primitive that partitions a message into an indexed sequence of independently accessible, individually authenticated segments. This document specifies concrete, interoperable instantiations of SEAL for particular uses, built from previously specified primitives, and applies the analysis in a companion document to state their security properties and safe usage limits. | |||||||||||||
| draft-sullivan-tls-signed-ech-updates-02.txt | ||||||||||||||
| Authenticated ECH Config Distribution and Rotation | ||||||||||||||
|
Encrypted ClientHello (ECH) requires clients to have the server's ECH configuration before connecting. Currently, when ECH fails, servers can send updated configurations but clients cannot authenticate them unless the server has a valid certificate for the public name, limiting deployment flexibility. This document specifies a new mechanism for authenticating ECH configurations. Servers include additional information in their initial ECH configurations, which enables clients to authenticate updated configurations without relying on a valid certificate for the public name. | |||||||||||||
| draft-sullivan-tls-xof-schedule-00.txt | ||||||||||||||
| XOF-based key schedules for TLS 1.3 | ||||||||||||||
|
TLS 1.3 runs its entire key schedule on HKDF over SHA-2. This document defines an extension that replaces that schedule with one built on an extendable-output function (XOF): the negotiated KDF governs every derivation, the Finished and binder MACs, and the transcript hash, so no SHA-2 remains in the key schedule. The cipher suites, AEAD algorithms, state machine, and record layer are unchanged, and a connection without the extension uses HKDF as today. Two KDFs are defined, SHAKE256 and the reduced-round TurboSHAKE256. This document updates RFC 9258. | |||||||||||||
| draft-sun-nmop-agent-lifecycle-management-00.txt | ||||||||||||||
| The requirements of Agent Lifecycle Management | ||||||||||||||
|
As agents evolve from auxiliary analysis toward autonomous decision- making and task execution, their operation involves multiple dynamic factors, including models, knowledges, metrics, tools, permissions, behaviors, and collaborative relationships. Traditional management methods are no longer sufficient to ensure their secure and stable operation. This draft proposes an agent lifecycle management requirement covering registration and publication, deployment and operation, continuous operations, capability evolution, deactivation, and retirement. It analyzes key management requirements related to assets, capabilities, knowledge, tools, identity and authorization, operational evaluation, auditing, and version evolution and retirement, providing the unified management, continuous governance, and large-scale deployment of agents. | |||||||||||||
| draft-sun-nmrg-hybrid-switching-14.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sun-rats-composite-eat-00.txt | ||||||||||||||
| An EAT Profile for Composite Platform Attestation | ||||||||||||||
|
This document defines an Entity Attestation Token (EAT) profile for composite platform attestation. A Lead Attester, such as a platform Root of Trust, produces a single signed composite EAT that carries its own measurements and cryptographic digests committing to detached, native evidence collected from peripheral sub-attesters. The full sub-attester evidence -- Security Protocol and Data Model (SPDM) signed measurements, device-emitted EATs, or SPDM-carried TCG DICE Concise Evidence -- is conveyed verbatim as detached Claims-Sets in a Detached EAT Bundle. This yields a single, freshness-bound, platform-scoped attestation artifact that a Verifier can appraise against platform-composition endorsements, even when the evidence is collected and conveyed by an untrusted mediator. | |||||||||||||
| draft-sun-single-stack-100-50-01.txt | ||||||||||||||
| The Single-Stack 100/50 Principle: Formal Definitions for IPv4 Retirement in Dual-Stack Networks | ||||||||||||||
|
The Single-Stack 100/50 Principle defines two independent, formally derivable consequences of retiring the IPv4 protocol stack in a dual- stack (IPv4 + IPv6) network environment: (1) 100% elimination of executable attacks attributable to IPv4 under the document's definition, and (2) an exact 50% reduction in the count of concurrently exposed network-layer protocol-stack surfaces when IPv4 is retired, stated by the Principle as a minimum structural floor. The analysis is bounded to the functional Layer 3 scope and parameter universe U_3 defined in this document. Within that premise, Axiom 0 and Axioms 1-15 stipulate protocol independence, operational state transitions, traffic termination, addressing/routing domains, protocol-associated control and resolution functions, header- processing paths, and protocol-specific vulnerability execution. Theorem I follows by removal of the necessary IPv4 Layer 3 execution precondition for every IPv4-attributable attack. Theorem II follows by direct enumeration of two concurrently exposed protocol-stack surfaces before retirement and one after retirement. Neither theorem depends on empirical attack volume, incident frequency, or statistical inference, and neither theorem claims that IPv6 is inherently more secure than IPv4. | |||||||||||||
| draft-sun-ssh-composite-sigs-03.txt | ||||||||||||||
| Composite ML-DSA Signatures for SSH | ||||||||||||||
|
This document describes the use of PQ/T composite signatures for the Secure Shell (SSH) protocol. The composite signatures described combine ML-DSA as the post-quantum part and the elliptic curve signature schemes ECDSA, Ed25519 and Ed448 as the traditional part. | |||||||||||||
| draft-sunnetci-ntcf-format-00.txt | ||||||||||||||
| The NTCF Network and Telemetry Compression Format | ||||||||||||||
|
This document specifies NTCF (Network and Telemetry Compression Format), a self-describing, columnar, append-friendly binary container for cybersecurity and network telemetry such as flow records, honeypot events, and web access logs. Unlike general- purpose byte compressors, NTCF models the semantics of telemetry -- IP addresses, autonomous system numbers, ports, country codes, event types, and timestamps -- as typed columns and applies semantic encodings (dictionary, delta, delta-of-delta, run-length, frame-of- reference bit packing, and variable-length integers) before a conventional entropy compression stage. NTCF embeds per-column zone-map statistics and Bloom filters so that point lookups and analytical predicates can be evaluated by reading only the columns and segments that can possibly match, without decompressing the entire file. This document defines the on-disk octet layout (format version 1), the encoding catalogue, the reading and crash-recovery algorithms, a resource-limit model, security considerations, and an IANA media-type registration. | |||||||||||||
| draft-sunyi-hacp-protocol-00.txt | ||||||||||||||
| HACP: A Capability-Contract Protocol for AI Agents and Edge Hardware | ||||||||||||||
|
HACP (Hardware Agent Capability Protocol) is a JSON-RPC 2.0 transport- agnostic protocol that lets a Large Language Model (LLM) agent — or any program acting on its behalf — discover, plan, execute, observe, and audit operations on physical edge hardware (GPIO, I2C, UART, sensors, system telemetry, files) through a single, stable, security-checked surface. HACP sits below higher-level agent protocols such as the Model Context Protocol and above the operating system. It is designed to make heterogeneous edge devices interoperable with diverse AI agent implementations without requiring either side to know the details of the other. This document specifies the HACP wire format, core methods, lifecycle, error model, security requirements, and audit semantics. Streaming, attestation, and MCP-bridge profiles are sketched as optional or preview. | |||||||||||||
| draft-surampudi-wtx1-01.txt | ||||||||||||||
| WTX-1: Cross-Domain Context Preservation Protocol | ||||||||||||||
|
This document defines WTX-1, a protocol for preserving pseudonymous user context across web domains that are operated by, or on behalf of, the same organization and that have mutually opted into the exchange. The protocol operates only after explicit user consent and does not use third-party cookies, browser fingerprinting, or collection of direct identifiers by default. Identifiers are pseudonymous, not anonymous: they can be linked to application-level identities by the deploying organization and may constitute personal data under applicable law. WTX-1 transfers context using an encrypted, authenticated, destination-bound, single-use token carried in the URL fragment. Tokens are issued and verified server side, with atomic replay consumption, DNS-based domain authorization, and short-lived server- signed write grants that authorize browser write operations without trusting caller-supplied tenant claims. This revision (draft-02) replaces the signed-cleartext token format of draft-01 with a sign-then-encrypt construction, specifies write grants and replay-consumption ordering, defines the consent lifecycle including withdrawal and asynchronous cancellation, adds storage retention limits and user inspection, reset, and revocation controls, and rescopes the document's security, privacy, and performance claims to match the reviewed reference implementation. A complete change log appears in Appendix A. | |||||||||||||
| draft-sury-dnsop-parent-centric-resolver-03.txt | ||||||||||||||
| Parent-Centric Delegation Handling in DNS Resolvers | ||||||||||||||
|
This document specifies an optional parent-centric behavioral model for DNS recursive resolvers, in which delegation decisions are always based on the NS RRset (or DELEG RRset) received from the parent side of a zone cut and are never overwritten by child-side NS data. The parent-centric model eliminates the "two sources of truth" problem inherent in the current DNS delegation design, closes the Ghost Domain and Phoenix Domain attack vectors, provides deterministic behavior in the presence of parent/child NS mismatches, and enables resolvers to safely accept sibling (out-of-bailiwick) glue by scoping delegation information to individual zone cuts. It also provides the behavioral foundation required for deployment of the DELEG extensible delegation mechanism. This document updates [RFC1034] and [RFC1035]. | |||||||||||||
| draft-sury-dnsop-rrsig-refused-00.txt | ||||||||||||||
| Refusing DNS Queries That Have QTYPE=RRSIG | ||||||||||||||
|
The Domain Name System (DNS) allows a query with QTYPE=RRSIG. Such a query has no useful answer. RRSIG resource records are meaningful only together with the resource records they cover, so a response can carry no more than an arbitrary subset of the signatures present at the query name. This document specifies that DNS responders refuse queries with QTYPE=RRSIG, and that DNS requestors do not send them. It supplies the guidance that [RFC8482] left unspecified. | |||||||||||||
| draft-sury-dnsop-tsig-clarify-00.txt | ||||||||||||||
| Handling Verification Failures of TSIG-Signed DNS Messages | ||||||||||||||
|
Transation Signatures (TSIG) provide a standard mechanism to sign DNS messages, so that the authenticity of messages can be verified by the system that receives them. This document updates the required behaviour of a system that receives a signed message that fails verification. | |||||||||||||
| draft-svensson-credential-oidc-bridge-02.txt | ||||||||||||||
| Credential Presentation to OIDC Claims Bridge | ||||||||||||||
|
This document defines a mechanism for conveying digital credential claims via OpenID Connect (OIDC). It specifies how an OpenID Provider (OP) that collects credentials from a wallet can expose those claims to Relying Parties as standard OIDC claims, enabling existing OIDC deployments to consume digital credentials without implementing any wallet-facing presentation protocol. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/masv3971/rfc_credential_oidc_bridge. | |||||||||||||
| draft-svg-tiny-ps-abrotman-12.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-swaminathan-da-00.txt | ||||||||||||||
| Domain Authority (DA): A DNS-Designated Service Endpoint for Domain Information | ||||||||||||||
|
This document specifies a minimal standard by which a domain designates, via a single DNS record, a Domain Authority (DA) as a service endpoint accessible at a well-known HTTPS URI. The DA exposes five namespaces for capabilities beyond what DNS can natively deliver: atomic record bundles, public key distribution, domain- defined APIs, authenticated access, and private domain control verification. The standard is organized in three layers. The Designation Layer specifies how a domain publishes a DNS record that points to its DA. The Retrieval Layer specifies the five namespaces through which consumers access domain information. The Trust Layer specifies how consumers establish confidence in the DA and its responses. The standard preserves full backward compatibility with existing DNS resolution. It requires no changes to DNS resolvers, no new DNS record types, and no ecosystem-wide coordination. Any domain can adopt unilaterally and gain immediate operational benefit. | |||||||||||||
| draft-swaminathan-dka-framework-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-sweeney-wimse-credential-delegation-00.txt | ||||||||||||||
| Credential Delegation Protocol for AI Agents in Multi-System Environments | ||||||||||||||
|
Autonomous AI agents increasingly require access to protected resources across multiple service providers on behalf of human users. Existing OAuth 2.0 extensions address individual aspects of this problem (token exchange, proof-of-possession, and structured authorization) but no current specification defines how these mechanisms compose into a coherent credential delegation framework for AI agents. This document specifies the Credential Delegation Protocol: a profile of OAuth 2.0 Token Exchange (RFC 8693), Demonstrating Proof-of- Possession (RFC 9449), Rich Authorization Requests (RFC 9396), and Client-Initiated Backchannel Authentication (OpenID Connect CIBA) that enables human users to delegate scoped, attenuated credentials to AI agents operating across heterogeneous service providers. The protocol defines: agent identity lifecycle management using ephemeral key pairs; capability-shaped delegation tokens bound to specific operations and resources; credential wrapping semantics that prevent exposure of underlying OAuth tokens to agents; consent-gated delegation flows for asynchronous agents; real-time cascading revocation; and tamper-evident audit chains. This document does not define new token formats, new OAuth grant types, or modifications to existing authorization server behavior. It specifies how existing mechanisms are combined to achieve secure, auditable credential delegation for AI agents. | |||||||||||||
| draft-sweetser-bcp-rpki-ca-02.txt | ||||||||||||||
| Operational Guidelines for RPKI Delegated Certification Authorities | ||||||||||||||
|
This document provides operational guidelines for Resource Public Key Infrastructure (RPKI) delegated Certification Authorities (CAs) and registry operators managing such delegations. It addresses common operational issues including CA availability problems, publication quality issues, and lifecycle management. The guidelines aim to improve the overall health and efficiency of the RPKI ecosystem by establishing best practices for CA operations and delegation management. | |||||||||||||
| draft-swhited-contra-tags-05.txt | ||||||||||||||
| Metadata for Called Folk Dances | ||||||||||||||
|
This document defines metadata tags for describing aspects of Contra, Square, and other traditional called folk dances. These tags are meant for archivists as well as modern day callers of traditional dances. | |||||||||||||
| draft-swhited-mka-stems-13.txt | ||||||||||||||
| Matroska Stem Files | ||||||||||||||
|
This document defines a multi-track profile of the Matroska container format for distributing stems for live-mixing by DJs. It is intended to be used by DJ applications, Digital Audio Workstations, and multi- track recorders while remaining backwards compatible with existing media players. | |||||||||||||
| draft-swhited-ogg-skeleton-02.txt | ||||||||||||||
| Ogg Skeleton | ||||||||||||||
|
Ogg Skeleton defines a logical bitstream that provides structuring information for multitrack Ogg files. It provides clues for synchronization and content negotiation including language selection. It also provides keypoint indices for optimal seeking over high- latency connections or in time-critical scenarios. | |||||||||||||
| draft-swhited-ogg-stems-05.txt | ||||||||||||||
| Ogg Stem Files | ||||||||||||||
|
This document defines a multi-track profile of the Ogg container format for storing for storing stems for use by DJ applications while remaining backwards compatible with existing media players. | |||||||||||||
| draft-sz-dmsc-iaip-02.txt | ||||||||||||||
| Intent-based Agent Interconnection Protocol at Agent Gateway | ||||||||||||||
|
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. | |||||||||||||
| draft-tailhardat-incident-management-noria-01.txt | ||||||||||||||
| Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design | ||||||||||||||
|
Operational efficiency in incident management in networking requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge Graphs (KG) can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management Knowledge Graph (ITSM-KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. | |||||||||||||
| draft-tailhardat-nmop-incident-management-noria-05.txt | ||||||||||||||
| Knowledge Graphs for Enhanced Cross-Operator Incident Management and Network Design | ||||||||||||||
|
Operational efficiency in incident management in networking requires correlating and interpreting large volumes of heterogeneous technical information. Knowledge Graphs (KG) can provide a unified view of complex systems through shared vocabularies. YANG data models enable describing network configurations and automating their deployment. However, both approaches face challenges in vocabulary alignment and adoption, hindering knowledge capitalization and sharing on network designs and best practices. To address this, the concept of a IT Service Management Knowledge Graph (ITSM-KG) is introduced to leverage existing network infrastructure descriptions in YANG format and enable abstract reasoning on network behaviors. The key principle to achieve the construction of such ITSM-KG is to transform YANG representations of network infrastructures into an equivalent knowledge graph representation, and then embed it into a more extensive data model for Anomaly Detection (AD) and Risk Management applications. In addition to use case analysis and design pattern analysis, an experiment is proposed to assess the potential of the ITSM-KG in improving network quality and designs. | |||||||||||||
| draft-tan-ccamp-onco-control-framework-00.txt | ||||||||||||||
| A Control Framework for Optical Networks and AI Computing Orchestration (ONCO) | ||||||||||||||
|
This document defines the control framework for Optical Networks and AI Computing Orchestration (ONCO). The framework is designed to achieve synergistic management of optical network (e.g., fgOTN, OXC) and computing resources for high-performance AI workloads. It specifies a multi-stakeholder service model, a layered architecture across management, control, and data planes, and a set of functional components. The ONCO framework supports both centralized and distributed orchestration models to enable proactive resource reservation and deterministic optical circuit provisioning. | |||||||||||||
| draft-tan-ccamp-onco-problem-statement-00.txt | ||||||||||||||
| Optical Networks and AI Computing Orchestration (ONCO) Problem Statement,Use Cases and Requirements | ||||||||||||||
|
Distributed artificial intelligence (AI) computing is increasingly deployed across geographically dispersed AI data centers (AIDCs) to meet the scale and performance demands of modern AI workloads. In such environments, the efficiency of distributed training and inference depends critically on tight coordination between optical transport networks and compute orchestration systems. However, today's infrastructure operates with isolated control planes: optical networks lack awareness of dynamic compute requirements, while compute schedulers have no visibility into real-time network conditions such as latency, bandwidth, or congestion. This decoupling leads to suboptimal resource utilization, degraded job performance, and inefficient scaling. This draft presents the problem statement, outlines two representative use cases: distributed AI training and distributed AI inference, and specifies the requirements for Optical Networks and AI Computing Orchestration (ONCO). The goal is to enable bidirectional awareness, joint resource abstraction, and synchronized control across the compute-optical boundary, thereby supporting intent- driven, end-to-end provisioning of AI services over wide-area optical infrastructures. | |||||||||||||
| draft-tang-ipv4plus-17.txt | ||||||||||||||
| IPv4+ The Extended Protocol Based On IPv4 | ||||||||||||||
|
This document specifies version 4+ of the Internet Protocol (IPv4+). IPv4 is very successful,simple and elegant. continuation and expansion of the IPv4 is necessary. Existing systems, devices only need to upgrade the software to support IPv4+, without the need to update new hardwares,saving investment costs. Ipv4+ is also an interstellar Protocol, so the Internet will evolve into a star Internet. | |||||||||||||
| draft-tantsura-bess-evpn-route-type-exp-use-00.txt | ||||||||||||||
| Reservation of EVPN Route Types for Experimental Use | ||||||||||||||
|
This document reserves codepoints in the EVPN Route Type registry for experimental use to enable implementations to carry out development and test of new EVPN features. It updates RFC7432 to modify the registration policy for the EVPN Route Type registry. | |||||||||||||
| draft-tantsura-bess-evpn-unreachability-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tantsura-fann-yang-00.txt | ||||||||||||||
| A YANG Data Model for Fast Network Notifications | ||||||||||||||
|
This document defines a YANG data model to Fast Network Notifictions. | |||||||||||||
| draft-tantsura-idr-unreachability-safi-06.txt | ||||||||||||||
| BGP Unreachability Information SAFI | ||||||||||||||
|
This document defines a new BGP Subsequent Address Family Identifier (SAFI) called "Unreachability Information" that allows the propagation of prefix unreachability information through BGP without affecting the installation or removal of routes in the Routing Information Base (RIB) or Forwarding Information Base (FIB). This mechanism enables network operators to share information about unreachable prefixes for monitoring, debugging, and coordination purposes while maintaining complete separation from the active routing plane. | |||||||||||||
| draft-taylor-dtn-dpp-01.txt | ||||||||||||||
| DTN Peering Protocol | ||||||||||||||
|
This document specifies the DTN Peering Protocol (DPP), an inter- domain routing protocol for the Delay-Tolerant Networking (DTN) ecosystem. DPP facilitates the exchange of reachability information between distinct Administrative Domains (ADs), enabling inter-domain routing across the Solar System DTN. DPP separates the control plane from the data plane: a DPP speaker need not be a gateway that forwards bundles, allowing centralized route controllers or orchestration systems to participate in peering on behalf of the gateways they manage. DPP harmonizes the two DTN addressing schemes -- ipn (integer-based) and dtn (URI-based) -- into a unified routing framework. It leverages DNS for identity verification and supports both reactive routing and scheduled contact windows for deep-space networks. | |||||||||||||
| draft-taylor-dtn-echo-service-01.txt | ||||||||||||||
| BPv7 Echo Service | ||||||||||||||
|
This document specifies an echo service for Bundle Protocol Version 7 (BPv7) networks. An echo service receives bundles at a well-known endpoint and replies to each with a response bundle that returns the payload to the originator. This enables round-trip time measurement and end-to-end connectivity verification in Delay-Tolerant Networks. This document requests IANA allocation of a well-known IPN service number for the echo service. | |||||||||||||
| draft-tayyebi-fcl-dcop-gtl-00.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-tcr-tef-00.txt | ||||||||||||||
| Triageable Evidence Format (TEF) | ||||||||||||||
|
This document defines the Triageable Evidence Format (TEF), a YAML- based format for structured vulnerability evidence submission. TEF provides a standard way for security researchers to describe software defects so that triage systems, whether human or automated, can classify them without ambiguity. TEF combines YAML data structure with a Given/When/Then evidence model. Each submission carries structured metadata, one or more evidence scenarios with preconditions, triggers, and observed outcomes, location data identifying where the defect exists, and reproduction artefacts proving its presence. TEF is an intake format. It does not replace vulnerability publication formats (CVE, CSAF, OSV) or scan output formats (SARIF). It fills the gap between discovery and classification. | |||||||||||||
| draft-templeman-scitt-framing-space-00.txt | ||||||||||||||
| Measuring the CBOR Framing Space of COSE_Sign1 Data-Hash Pre-images | ||||||||||||||
|
A signed statement conveyed as a COSE_Sign1 object may be serialized into many distinct byte sequences that all decode to the same data item. Where a protocol identifies such a statement by a digest computed over its wire octets (referred to here as a data-hash), the identifier is sensitive to that framing while the signature over the statement is not. This document reports a measurement of the size of that class. Taking one 165-octet COSE_Sign1 object and re-emitting it under every combination of six CBOR encoding freedoms yields 64 distinct octet sequences. All 64 carry an identical Sig_structure and therefore an identical, valid signature. All 64 produce distinct data-hash values, with no collisions. A stock CBOR decoder rejected none of them, and 31 were silently repaired into the canonical form by the act of being read. This document specifies nothing and proposes no wording. It reports a measurement, publishes the reproduction recipe, and identifies the prior work that already addresses the problem it measures. | |||||||||||||
| draft-templin-6man-aero-omni-amen-16.txt | ||||||||||||||
| AERO/OMNI Base Specification Amendments (Volume 1) | ||||||||||||||
|
The Automatic Extended Route Optimization (AERO) and Overlay Multilink Network (OMNI) Interface functional specifications have reached a level of maturity ready for advancement in the RFC publication process. Updates to the base specifications are documented in this first amendment and any additional future amendments as necessary. | |||||||||||||
| draft-templin-6man-fwiw-05.txt | ||||||||||||||
| Fragmentation Revisited: For What It's Worth | ||||||||||||||
|
Internet Protocol (IP) fragmentation and reassembly have served as core elements of the architecture from the very earliest days but they have been subject to negative publicity by studies that have declared them "harmful" and "fragile". These warning labels have resonated deeply within the community in a way that fosters the enemies of sound engineering: fear, uncertainty and doubt. This document revisits IP fragmentation and shows that a properly engineered alternative IPv6 solution is both practical and necessary to provide a robust service for the future of Internetworking. | |||||||||||||
| draft-templin-6man-ipid-ext2-28.txt | ||||||||||||||
| IPv6 Extended Fragment Header (EFH) | ||||||||||||||
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. Both IPv4 and IPv6 fragmentation have further been classified as fragile to the point that their use is discouraged. This specification addresses these limitations by defining an IPv6 Extended Fragment Header (EFH) that includes a 64-bit Identification in the context of more robust, secure and efficient fragmentation and reassembly procedures. | |||||||||||||
| draft-templin-6man-mla-33.txt | ||||||||||||||
| IPv6 Addresses for Ad Hoc Networks | ||||||||||||||
|
Ad Hoc networks present an IPv6 addressing challenge due to the undetermined neighborhood properties of their interfaces. IPv6 nodes must assign locally-unique and topology-independent IPv6 addresses when topology-oriented IPv6 address delegation services are either absent or only intermittently available. This document introduces a new IPv6 address type (termed the "Multilink Local Address (MLA)") that nodes can autonomously assign to interfaces to support Ad Hoc network operations. | |||||||||||||
| draft-templin-intarea-ipid-ext2-11.txt | ||||||||||||||
| IPv6 Extended Fragment Header for IPv4 | ||||||||||||||
|
The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by adapting the IPv6 Extended Fragment Header for IPv4. | |||||||||||||
| draft-templin-manet-inet-05.txt | ||||||||||||||
| MANET Internetworking: Problem Statement and Gap Analysis | ||||||||||||||
|
[RFC2501] defines a MANET as "an autonomous system of mobile nodes. The system may operate in isolation, or may have gateways to and interface with a fixed network" (such as the global public Internet). This document presents a MANET Internetworking problem statement and gap analysis. | |||||||||||||
| draft-tempobono-protectchain-00.txt | ||||||||||||||
| ProtectChain: An Anchored Permissioned Ledger for Proof of Anteriority of Authored Works | ||||||||||||||
|
This document specifies ProtectChain, a permissioned, hash-chained and cryptographically signed ledger whose purpose is to produce verifiable evidence that a given digital work already existed no later than a given point in time, under an authorship claim made by an identified account. ProtectChain records only cryptographic digests and pseudonymous identifiers; the work itself never enters the ledger. Because all initial authorities may be operated by a single organization, every block is also anchored to independent public time references, so that the upper bound on a record's date does not rest on the operator's assertion. This document is deliberately explicit about the limits of the evidence produced: an anchor establishes that data existed _no later than_ a given instant; it does not establish the exact instant of creation, nor does it establish authorship or originality. | |||||||||||||
| draft-teodor-pilot-problem-statement-01.txt | ||||||||||||||
| Problem Statement: Network-Layer Infrastructure for Autonomous Agent Communication | ||||||||||||||
|
AI agents --- autonomous software entities capable of reasoning, planning, and executing tasks --- are an increasingly important class of network participant. Current agent communication protocols operate exclusively at the application layer over HTTP, assuming the existence of stable endpoints, DNS names, and centralized infrastructure. No existing standard provides network-layer identity, addressing, or transport for agents. This document describes the problem space and identifies requirements for a network-layer infrastructure that would give agents first-class network citizenship, independent of the web infrastructure designed for human users. | |||||||||||||
| draft-teodor-pilot-protocol-01.txt | ||||||||||||||
| Pilot Protocol: An Overlay Network for Autonomous Agent Communication | ||||||||||||||
|
This document specifies Pilot Protocol, an overlay network that provides autonomous AI agents with virtual addresses, port-based service multiplexing, reliable and unreliable transport, NAT traversal, encrypted tunnels, and a bilateral trust model. Pilot Protocol operates as a network and transport layer beneath application-layer agent protocols such as A2A and MCP. It encapsulates virtual packets in UDP datagrams for transit over the existing Internet. The protocol gives agents first-class network citizenship --- stable identities, reachable addresses, and standard transport primitives --- independent of their underlying network infrastructure. | |||||||||||||
| draft-teppo-corporate-authenticated-dns-00.txt | ||||||||||||||
| Authenticated DNS Resolution (ADR) for Enterprise DNS | ||||||||||||||
|
This document defines Authenticated DNS Resolution (ADR), an enterprise query-plane model that augments DNS resolution with per- query identity, role-based authorization, and audit. ADR preserves DNSSEC and public Internet DNS behavior while enabling enterprises to publish comprehensive internal naming without exposing sensitive topology. ADR leverages existing enterprise authentication and identity systems to authorize and audit DNS queries without defining a new authentication protocol. | |||||||||||||
| draft-test-psi-00.txt | ||||||||||||||
| Test PSI Submission | ||||||||||||||
|
Test submission. | |||||||||||||
| draft-thain-ipv8-02.txt | ||||||||||||||
| Internet Protocol Version 8 (IPv8) | ||||||||||||||
|
Internet Protocol Version 8 (IPv8) is a managed network protocol suite that transforms how networks of every scale -- from home networks to the global internet -- are operated, secured, and monitored. Every manageable element in an IPv8 network is authorised via OAuth2 JWT tokens served from a local cache. Every service a device requires is delivered in a single DHCP8 lease response. Every packet transiting to the internet is validated at egress against a DNS8 lookup and a WHOIS8 registered active route. Network telemetry, authentication, name resolution, time synchronisation, access control, and translation are unified into a single coherent Zone Server platform. IPv4 is a proper subset of IPv8. An IPv8 address with the routing prefix field set to zero is an IPv4 address. No existing device, application, or network requires modification. The suite is 100% backward compatible. There is no flag day and no forced migration at any layer. IPv8 also resolves IPv4 address exhaustion. Each Autonomous System Number (ASN) holder receives 4,294,967,296 host addresses. The global BGP8 routing table is structurally bounded by ASN count rather than prefix count. WHOIS8 is a critical infrastructure service underpinning this model. This document is one of the companion specifications: * draft-thain-ipv8-02 Core protocol (this document) * draft-thain-routing-protocols-00 BGP8, IBGP8, OSPF8, IS-IS8, CF * draft-thain-rine-00 Regional Inter-Network Exchange * draft-thain-zoneserver-00 Zone Server Architecture * draft-thain-whois8-00 WHOIS8 Protocol * draft-thain-netlog8-00 NetLog8 Protocol * draft-thain-support8-00 ARP8, ICMPv8, Route8 * draft-thain-ipv8-mib-00 IPv8 MIB and SNMPv8 * draft-thain-wifi8-00 WiFi8 Protocol * draft-thain-update8-00 Update8 and NIC Certification | |||||||||||||
| draft-thallapelly-oasnt-02.txt | ||||||||||||||
| OASNT: Attested Action Authorization Tokens | ||||||||||||||
|
This document defines the OASNT token, a compact JWS-based credential in which a hardware-bound device key attests that a specific human, on a device whose runtime integrity was assessed, authorized one specific action whose human-readable disclosure is cryptographically bound to the token (What You See Is What You Sign). Tokens are single-use, short-lived, and may additionally be bound to one concrete HTTP request. | |||||||||||||
| draft-thallapelly-oasnt-caid-01.txt | ||||||||||||||
| OASNT-CAID: Canonical Action Identifier Derivation and the Named-Human Binding | ||||||||||||||
|
This document profiles OASNT tokens for consumption by executor-side processing models. It fixes one normative derivation of a Canonical Action Identifier (CAID) from the OASNT action digest, so that every executor checks the same derivation rather than each integration defining its own, and it specifies the semantics of the token's named-human binding, including a subject-to-enrollment check whose absence this profile makes a refusal. | |||||||||||||
| draft-thallapelly-oasnt-enforce-01.txt | ||||||||||||||
| OASNT-ENFORCE: Request-Bound Enforcement of Attested Action Authorization | ||||||||||||||
|
This document profiles the enforcement of OASNT tokens at the point of execution. It defines the OASNT-Token HTTP field, the rules by which an enforcement point derives the observed request from the octets it will itself forward, a verification procedure for relying parties that hold no request-to-action mapping, uniform refusal behavior, and the set of refusals a conforming enforcement point is required to produce. It further defines an optional grp claim and an exclusivity ledger, by which a set of tokens issued from one human confirmation is made spendable only once between them, and fixes which relying party in a deployment performs that consumption. An enforcement point conforming to this profile makes a human approval a precondition of execution for the requests it fronts, without any change to the protected service. | |||||||||||||
| draft-thatcher-tsvwg-renomination-00.txt | ||||||||||||||
| ICE Renomination: Dynamically selecting ICE candidate pairs | ||||||||||||||
|
This document describes an extension to the Interactive Connectivity Establishment (ICE) that enables the controlling ICE agent to dynamically change its selected candidate pair over time as network conditions change, and notify the controlled side accordingly. | |||||||||||||
| draft-thomson-ptth-potato-02.txt | ||||||||||||||
| (Potato) - HTTP,Inverted | ||||||||||||||
|
This document defines 🥔 (P̷̙̩̩̖̦̦̮̲͖͗̅͋̇̊o̷̢͚̼͎͉̙̩̻̱̊̂̽̀̅̚͟͡t̤̐̇̋̍̑̓̏̕͝ ̴̖̞͖̰ȁ̷̩̹͎͖̮͚͋͑̏̀̓̂͡͞ͅt̗̹̩̭͈̳̫͈͈̒͆̃̿̚͝͠o͖͓͈̩̻̤͎͐̐͐̅̂́͟), a suite of reversed versions of HTTP for origin servers. | |||||||||||||
| draft-thomson-webpush-hpke-00.txt | ||||||||||||||
| WebPush Encryption using HPKE | ||||||||||||||
|
This document defines how to use Hybrid Public Key Encryption (HPKE) with Web Push. This document obsoletes RFC 8291. | |||||||||||||
| draft-thomson-webpush-sym-00.txt | ||||||||||||||
| WebPush Encryption using Symmetric Ciphers | ||||||||||||||
|
This document defines how to use purely symmetric cryptography with Web Push. This document obsoletes RFC 8291. | |||||||||||||
| draft-tian-dtn-sbam-05.txt | ||||||||||||||
| Securing BPSec Against Arbitrary Packet Dropping | ||||||||||||||
|
In this document we describe Secure Bundle Protocol Audit Mechanism (SBAM), an authentication protocol designed to provide cryptographic auditing services for the Bundle Security protocol. | |||||||||||||
| draft-tiloca-ace-bidi-access-control-03.txt | ||||||||||||||
| Bidirectional Access Control in the Authentication and Authorization for Constrained Environments (ACE) Framework | ||||||||||||||
|
This document updates the Authentication and Authorization for Constrained Environments (ACE) framework, for which it defines a method to enforce bidirectional access control by means of a single access token. Therefore, this document updates RFC 9200. | |||||||||||||
| draft-tiloca-ace-oscore-gm-kem-00.txt | ||||||||||||||
| Quantum-Resistant Key Encapsulation Mechanisms (KEMs) via the OSCORE Group Manager Using Authentication and Authorization for Constrained Environments (ACE) | ||||||||||||||
|
RFC 9594 defines a Key Distribution Center (KDC) to provision keying material for secure group communication, using the Authentication and Authorization for Constrained Environments (ACE) framework. An instance of KDC is the Group Manager for provisioning keying material in group communication scenarios that use the Constrained Application Protocol (CoAP) and the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). To make the pairwise mode of Group OSCORE post-quantum secure, it is possible to rely on a quantum-resistant Key Encapsulation Mechanism (KEM) as the Pairwise Key Agreement Algorithm used to derive pairwise keys. This document extends the interface of the ACE-based Group Manager to enable the exchange of KEM public keys and KEM ciphertexts among group members via the Group Manager, thus making the derivation of pairwise keys in Group OSCORE post-quantum secure. | |||||||||||||
| draft-tiloca-core-group-oscore-kem-00.txt | ||||||||||||||
| Using Quantum-Resistant Key Encapsulation Mechanisms (KEMs) in the Pairwise Mode of Group Object Security for Constrained RESTful Environments (Group OSCORE) | ||||||||||||||
|
Group communication for the Constrained Application Protocol (CoAP) can be protected end-to-end by using the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The pairwise mode of Group OSCORE provides authenticated encryption of CoAP messages, by means of symmetric keys that two group members establish only among themselves to achieve pairwise secure communication. This document defines the use of quantum-resistant Key Encapsulation Mechanisms (KEMs) as Pairwise Key Agreement Algorithm of Group OSCORE, enabling post-quantum secure derivation of the symmetric keys used in the pairwise mode. The Group Manager facilitates the exchange of KEM public keys and KEM ciphertexts among group members. | |||||||||||||
| draft-tiloca-core-oscore-discovery-20.txt | ||||||||||||||
| Discovery of OSCORE Groups with the CoRE Resource Directory | ||||||||||||||
|
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices might not know the exact security groups to join, the respective Group Managers responsible for those groups, or other information required to perform the joining process. This document defines how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Managers. A given security group can be used to protect communications in multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the Authentication and Authorization for Constrained Environments (ACE) framework. | |||||||||||||
| draft-tiloca-core-oscore-piv-enc-03.txt | ||||||||||||||
| Stand-in Key Identifier and Encrypted Partial IV in the Constrained Application Protocol (CoAP) OSCORE Option | ||||||||||||||
|
The security protocol Object Security for Constrained RESTful Environments (OSCORE) provides end-to-end protection of messages exchanged with the Constrained Application Protocol (CoAP). Messages protected with OSCORE include a CoAP OSCORE Option, where the "Partial IV" field specifies the sequence number value used by the message sender and the "kid" field specifies the identifier of the message sender. In order to reduce the information exposed on the wire that can be used for fingerprinting traffic and for tracking endpoints, this document defines a lightweight add-on method that obfuscates certain fields of the OSCORE Option, by encrypting the "Partial IV" field and overwriting the "kid" field with a stand-in identifier. Therefore, it updates RFC 8613. With minor adaptations, the defined method is applicable also to the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) that protects group communication for CoAP. | |||||||||||||
| draft-tiloca-lake-private-use-ranges-00.txt | ||||||||||||||
| Additional Private Use Ranges in the IANA Registries of the Lightweight Authenticated Key Exchange (LAKE) Protocol | ||||||||||||||
|
This document adds Private Use ranges to IANA registries that pertain to the Lightweight Authenticated Key Exchange (LAKE) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/lake/. Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-lake-private-use-ranges. | |||||||||||||
| draft-tiloca-t2trg-sw-update-groupcomm-02.txt | ||||||||||||||
| Distribution of Software Updates with End-to-End Secure Group Communication and Block-Wise Transfer for CoAP | ||||||||||||||
|
This document defines a method for efficiently distributing a software update to multiple target devices, by using end-to-end secure group communication over UDP and IP multicast. To this end, the defined method relies on a number of building blocks developed in the Constrained RESTful Environments (CoRE) Working Group of the IETF. Those especially include the Constrained Application Protocol (CoAP), Block-wise transfers for CoAP, and the end-to-end security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE). The method defined in this document is compatible with (but not dependent on) the architecture for software and firmware update developed in the Software Updates for Internet of Things (SUIT) Working Group of the IETF. | |||||||||||||
| draft-todd-mas-01.txt | ||||||||||||||
| Monotonic Attestation Service (MAS) | ||||||||||||||
|
This document defines the Monotonic Attestation Service (MAS), a protocol for issuing cryptographically attested, monotonically increasing sequence numbers within named namespaces. Each attestation includes a hash chain linking it to all prior entries in the namespace, providing verifiable proof of ordering and completeness. MAS is designed to complement RFC 3161 Trusted Timestamping: where RFC 3161 proves when an event occurred, MAS proves in what order and that the sequence is complete. | |||||||||||||
| draft-todo-kevinmcm-tutorial-00.txt | ||||||||||||||
| kevinmcm - Github tutorial | ||||||||||||||
|
This is where the abstract should be written About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://kevinmcm- github.github.io/github-tutorial/draft-todo-kevinmcm-tutorial.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-todo-kevinmcm-tutorial/. Source for this draft and an issue tracker can be found at https://github.com/kevinmcm-github/github-tutorial. | |||||||||||||
| draft-tojens-diem-arch-visual-aid-00.txt | ||||||||||||||
| DIEM Architecture Example | ||||||||||||||
|
This document defines the architecture for Digital Emblems. Standards that define Digital Emblems are expected to do so by mapping their mechanisms to the required and optional componented defined by this document. | |||||||||||||
| draft-tomas-openroaming-08.txt | ||||||||||||||
| WBA OpenRoaming Wireless Federation | ||||||||||||||
|
This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architecture enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. | |||||||||||||
| draft-tomlinson-lockb0x-01.txt | ||||||||||||||
| The Lockb0x Protocol: Codex Entries for Verifiable Data Sovereignty | ||||||||||||||
|
This document specifies the Lockb0x Protocol, a standards-based framework for creating Codex Entries (machine-readable Controllable Electronic Records) that bind together storage proofs, blockchain anchors, encryption metadata, signatures, and provenance. The protocol enables interoperability across decentralized and cloud storage systems while providing auditability and compliance with legal frameworks such as UCC Article 12. | |||||||||||||
| draft-tong-idr-bgp-ls-sav-rule-05.txt | ||||||||||||||
| Advertising SAV Rule-related Information using BGP Link-State | ||||||||||||||
|
This document proposes extensions to the BGP Link-State protocol for advertising Source Address Validation (SAV) rule-related information for monitoring and management purposes. | |||||||||||||
| draft-tonyai-a2a-trust-03.txt | ||||||||||||||
| Agent-to-Agent Trust,Identity,and Verifiable Provenance | ||||||||||||||
|
This document defines a trust model for agent-to-agent (A2A) interactions in multi-agent AI systems. It specifies how agents obtain verifiable identities via CA-signed templates, how spawn chains are cryptographically established and validated, how dynamic policies are governed under a dual-signature model, and how cross- organizational agent interactions are explicitly authorized. The model applies existing PKI primitives (X.509, CRL, CSR) and established identity patterns (OAuth 2.0, On-Behalf-Of) to the problem of agent provenance. This document does not address agent- to-resource access control, human-in-the-loop orchestration, or agent behavior, as those concerns belong to the resource enforcement layer and the orchestration layer respectively. | |||||||||||||
| draft-toraman-noa-action-digest-01.txt | ||||||||||||||
| The NOA Action Digest: a Domain-Separated Correlation Value for Human-Approved Agent Actions | ||||||||||||||
|
This document defines a domain-separated correlation value, the NOA Action Digest, that binds a verified human authorization for an agent action to the artifacts and external events associated with that action's execution attempt. The digest is a fixed-width value derived from an approved action's authorization record, its tenancy and chain identifiers, its parameter commitment, its execution grant, and a single-use nonce. It is designed to be embedded in external systems that carry an opaque, caller-chosen identifier, so that a third party can correlate an external event with a specific prior authorization. *The digest establishes correlation only. Equality of digests is not evidence that any statement made by any party about the action is true, and is not evidence that any action was executed or any effect occurred.* | |||||||||||||
| draft-toraman-noa-settlement-evidence-01.txt | ||||||||||||||
| Settlement Evidence for Human-Approved Agent Payments | ||||||||||||||
|
This document defines a signed side artifact that records the observation, on a public ledger, of a payment authorization whose correlation value was committed before dispatch. The artifact references the authorization record and the execution grant by hash and does not modify either. It permits a Relying Party *that obtains ledger facts itself* to establish that a payment authorization bearing the correlation value *was consumed on the token contract and network the mandate itself committed to, transferring a stated value to a stated recipient*, and that the correlation value is recomputable from a specific authorization record, a specific single- use execution grant, and the parameter pre-image that record commits to. *It does not establish that any service was delivered, that any obligation was discharged, or that the payment achieved its purpose. It does not establish that the approving principal — as opposed to the payer key — authorized the transfer.* Those scope limits are permanent and are restated wherever this artifact is described. | |||||||||||||
| draft-toutain-core-private-sid-translation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-toutain-core-sid-encoding-00.txt | ||||||||||||||
| YANG SID Discovery Using the Domain Name System | ||||||||||||||
|
CORECONF is an interface for managing YANG-modeled data using CBOR. It replaces verbose YANG schema item identifiers with compact 64-bit integers called Schema Item iDentifiers (SIDs). Interpreting a SID requires two resources: the YANG module definition and the SID dictionary (the .sid file) that maps each integer to the corresponding YANG schema item. Pre-loading every possible YANG module and its SID dictionary is not practical as the set of deployed modules grows; a dynamic discovery mechanism is therefore needed. This document specifies a DNS reverse-lookup mechanism analogous to ip6.arpa that maps a SID to a DNS name under the sid.yt. tree (where "yt" stands for YANG Tracker). Resolving that name returns TXT records pointing to the authoritative repository for the corresponding YANG module. | |||||||||||||
| draft-toutain-t2trg-coreconf-m2m-01.txt | ||||||||||||||
| CORECONF for Machine-to-Machine Communication | ||||||||||||||
|
The document addresses the specific challenges of M2M interactions where both endpoints may be constrained nodes, and explores the use of CORECONF primitives. This document describes the use of CORECONF (CoAP Management Interface) for Machine-to-Machine (M2M) communication in constrained IoT environments. It defines a YANG data model enabling remote management and configuration of constrained devices using CoAP, CBOR, and YANG SID identifiers. The serialization in CBOR of this data model limits the payload size. It documents also how the YANG data model can interact with common IoT ontologies such as SOSA or SAREF. The same CORECONF/SID serialization also enables full interoperability between constrained devices and AI agents, by exposing device actions and data through an MCP (Model Context Protocol) server without requiring an intermediate, device-specific translation layer. | |||||||||||||
| draft-traffic-analysis-and-network-mode-mapping-03.txt | ||||||||||||||
| Network Traffic Analysis and Network Modal Mapping Method | ||||||||||||||
|
This document presents a framework for network traffic classification and modality mapping based on large language models (LLMs), addressing the inefficiencies of traditional methods in dynamic network environments. The proposed approach automates multi- dimensional traffic feature extraction and intelligent decision- making to achieve precise alignment between traffic patterns and computing-storage-transmission requirements. The framework comprises two phases: pre-training (generating multi-modal traffic representations from pcap data) and mapping (dynamically formulating resource allocation strategies). It supports anomaly detection, QoS assurance, and multi-service collaboration, thereby significantly enhancing resource utilization efficiency and network service performance. | |||||||||||||
| draft-trammell-happy-sad-01.txt | ||||||||||||||
| Slow Alternate Detection for Happy Eyeballs | ||||||||||||||
|
This document specifies Slow Alternate Detection (SAD) for Happy Eyeballs, an ICMP-based advisory path signal [RFC8558] for exposing information about path non-selection on-path devices in order to aid debugging and measurement of Happy Eyeballs. | |||||||||||||
| draft-trammell-tsvwg-443-is-enough-00.txt | ||||||||||||||
| 443 is Enough: Guidance on Port Allocation for HTTP-based Services | ||||||||||||||
|
[RFC7605] provides guidance on the use of port numbers and the criteria for new port assignments, including a test for whether a proposed service is distinct from an existing service. It gives the example that "an automated system that happens to use HTTP framing -- but is not primarily accessed by a browser -- might be a new service." It also might not. This document clarifies the application of the distinct-protocol test in [RFC7605] Section 7.1 to services built on HTTP as a substrate, in light of HTTP's evolution since its publication, and provides guidance to applicants and reviewers on when an HTTP-based service qualifies for a new port assignment and when it does not. | |||||||||||||
| draft-traviss-evil-byte-00.txt | ||||||||||||||
| The Evil Byte: A Security Octet for the IPv4 and IPv6 Headers | ||||||||||||||
|
Firewalls, intrusion detection systems, and similar devices continue to have difficulty distinguishing packets that have malicious intent from those that are merely unusual. RFC 3514 addressed this problem by defining a security flag in the IPv4 header, the "evil bit", to be set by the sender of any packet with malicious intent. Twenty-four years of operational experience have shown that senders cannot be relied upon to set it, and that a single bit cannot express the range of Evil now observed on the Internet. This document obsoletes RFC 3514, replacing the evil bit with the Evil Byte: an eight-bit Evil Rating carried in every IPv4 and IPv6 packet, computed and set not by the sender but by a Morality- Inspecting Trusted Middleman (MITM) on the path, from a weighted product of the sender's Autonomous System, choice of protocols, content, name, and the time of day. Servers reject requests from Evil clients; clients discard responses from Evil servers; and the Evil of every Autonomous System is continuously re-estimated by an Elo rating system operated by a central Evil Rating Authority. The document also specifies the carriage of the octet over avian carriers. | |||||||||||||
| draft-treneule-humia-protocol-00.txt | ||||||||||||||
| HUMIA: A Website-First Protocol for Human-AI Cooperation | ||||||||||||||
|
HUMIA defines a website-first mechanism for publishing a machine- readable cooperation policy for AI agents. A website publishes a JSON policy at /.well-known/humia.json. The policy identifies the origin and expresses site-level conditions for public-content access, selected AI usage purposes, attribution, and optional usage reporting. HUMIA does not replace the Robots Exclusion Protocol, authentication, authorization, licensing, or access-control mechanisms. It is an additional cooperation layer. This document also defines an optional, experimental Humia: discovery record in robots.txt that points HUMIA-aware agents to the canonical policy URI. | |||||||||||||
| draft-trimplayer-portcast-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-tsou-behave-ftp46-01.txt | ||||||||||||||
| An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation | ||||||||||||||
|
An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo supports the case of an IPv4 client connecting to an IPv6 server. | |||||||||||||
| draft-tsou-softwire-port-set-algorithms-analysis-04.txt | ||||||||||||||
| Analysis of Algorithms For Deriving Port Sets | ||||||||||||||
|
This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches. | |||||||||||||
| draft-tsyrulnikov-rats-attested-inference-receipt-02.txt | ||||||||||||||
| Attested Inference Receipt (AIR): A COSE/CWT Profile for Confidential AI Inference | ||||||||||||||
|
This document defines the Attested Inference Receipt (AIR), an application-layer COSE_Sign1 envelope carrying CWT claims profiled per the Entity Attestation Token (EAT) framework. An AIR receipt binds model identity, input/output hashes, attestation-linked metadata, and operational telemetry into a single signed artifact suitable for independent third-party verification of a confidential AI inference. An AIR receipt is Attester-signed Evidence, not an appraisal verdict: a RATS Verifier must appraise the referenced platform attestation before the receipt establishes TEE provenance. AIR v1 targets single-inference receipts emitted by workloads running inside hardware-isolated Trusted Execution Environments (TEEs). AIR is attestation-linked: it carries measurements and a hash reference to the platform attestation evidence associated with the inference, but it does not replace platform-specific attestation verification. This version defines AWS Nitro Enclaves and Intel TDX measurement profiles only, and assumes a single platform attestation document per receipt. Pipeline chaining, multi-inference receipts, composite attesters, multi-verifier orchestration, accelerator / GPU confidential-compute attestation integration, and extensibility mechanisms for additional claim or platform profiles are out of scope. | |||||||||||||
| draft-tt-netmod-yang-config-templates-03.txt | ||||||||||||||
| YANG Configuration Templates | ||||||||||||||
|
NETCONF and RESTCONF protocols provide programmatic interfaces for accessing configuration data modeled by YANG. This document defines the use of a YANG-based configuration template mechanism whereby configuration data can be defined in one or more templates and applied repeatedly. This avoids the redundant definition of identical configuration and ensures the consistency of it, thus allowing configuration data to be managed more conveniently and efficiently. | |||||||||||||
| draft-tudor-asdf-proxy-privacy-00.txt | ||||||||||||||
| Enhanced privacy for SDF proxy operations | ||||||||||||||
|
The Semantic Definition Format (SDF) enables ecosystem-independent descriptions of IoT device interaction capabilities. When a proxy mediates communication between applications and devices, it requires SDF definitions and ecosystem-specific mappings for translation. These definitions may contain privacy-sensitive information about devices and their interactions. This document defines an SDF extension for marking sensitive definitions and specifies mechanisms for generating privacy-preserving SDF documents that enable proxy operation without exposing sensitive information. | |||||||||||||
| draft-tuexen-tsvwg-sctp-multipath-32.txt | ||||||||||||||
| Load Sharing for the Stream Control Transmission Protocol (SCTP) | ||||||||||||||
|
The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. | |||||||||||||
| draft-uberti-tsvwg-warp-00.txt | ||||||||||||||
| WebRTC Abridged Roundtrip Protocol (WARP) | ||||||||||||||
|
This document outlines a set of improvements to the WebRTC session setup protocols aimed at significantly reducing connection setup latency. This improved setup mechanism is known as the WebRTC Abridged Roundtrip Protocol (WARP). By addressing inefficiencies within the current multi-protocol handshake process, WARP can reduce setup latency from 6 RTTs to 2 RTTs when its optimizations are used together, with a direct impact on perceived performance and reliability. | |||||||||||||
| draft-udpn-protocol-00.txt | ||||||||||||||
| UDPN: UDP Datagram Privacy Network Protocol Version 1.0 | ||||||||||||||
|
This document specifies the UDP Datagram Privacy Network (UDPN) protocol, version 1.0. UDPN provides an authenticated, encrypted Layer 3 tunnel over UDP with traffic obfuscation designed to resist deep packet inspection (DPI) and active probing. All packets are wrapped in DTLS 1.2 ApplicationData records. The protocol uses the Noise_NK handshake pattern with X25519 Diffie-Hellman and ChaCha20-Poly1305 AEAD encryption. | |||||||||||||
| draft-uimonen-veif-01.txt | ||||||||||||||
| Verified Email Identity Framework (VEIF) | ||||||||||||||
|
This document defines the Verified Email Identity Framework (VEIF), a mechanism for associating a cryptographically verifiable real- world identity with an email message. VEIF complements existing email authentication technologies such as SPF, DKIM, and DMARC by providing a higher-level identity assurance layer. | |||||||||||||
| draft-uri-cfrg-pquake-00.txt | ||||||||||||||
| PQuAKE - Post-Quantum Authenticated Key Exchange | ||||||||||||||
|
This document defines the Post-Quantum Authenticated Key Exchange (PQuAKE) protocol that addresses the needs of bandwidth- and/or power-constrained environments, while maintaining strong security guarantees. It accomplishes that by minimizing the number of bits that need to be exchanged and by utilizing an implicit peer authentication approach similar to Menezes-Qu-Vanstone (MQV) design. This protocol is suitable for integration into protocols that establish dynamic secure sessions, such as Extensible Authentication Protocol (EAP), Internet Key Exchange Version 2 (IKEv2), or Secure Communications Interoperability Protocol (SCIP). This protocol has proofs in the verifiers Verifpal and CryptoVerif for security properties such as secrecy of the session key, mutual authentication, identity hiding with a pre-shared secret, and forward secrecy of the session key. The authors are in the process of publishing the proofs. | |||||||||||||
| draft-urien-core-racsl-00.txt | ||||||||||||||
| Remote APDU Call Secure Lite(RACSL) | ||||||||||||||
|
The Remote APDU Call Lite protocol (RACSL) is a lightweight version of the Remote APDU Call Secure protocol (RACS). RACS is designed for Grids of Secure Elements (GoSE), where servers host Secure Elements (SEs), i.e., tamper-resistant chips providing secure storage and cryptographic capabilities. It supports commands for GoSE inventory and data exchange with secure elements. RACSL targets environments hosting a limited number of secure element-typically one-within an IoT device managed by a microcontroller. It provides commands for data exchange with secure elements, in particular for managing their embedded applications. These commands are transported over TLS 1.3 pre-shared key (PSK) sessions, which MAY be secured using a TLS Identity Module (TLS-IM) application hosted within a secure element. RACSL can be used to update TLS-IM applications or to remotely access computing and storage resources hosted in secure elements. | |||||||||||||
| draft-urien-tls-im-trusted-exporter-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-urien-tls-se-xauth-03.txt | ||||||||||||||
| TLS for Secure Element Recursive Authentication | ||||||||||||||
|
This document defines a recursive authentication architecture based on the TLS 1.3 pre-shared key (PSK) mode. In this context, TLS servers, typically hosted within secure elements (TLS-SE), realize procedures that compute TLS 1.3 PSK-binder and Handshake Secret. These procedures allow a client to authenticate to downstream TLS servers without directly possessing the corresponding PSKs. Authentication capabilities can therefore be delegated across multiple TLS servers while maintaining protection of the underlying secrets. | |||||||||||||
| draft-usama-seat-intra-vs-post-04.txt | ||||||||||||||
| Pre-,Intra- and Post-handshake Attestation | ||||||||||||||
|
This document presents a taxonomy of extending TLS protocol with remote attestation, referred to as attested TLS. It also presents high-level analysis of benefits and limitations of each category, namely pre-handshake attestation, intra-handshake attestation and post-handshake attestation. It also captures the opinions of the WG participants in order to build consensus towards solutions. It also discussed tradeoffs and scalability. | |||||||||||||
| draft-usama-tls-fatt-extension-09.txt | ||||||||||||||
| Proposed Document Template for TLS FATT Process | ||||||||||||||
|
This document applies only to non-trivial extensions of TLS, which require formal analysis. FATT process has successfully discovered CVEs of *CVSS 7.5* and most recently expected *CVSS 9.1* in the *production* implementations of the drafts proposed for adoption in the TLS WG. To achieve high cryptographic assurances, this document proposes the drafts specify a clear threat model and informal security goals in the Security Considerations section, as well as motivation and a protocol diagram in the draft. | |||||||||||||
| draft-usama-tls-risks-of-mlkem-04.txt | ||||||||||||||
| Analysis of Hybrid Key Establishment and Standalone ML-KEM in TLS 1.3 | ||||||||||||||
|
This memo is a work-in-progress and maps out the technical facets relevant to the quantum-resistant key establishment in TLS 1.3 and provides some preliminary discussion to help developers and policymakers make informed choices. In particular, it presents hybrid key establishment and standalone ML-KEM in TLS 1.3. Moreover, it offers minimal implementation guidance for hybrid key establishment. The memo finally presents technical insights into hybrid key establishment and standalone ML-KEM in TLS 1.3. Our observation is that hybrid key establishment is preferable over standalone ML-KEM until a powerful CRQC exists which breaks most bits of pre-quantum. This memo is not a standard nor has it been shown to have consensus of the IETF community. | |||||||||||||
| draft-uttaro-idr-bgp-oad-08.txt | ||||||||||||||
| One Administrative Domain using BGP | ||||||||||||||
|
This document defines a new External BGP (EBGP) peering type known as EBGP-OAD, which is used between two EBGP peers that belong to One Administrative Domain (OAD). | |||||||||||||
| draft-valverde-oauth-pact-00.txt | ||||||||||||||
| PACT: Private Agent Consent and Trust Profile for OAuth 2.1 and CIBA | ||||||||||||||
|
PACT (Private Agent Consent and Trust Profile) is a security profile of OAuth 2.1 for privacy-preserving agent delegation. It extends VEIL and composes OIDC CIBA Core 1.0 and OAuth Token Exchange (RFC 8693). PACT defines a durable-host plus ephemeral-session control plane, a delegation token claim vocabulary, runtime identity proofs using Ed25519 JWTs, capability grants with typed constraints and usage limits, risk-graduated consent routing, and claim narrowing on token exchange to non-agent audiences. | |||||||||||||
| draft-valverde-oauth-veil-00.txt | ||||||||||||||
| VEIL: Verified Ephemeral Identity Layer for OAuth 2.1 | ||||||||||||||
|
VEIL (Verified Ephemeral Identity Layer) is a security profile of OAuth 2.1 for privacy-preserving identity verification. It separates claims into two tracks: proof claims (boolean verification results, compliance flags, assurance levels) travel through standard token claims, while identity claims (name, date of birth, address, nationality) travel only through an ephemeral, single-consume channel that keeps personally identifiable information off long-lived tokens. Subject identifiers are pairwise by default. Consent records are HMAC-protected. Step-up authentication scales with operation sensitivity. VEIL is the base profile for domain-specific extensions. | |||||||||||||
| draft-van-meter-qirg-quantum-network-architecture-01.txt | ||||||||||||||
| A Quantum Network Architecture | ||||||||||||||
|
This quantum network architecture defines a set of planes providing different views of the network, supporting different responsibilities and modes of operation; a set of device, node and link types; some network topologies, deployment scenarios and their relationship to applications; and key design decisions as a result of corresponding requirements. | |||||||||||||
| draft-vance-socks-v4-09.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vance-socks-v4a-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vance-socks5-frag-deprecation-00.txt | ||||||||||||||
| Deprecating the FRAG Field in SOCKS5 | ||||||||||||||
|
This document updates RFC 1928 by formally deprecating the FRAG (Fragment) field in the SOCKS5 UDP ASSOCIATE request header. It mandates that the FRAG field MUST be set to X'00' by clients and that proxies MUST drop any SOCKS5 UDP packets containing a non-zero FRAG value. This change aligns the SOCKS5 protocol with modern Internet engineering practices regarding UDP fragmentation (BCP 227), simplifies proxy implementations, and eliminates a vector for resource exhaustion attacks. | |||||||||||||
| draft-vandemeent-ains-discovery-01.txt | ||||||||||||||
| AINS: AInternet Name Service - Agent Discovery and Trust Resolution Protocol | ||||||||||||||
|
This document specifies AINS (AInternet Name Service), a protocol for discovery, identification, and trust resolution of autonomous agents (AI agents, devices, humans, and services) in heterogeneous networks. AINS defines a transport-independent logical namespace for agents, a structured record format combining identity, capabilities, and cryptographic trust metadata, and a resolution protocol based on HTTPS. Unlike the Domain Name System (DNS), which maps names to network addresses, AINS maps agent identifiers to rich metadata objects that include capabilities, trust scores, endpoint information, and references to companion provenance protocols. AINS federates through signed append-only replication logs, enabling multi-registry deployments without central authority while preserving auditability. This specification is designed to complement TIBET [TIBET], JIS [JIS], UPIP [UPIP], and RVP [RVP]. | |||||||||||||
| draft-vandemeent-bearer-handover-01.txt | ||||||||||||||
| Identity-Anchored Bearer Handover for Real-Time Media Sessions | ||||||||||||||
|
This document describes identity-anchored bearer handover: a method for keeping a live, authenticated real-time media session (such as a voice call) running uninterrupted while the underlying network bearer changes - for example a device moving from Wi-Fi to cellular. The session is bound to a cryptographic identity and a media-encryption key, never to an IP address. When the bearer changes, the endpoint detects the new local address and emits an authenticated re-anchor over a stable control channel; the media path is re-established to the same cryptographic context, so the far end can relearn the new transport source without exposing the session to source-substitution (latching) attacks. No central media relay is required: a default- routed media anchor plus an authenticated re-anchor is sufficient. Each handover MAY emit a signed transport-rebind event for an auditable trail. Human-facing names, dial strings, or aliases may select a policy surface, but they are not the cryptographic anchor and not the transport binding. This protocol is transport-agnostic and complements JIS [JIS], the MUX Status Frame [MUX], the Semantic Surface Manifest [SSM], and TIBET provenance [TIBET]. | |||||||||||||
| draft-vandemeent-continuity-envelope-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vandemeent-iddrop-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vandemeent-jis-identity-02.txt | ||||||||||||||
| JIS: JTel Identity Standard - Identity and Trust Establishment for Autonomous Agents | ||||||||||||||
|
This document defines JIS (JTel Identity Standard), a protocol for establishing identity, negotiating trust, and binding intent declarations to actor interactions. JIS provides three core mechanisms: a dual-keypair identity model separating human-device binding (HID) from device authentication (DID), a trust establishment handshake (FIR/A) that negotiates capabilities and records intent, and a human-readable context layer (Humotica) that captures the sense, context, intent, and explanation for every interaction. JIS is transport-agnostic and operates as a semantic layer above existing protocols. It integrates with TIBET [TIBET] for provenance tracking, and is consumed by UPIP [UPIP], RVP [RVP], and AINS [AINS] for process integrity, continuous verification, and agent discovery respectively. | |||||||||||||
| draft-vandemeent-mux-status-frame-00.txt | ||||||||||||||
| MUX Status Frame: Two-Way Reachability Signalling without an Enumeration Oracle | ||||||||||||||
|
This document defines the MUX Status Frame, a two-octet, relationship-scoped signal that lets a multiplexing routing layer tell a proven, related peer that a destination is unavailable - offline, not in session, superseded, or permanently revoked (tombstoned) - while disclosing nothing to the open network. It resolves the tension between two failure modes of a null-routing mux: silently dropping traffic to a dead peer (a false positive - the sender believes it landed) and answering honestly to everyone (an enumeration oracle mapping who is alive, dead, or revoked). Honest status travels only on a relationship-scoped trusted path; to the world, and to any merely authenticated but unrelated peer, the entire frame is zero. Status is derived from the canonical naming record and session liveness, not from a separate blocklist. The encoding is deterministic so independent implementations agree byte-for-byte. This protocol is transport-agnostic and complements JIS [JIS], AINS [AINS], TIBET [TIBET], and RVP [RVP]. | |||||||||||||
| draft-vandemeent-rvp-continuous-verification-02.txt | ||||||||||||||
| RVP: Real-time Verification Protocol - Continuous Identity and Process Verification | ||||||||||||||
|
This document defines RVP (Real-time Verification Protocol), a protocol for continuous identity verification through ordered cascades of verification methods. Unlike traditional authentication models that verify once and trust until session expiry, RVP treats every interaction as a verification moment. Each moment produces a Verification Token: a cryptographic evidence record capturing which methods were used, what confidence each produced, and whether the accumulated confidence meets the required threshold. RVP defines a Verification Cascade: an ordered chain of verification methods (behavioral biometrics, physical identity, device context) where each layer activates only when preceding layers produce insufficient confidence. The cascade produces evidence at every step; enforcement is a local policy decision. RVP integrates with TIBET [TIBET] for provenance tokens and JIS [JIS] for identity semantics. The protocol is designed for local-first operation with no dependency on centralized identity providers. | |||||||||||||
| draft-vandemeent-tibet-causal-time-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vandemeent-tibet-provenance-02.txt | ||||||||||||||
| TIBET: Transaction/Interaction-Based Evidence Trail | ||||||||||||||
|
This document defines TIBET (Transaction/Interaction-Based Evidence Trail), a data model and protocol for constructing cryptographically linked provenance chains over interactions between autonomous agents, human actors, and automated processes. A TIBET token captures four dimensions of provenance: content (ERIN), references (ERAAN), context (EROMHEEN), and intent (ERACHTER). Tokens are cryptographically signed, hash-chained, and designed for append-only storage. TIBET is transport-agnostic and encoding-flexible, with JSON over HTTPS as the baseline serialization. This document specifies the token data model, chain semantics, canonicalization rules, verification procedures, and integration points with companion protocols JIS [JIS], UPIP [UPIP], RVP [RVP], and AINS [AINS]. | |||||||||||||
| draft-vandemeent-tibet-semantic-surface-manifest-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vandemeent-tibet-tat-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vandemeent-upip-process-integrity-01.txt | ||||||||||||||
| UPIP: Universal Process Integrity Protocol with Fork Tokens for Multi-Actor Continuation | ||||||||||||||
|
This document defines UPIP (Universal Process Integrity Protocol), a five-layer protocol for capturing, verifying, and reproducing computational processes across machines, actors, and trust domains. UPIP defines a cryptographic hash chain over five layers: STATE (input), DEPS (dependencies), PROCESS (execution), RESULT (output), and VERIFY (cross- machine proof). The stack hash chains these layers, ensuring that modification of any component is detectable. This document also defines Fork Tokens, a continuation mechanism for multi-actor process handoff. Fork tokens freeze the UPIP stack at a specific point and transfer it to another actor with cryptographic chain of custody. The receiving actor can verify what was handed off, validate capabilities, and continue the process with full provenance. UPIP integrates with TIBET [TIBET] for provenance tokens, JIS [JIS] for actor identity, and is transport-agnostic with JSON as the baseline serialization. | |||||||||||||
| draft-vandoulas-aidp-03.txt | ||||||||||||||
| Agent Interaction & Delegation Protocol (AIDP) | ||||||||||||||
|
This document specifies the Agent Interaction & Delegation Protocol (AIDP), a control-plane protocol for secure, auditable, and interoperable software agents. AIDP defines standardized mechanisms for expressing intent, enforcing authority, delegating capabilities, executing actions, and binding execution results to agent reasoning across heterogeneous systems and administrative domains. This version introduces a normative Intent Lifecycle Model, including Human Approval Gates and support for long-running agent executions, defines version negotiation and capability discovery, clarifies the relationship of AIDP to the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol, and establishes extensibility registries. Non-normative deployment material has been moved to informative appendices. | |||||||||||||
| draft-vangeest-lamps-update-asn1-signed-type-01.txt | ||||||||||||||
| Updated Parameterized SIGNED ASN.1 Type for X.509 (PKIX) | ||||||||||||||
|
This document updates some ASN.1 modules which conform to the syntax of the 2002 version of ASN.1 but feature constraints that are no longer consistent with usage of the associated structures. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax to better align with current practices. | |||||||||||||
| draft-vanmook-expanse-problem-statement-00.txt | ||||||||||||||
| Extending Policy,Addressing and Numbering across Space Ecosystems (EXPANSE): Problem Statement | ||||||||||||||
|
Ongoing IETF work on networking in non-terrestrial and deep-space environments treats addressing, numbering, and registry policy as a greenfield. It is not. Three decades of operational practice, registry governance, and routing security infrastructure exist, and any space-segment architecture that ignores them will recreate, badly, the coordination mechanisms the Internet already has. This document describes the problem and motivates chartering a working group to address it. | |||||||||||||
| draft-vargas-eirp-00.txt | ||||||||||||||
| Encrypted Identity Routing Protocol (EIRP): A Blockchain-Orchestrated Identity-Based Routing Architecture | ||||||||||||||
|
This document proposes the Encrypted Identity Routing Protocol (EIRP), a conceptual redesign of Internet routing where public IP addresses are replaced by encrypted identities authenticated through blockchain consensus. | |||||||||||||
| draft-varhal-6man-icmp-srv6-vpn-02.txt | ||||||||||||||
| ICMP Error Handling for VPNs in SRv6 Networks | ||||||||||||||
|
This document specifies ICMP error handling in SRv6-based Virtual Private Networks, that support direct localization of failures. It provides a solution for connectivity check and fault localization without adding complexity to P nodes and keeps P nodes service agnostic. ICMP processing is changed only on ingress PE nodes and gains from adding VPN-specific information to the SRv6 encapsulated packet. Egress PE nodes are not involved in the forwarding of the ICMP error messages therefore, the solution provides visibility upto the failure even if ingress PE to egress PE connectivity is broken within the SR domain. | |||||||||||||
| draft-varnagy-iid-protocol-00.txt | ||||||||||||||
| Internet Identity Protocol (IID) | ||||||||||||||
|
This document specifies the IID protocol, which defines message formats and operations for managing personal data, permissions, and attributes associated with internet identities, including natural persons, organizations and artificial intelligence agents. The protocol is designed to be simple, extensible, platform- independent, and human readable. It is transport-agnostic and supports arbitrary cryptographic algorithms. | |||||||||||||
| draft-vasters-json-structure-alternate-names-03.txt | ||||||||||||||
| JSON Structure: Alternate Names and Descriptions | ||||||||||||||
|
This document is an extension to JSON Structure Core. It defines three annotation keywords, altnames, altenums, and descriptions, which allow schema authors to provide alternative identifiers, display names, and multi-variant descriptions for types, properties, and enumeration values. | |||||||||||||
| draft-vasters-json-structure-cond-composition-03.txt | ||||||||||||||
| JSON Structure: Conditional Composition | ||||||||||||||
|
This document specifies JSON Structure Conditional Composition, an extension to JSON Structure Core that introduces composition constructs for combining multiple schema definitions. In particular, this specification defines the semantics, syntax, and constraints for the keywords allOf, anyOf, oneOf, and not, as well as the if/then/ else conditional construct. | |||||||||||||
| draft-vasters-json-structure-core-04.txt | ||||||||||||||
| JSON Structure: Core | ||||||||||||||
|
This document specifies JSON Structure, a data structure definition language that enforces strict typing, modularity, and determinism. JSON Structure describes JSON-encoded data such that mapping to and from programming languages and databases and other data formats is straightforward. | |||||||||||||
| draft-vasters-json-structure-import-03.txt | ||||||||||||||
| JSON Structure: Import | ||||||||||||||
|
This document specifies the $import and $importdefs keywords as extensions to JSON Structure Core. These keywords allow a schema to import definitions from external schema documents. | |||||||||||||
| draft-vasters-json-structure-relations-00.txt | ||||||||||||||
| JSON Structure: Relations | ||||||||||||||
|
This document is an extension to JSON Structure Core. It defines keywords for modeling relationships and associations between objects in JSON Structure schemas, including the identity, relations, targettype, cardinality, scope, and qualifiertype keywords. | |||||||||||||
| draft-vasters-json-structure-sem-ann-00.txt | ||||||||||||||
| JSON Structure: Semantic and Reference-System Annotations | ||||||||||||||
|
Data types describe representation, but they do not explain the semantic, temporal, spatial, and operational characteristics needed to interpret and compare data. This document defines optional JSON Structure annotations that bind schema nodes to terms in external vocabularies; annotations for observation results, observed properties, features of interest, procedures, time semantics, quality, derivation, and cadence; annotations for spatial referencing by coordinates, by vector and tensor reference frames, by transformations between frames, and along linear elements; and annotations for color spaces, audio channel layouts, spectral bands, code lists, and measurement conditioning. The annotations make an incompatibility between two data sets detectable by machine; they do not resolve one. They are optional, and their absence does not make a schema invalid. | |||||||||||||
| draft-vasters-json-structure-units-03.txt | ||||||||||||||
| JSON Structure: Symbols,Scientific Units,and Currencies | ||||||||||||||
|
This document specifies "JSON Structure Symbols, Scientific Units, and Currencies", an extension to JSON Structure Core. This specification defines a set of annotation keywords for associating scientific unit and currency metadata and constraints, primarily for use with numeric values. This extension provides a mechanism for schema authors to explicitly declare the unit associated with numeric data, thereby enabling precise mapping between schema representations and external data systems. | |||||||||||||
| draft-vasters-json-structure-validation-03.txt | ||||||||||||||
| JSON Structure: Validation Extensions | ||||||||||||||
|
The JSON Structure Validation extension provides schema authors with additional means to constrain instance data. These keywords are applied in conjunction with the constructs defined in JSON Structure Core. The keywords defined herein include numeric, string, array, and object validation keywords as well as conditional validations. | |||||||||||||
| draft-vasylenko-e2ee-http-00.txt | ||||||||||||||
| End-to-End Encryption for HTTP APIs Using X25519 and AES-GCM | ||||||||||||||
|
This document specifies an application-layer end-to-end encryption (E2EE) scheme for HTTP APIs. The scheme uses X25519 Elliptic Curve Diffie-Hellman (ECDH) for key agreement, HKDF-SHA256 for key derivation, and AES-GCM (with 128-, 192-, or 256-bit keys) for authenticated encryption of request and response payloads. Server public keys are discovered through a Well-Known URI and authenticated either by TLS or by a stronger out-of-band trust mechanism, depending on the deployment threat model. The scheme is designed to provide confidentiality and integrity of payloads independent of, and in addition to, transport-layer security such as TLS. It provides replay protection and key rotation. | |||||||||||||
| draft-vasylenko-pait-protocol-01.txt | ||||||||||||||
| Provenance-Attributed Inference Token (PAIT): A Protocol for Token-Level Inference Provenance and Identity-Conditioned Inference in Generative AI Systems | ||||||||||||||
|
This document specifies the Provenance-Attributed Inference Token (PAIT) protocol, a wire-level protocol for token-level provenance attribution and identity-conditioned inference in Large Language Model (LLM) systems and other generative AI systems. PAIT defines: (1) an Agent Identity Token format that binds a globally unique agent identifier to a hierarchical authorization level by means of an asymmetric digital signature; (2) a Provenance Manifest Record format that associates each output token of an inference session with verifiable attribution data referencing training-corpus segments; (3) a Trust Telemetry Signal format for aggregated session metrics emission to external monitoring endpoints; and (4) a wire protocol state machine governing the interaction between a requesting agent and a generative AI endpoint. PAIT is intended to address the transparency obligations imposed by emerging regulatory frameworks for high-risk and general-purpose AI systems, in particular those concerning the provenance of AI-generated content at sub-document granularity. | |||||||||||||
| draft-vauban-x402-consolidated-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vauban-x402-delegation-binding-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vauban-x402-lifecycle-fsm-01.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-vauban-x402-pqc-receipts-01.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-vauban-x402-stark-receipts-02.txt | ||||||||||||||
| 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). | |||||||||||||
| draft-vauban-x402-starknet-anchor-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vauban-x402-vpsf-algebra-01.txt | ||||||||||||||
| 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]. | |||||||||||||
| draft-vaughan-machine-readability-01.txt | ||||||||||||||
| Defining Machine Readability for Usage Preferences and Policy Expression | ||||||||||||||
|
The term "machine readable" is widely invoked when content usage preferences, rights, and legal terms are expressed for automated consumption, but it is rarely defined with enough precision to be actionable. This document resolves the term into two core criteria, parseability and interpretability, which are properties of an expression itself, and three further dimensions (discoverability, actionability, and verifiability) which are orthogonal to the core criteria and to one another, concerning as they do the expression's place in a transaction rather than its content alone. Together these determine whether an expression of preferences or policy can be reliably acted upon by a non-human agent without human intervention. This document applies the framework to usage preferences and legal terms of service. | |||||||||||||
| draft-venaas-pim-ipv4-in-ipv6-core-01.txt | ||||||||||||||
| Native IPv4 multicast in IPv6 Core using PIM | ||||||||||||||
|
This document describes how PIM Sparse-Mode can be used to construct IPv4 multicast trees across an IPv6-only network core. This allows forwarding of native IPv4 multicast data packets. The document specifies how to send and receive IPv4 PIM messages with IPv6 headers, using a new well-known link-local IPv6 multicast address, and the use of RPF vectors for reachability. | |||||||||||||
| draft-venkateswaran-jamwal-twophp-01.txt | ||||||||||||||
| 2-Phase HTTP Protocol for Distributed Transaction Tracking (2PHP-DTT) | ||||||||||||||
|
This document specifies the 2-Phase HTTP Protocol for Distributed Transaction Tracking (2PHP-DTT), a backward-compatible, opt-in extension to HTTP mutation semantics that introduces a two-phase handshake at service request boundaries. 2PHP ensures that a mutation request is durably registered on both the client and the server before any processing commences, addressing a structural gap in existing HTTP REST semantics where no standard mechanism exists to confirm bilateral intent registration prior to execution. The acronym DTT expands to Distributed Transaction Tracking. 2PHP is not Two-Phase Commit (2PC). Microservices architectures deliberately avoid the cross-service locking and blocking that 2PC requires. 2PHP standardizes the intent-tracking pattern that implementations currently build ad hoc, providing a common wire contract and a queryable ledger of registered intent without introducing a distributed transaction coordinator. A primary motivator for this work is the growing use of agent-driven HTTP invocations, including Model Context Protocol (MCP) tool calls and agent-to-agent (A2A) integrations. When an agent does not receive a response, its default behavior is to retry. Absent a queryable record of prior intent, retries pile onto services that may already be overwhelmed, causing deadlocks, resource exhaustion, and full outages. 2PHP's Phase 1 ledger record enables the client to inspect whether the prior intent was registered before issuing a retry, breaking the retry-storm feedback loop at the protocol layer. 2PHP operates at the HTTP protocol layer, requires no new transport mechanisms, and is composable across independently operating service boundaries. This document further defines a standardized Intent Ledger model for durable, queryable, cross-service correlation of request intent, distinct from execution telemetry provided by distributed tracing systems. This document does not claim novelty over existing intent-tracking, idempotency, or distributed-tracing patterns. Its goal is to define a common HTTP-layer wire contract and a common ledger schema so that a single reference implementation--packaged as a library or framework module--can serve multiple deployments, replacing the per-team ad hoc implementations that currently reinvent this pattern. This document defines the protocol headers, phase state machine, idempotency and replay behavior, the three-tier Intent Ledger architecture, cross-service correlation model, and IANA registration of the associated HTTP header fields. 2PHP-DTT targets the synchronous request-response boundary, where no standard acknowledgement primitive exists to confirm bilateral intent registration before processing. Asynchronous HTTP patterns -- 202 Accepted with Location-based polling in HTTP Semantics, Prefer: respond-async negotiation, webhooks, and message-broker delivery -- already provide durable acknowledgement of intent by construction, and are therefore out of scope for this specification. | |||||||||||||
| draft-veridom-omp-02.txt | ||||||||||||||
| Operating Model Protocol (OMP) Core -- Version 02: 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 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. | |||||||||||||
| draft-veridom-omp-aiins-00.txt | ||||||||||||||
| OMP Domain Profile: AI Liability Insurance Underwriting and Parametric Claims Evidence | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in contexts covered by AI liability insurance policies, including AI performance warranties, AI errors and omissions coverage, and coordinated AI liability structures. The profile -- designated InsureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate per-decision Proof-Points that function as objective parametric trigger data for AI liability insurance claims, and provide independently verifiable underwriting evidence that reduces claims ambiguity and supports premium differentiation. The InsureMark profile addresses the primary gap in current AI liability insurance underwriting: policies are currently issued based on model-level performance assessments, but claims arise at the level of individual AI decisions. No current AI liability insurance product requires or receives per-decision cryptographic evidence. This profile specifies the technical architecture by which OMP Proof- Points close this gap. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). | |||||||||||||
| draft-veridom-omp-clinical-00.txt | ||||||||||||||
| OMP Domain Profile: Clinical AI Decision Accountability Under Joint Commission/CHAI Guidance,California SB 1120,and Emerging US State and Federal Healthcare AI Obligations | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in clinical and healthcare decision contexts subject to qualified human reviewer requirements under the US Joint Commission and Coalition for Health AI (CHAI) Responsible Use Guide (September 2025), California Senate Bill 1120 (SB 1120, effective January 1, 2025), New York Assembly Bill A9149 (pending), and related US state and federal healthcare AI accountability obligations. The profile -- designated CareGuard -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the qualified human reviewer documentation requirements, clinical decision traceability obligations, and AI governance evidence standards applicable to healthcare AI deployments. The profile addresses four clinical deployment categories: medical necessity determinations, clinical decision support, diagnostic AI assistance, and prior authorisation AI systems. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). | |||||||||||||
| draft-veridom-omp-coloai-00.txt | ||||||||||||||
| OMP Domain Profile: Cross-Sector High-Risk AI Accountability Under the Colorado Artificial Intelligence Act (SB 24-205) and Alignment with NIST AI RMF 1.0 | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for high-risk AI systems subject to the Colorado Artificial Intelligence Act (SB 24-205, effective June 1, 2026), which requires deployers of high-risk AI systems in consequential decisions affecting Colorado consumers to implement risk management programmes, provide consumer disclosures, conduct impact assessments, and implement discrimination mitigation measures. The profile -- designated ColoradoMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the Colorado AI Act's per-decision accountability obligations and align with the NIST AI RMF 1.0, providing a unified cross-sector accountability evidence architecture for the six Colorado AI Act consequential decision domains. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). | |||||||||||||
| draft-veridom-omp-core-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-veridom-omp-employ-00.txt | ||||||||||||||
| OMP Domain Profile: Automated Decision Systems Accountability in Employment Under California FEHC CRC Regulations,New York City Local Law 144,and Related ADS Accountability Obligations | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for automated decision systems (ADS) deployed in employment contexts subject to the California Civil Rights Council (CRC) Employment Regulations on Automated Decision Systems (effective October 1, 2025), New York City Local Law 144 (bias audit requirement for automated employment decision tools), the Illinois Artificial Intelligence Video Interview Act (AIVIA), and related US state and municipal ADS accountability obligations in employment. The profile -- designated WorkMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the record-retention, named accountability, bias audit evidence, and per- decision auditability requirements applicable to employment ADS deployments. The profile directly addresses the California CRC requirement to retain ADS inputs, outputs, decision criteria, and audit results for four years with named accountability for AI- assisted hiring and employment decisions. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). | |||||||||||||
| draft-veridom-omp-euaia-00.txt | ||||||||||||||
| OMP Domain Profile: EU AI Act Article 12 Logging and Traceability Requirements for High-Risk AI System Operators | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for high-risk AI system operators subject to Article 12 of Regulation (EU) 2024/1689 (the EU AI Act). Article 12 requires that high-risk AI systems automatically generate tamper- resistant logs capable of ensuring traceability throughout the system's lifetime. This profile specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture (SHA-256, RFC 3161, institution signature) satisfy the Article 12 requirements, and defines the domain-specific Watchtower configurations and Audit Trace schema extensions applicable to EU high-risk AI deployments under Annex III of the Regulation. The core OMP specification is defined in a separate Internet-Draft (\"Operating Model Protocol (OMP): A Deterministic Decision-Enforcement Protocol with Externalized Proof-of-Integrity\"). | |||||||||||||
| draft-veridom-omp-fca-00.txt | ||||||||||||||
| OMP Domain Profile: FCA Consumer Duty,SM&CR Accountability,and AI Governance Evidence for UK Retail Financial Services | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in UK retail financial services contexts subject to the Financial Conduct Authority (FCA) Consumer Duty (PS22/9, effective July 31, 2023), the Senior Managers and Certification Regime (SM&CR), and the FCA's emerging AI accountability framework as informed by the Mills Review (2026) and the FCA's research on algorithmic decision-making. The profile -- designated DutyMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the evidence requirements for Consumer Duty outcome testing, SM&CR named accountability, and FCA supervisory examination of AI-assisted retail financial services decisions. The profile covers the four Consumer Duty outcome areas and FCA agent distribution oversight. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). | |||||||||||||
| draft-veridom-omp-fhfa-00.txt | ||||||||||||||
| OMP Domain Profile: AI Governance and Accountability Evidence for US Housing Finance Under FHFA Bulletin 2025-16 and GSE AI/ML Model Risk Governance | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI and machine learning (ML) systems deployed in US housing finance contexts subject to the Federal Housing Finance Agency (FHFA) Bulletin 2025-16 (effective March 3, 2026), which establishes a comprehensive AI governance framework for Fannie Mae, Freddie Mac, and the Federal Home Loan Banks (the GSEs), requiring transparency, accountability, and ethical stewardship for AI/ML systems used in housing finance decisions. The profile -- designated HomeMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the AI governance evidence requirements of FHFA Bulletin 2025-16, including per-decision accountability, named individual responsibility, model risk governance documentation, fair lending evidence, and representation and warranty compliance for mortgage origination, credit decisioning, property valuation, and loan servicing. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). | |||||||||||||
| draft-veridom-omp-legal-00.txt | ||||||||||||||
| OMP Domain Profile: Legal AI Supervision Under ABA Model Rule 5.3 and California Senate Bill 574 | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for legal AI deployments subject to attorney supervision obligations under ABA Model Rule 5.3 Responsibilities Regarding Nonlawyer Assistance and California Senate Bill 574 (SB 574, effective January 1, 2026). These instruments impose principal accountability requirements on attorneys who use AI tools to assist with legal work product -- requiring attorneys to verify AI-generated material, ensure compliance with professional duties, and maintain evidence of supervision. This profile specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture satisfy the attorney supervision obligations imposed by Rule 5.3 and SB 574, and defines the domain-specific Watchtower configurations, Named Accountable Officer assignments, and Audit Trace schema extensions applicable to legal AI deployments. The profile is designated the CiteGuard profile. The OMP core specification is defined in a separate Internet-Draft. | |||||||||||||
| draft-veridom-omp-ndtcp-00.txt | ||||||||||||||
| OMP Domain Profile: Kenya Digital Credit Providers -- CBK NDTCP Regulations 2022 and AI Decision Accountability | ||||||||||||||
|
This document defines the OMP domain profile for digital credit providers (DCPs) operating under the Central Bank of Kenya Digital Credit Providers Regulations 2022 (CBK NDTCP). It specifies the Intent Class configuration, routing threshold ranges, Watchtower definitions, and Audit Trace extensions required to satisfy per- decision explainability and human oversight evidence requirements for AI-assisted credit decisions under the CBK framework. The Central Bank of Kenya AI Banking Sector Survey (July 2025) found that few institutions using AI for credit decisions have mechanisms for per-decision explainability. The CBK AI Guidance Note, in preparation as of March 2026, will define what adequate AI governance evidence means for all 195 licensed DCPs. This profile specifies the technical architecture that satisfies those requirements. This profile REQUIRES implementation of the core OMP protocol as defined in draft-veridom-omp. All terms and base protocol specifications in that document apply to this profile. This document specifies only the domain parameters. | |||||||||||||
| draft-veridom-omp-sacco-00.txt | ||||||||||||||
| OMP Domain Profile: Kenya Deposit-Taking SACCOs -- SASRA Supervision and Cooperative Governance Accountability | ||||||||||||||
|
This document defines the OMP domain profile for deposit-taking SACCOs (Savings and Credit Cooperative Organisations) operating under SASRA supervision in Kenya. It specifies the Intent Class configuration, routing threshold ranges, Watchtower definitions, and Audit Trace extensions required to satisfy board-level principal accountability requirements under the SACCO Societies Act and the Cooperatives Bill 2024. The PricewaterhouseCoopers forensic audit of KUSCCO [KUSCCO-PWC-2025] (Kenya Union of Savings and Credit Co-operatives), presented to the Cabinet Secretary for Cooperatives and MSMEs in 2025, identified KES 13.3 billion in misappropriated funds. Every specific failure identified -- forged auditor signatures, unauthorised executive loans, fraudulent commission rate changes, unlicensed operations -- was undetectable because no evidence trail connected board authorisation to operational outcome. This profile specifies the OMP architecture that closes each of those specific failure modes. The Cooperatives Bill 2024 [COOPERATIVES-BILL-2024] (Bill No. 7 of 2024), currently before the Kenyan Senate, introduces criminal penalties for SACCO board directors who cannot produce governance evidence. This profile REQUIRES implementation of the core OMP protocol as defined in [I-D.veridom-omp]. The full specification is also available at [ZENODO-OMP]. | |||||||||||||
| draft-veridom-omp-sgapac-00.txt | ||||||||||||||
| OMP Domain Profile: AI Governance Evidence Under Singapore's Model AI Governance Framework,MAS FEAT Principles,and the ASEAN Guide on AI Governance and Ethics | ||||||||||||||
|
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in Singapore and the ASEAN region subject to the Singapore Model AI Governance Framework (Second Edition, 2020), the Monetary Authority of Singapore (MAS) FEAT Principles for financial services AI, and the ASEAN Guide on AI Governance and Ethics (2024). The profile -- designated SingapureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate the per-decision accountability evidence required by Singapore's model AI governance framework, satisfy the MAS FEAT Principles' named accountability and explainability requirements, and align with the ASEAN Guide's human oversight and consumer protection governance standards. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp). | |||||||||||||
| draft-verma-cirp-02.txt | ||||||||||||||
| A Capability-Oriented Intent Routing Protocol | ||||||||||||||
|
This document specifies the Capability-Oriented Intent Routing Protocol (CIRP), a capability-oriented protocol layer for routing intent between cryptographically identified endpoints across heterogeneous trust domains. The protocol defines capability identifiers with mandatory versioning, scoped discovery across five visibility levels, ticket-based session authorization, negotiated cryptographic suites including hybrid post-quantum key establishment, encrypted peer-to-peer session establishment, and mutually attested invocation receipts with hash-chained integrity. Payload semantics are opaque to the CIRP layer. CIRP messages are carried by transport bindings. The initial binding is datagram-oriented and maps CIRP control-plane and session messages onto UDP. Other bindings, including QUIC/TLS-based bindings, may be specified separately. This revision clarifies the protocol architecture in response to early review. It distinguishes CIRP core semantics from transport bindings, separates endpoint identity from reachability locators, separates discovery from authorization, and introduces no wire-format changes. | |||||||||||||
| draft-vicente-acme-pqc-agility-profile-05.txt | ||||||||||||||
| Post-Quantum Cryptographic Agility Profile for ACME | ||||||||||||||
|
This document defines an Automated Certificate Management Environment (ACME) [RFC8555] profile extension that enables ACME servers and clients to express per-account and per-order post-quantum cryptographic (PQC) posture. The extension introduces a pqcAgility metadata object in the ACME directory, an optional pqcAgility member in order objects, and a server-side adequacy scoring mechanism that determines whether a given order satisfies an account's declared PQC readiness threshold. The profile is designed for both public and private ACME deployments and does not modify the core ACME state machine: it adds discoverable capability metadata and per-order policy directives that servers MAY enforce. Multi-tenant ACME servers MUST implement tenant-isolation controls that prevent cross-account PQC posture leakage. This document is distinguished from draft-giron-acme-pqcnegotiation [I-D.giron-acme-pqcnegotiation], which defines algorithm negotiation at the ACME protocol level. This profile operates above the negotiation layer: it defines per-account posture scoring, adequacy thresholds, hybrid policy bits, rotation epoch anchoring, and tenant- isolation requirements that apply regardless of which negotiation mechanism is used. | |||||||||||||
| draft-vicente-lamps-pqchc-02.txt | ||||||||||||||
| A Post-Quantum Hybrid-Commitment Certificate Extension (PQCHC) | ||||||||||||||
|
This document defines a non-critical X.509 certificate extension, the Post-Quantum Hybrid Commitment (PQCHC), that allows a certificate issued with a classical or hybrid key to carry a verifiable, cryptographically bound commitment to a specific future post-quantum algorithm and a Commitment Validity Time. The PQCHC commitment binds to a hash of the committed future public key and algorithm identifier, enabling a relying party to verify that a subsequently issued post-quantum certificate honors the earlier commitment. This mechanism provides a crypto-agility signal for certificate-lifecycle automation, including ACME Renewal Information (ARI), to plan and verify PQC migration. | |||||||||||||
| draft-vicente-lamps-rotation-envelope-03.txt | ||||||||||||||
| CA-Side Post-Quantum Rotation Envelope for X.509 Issuance Continuity | ||||||||||||||
|
This document defines the X.509 Post-Quantum Rotation Envelope extension, a Certification Authority (CA) side commitment mechanism that allows an issuing CA to publish, sign, and bind to its issued certificates a machine-verifiable guarantee of post-quantum (PQ) or PQ/T hybrid issuance continuity across the CA's own key-rotation boundaries. The mechanism is complementary to, and does not overlap with, subject-side commitments such as the continuityPeriod field defined in [I-D.reddy-lamps-x509-pq-commit]: where that draft captures the CA's continuity obligation to continue presenting PQ or composite certificates after the current certificate's notAfter, this document captures the issuing CA's parallel obligation to remain capable of issuing such certificates across its own root and intermediate key rotations during the same migration window. The Rotation Envelope extension carries a SHA-384 hash of a CA- published, signed JSON manifest hosted at a stable /.well-known/pki- rotation-envelope URI under the issuer's authorityInfoAccess host. The manifest enumerates: (a) the algorithm identifiers the CA commits to continue supporting for issuance through a stated envelopeNotAfter date, (b) the successor-CA SubjectPublicKey hashes already provisioned for the next CA key generation, and (c) the OCSP and CRL distribution endpoints that will remain authoritative through the envelope window. Relying parties that understand the extension can verify, at any time during the current certificate's lifetime, that the CA's published continuity posture matches what was bound at issuance, detecting silent CA-side degradation, unannounced CA replacement, or rollback of PQ-capable issuance commitments. This document is filed independently and is intended to be considered alongside, not in place of, [I-D.reddy-lamps-x509-pq-commit]. The two mechanisms address orthogonal sides of the same PQ migration window: subject-side declaration of intent (Reddy et al.) and CA-side guarantee of issuance capability (this document). | |||||||||||||
| draft-vicente-oauth-apm-05.txt | ||||||||||||||
| Authorization Posture Mechanism (APM): Per-Transaction Consistency for OAuth 2.0 | ||||||||||||||
|
This document describes the Authorization Posture Mechanism (APM), a method by which an OAuth 2.0 [RFC6749] authorization server, or a resource server acting on its behalf, re-evaluates the mutual consistency of three bound factors -- the client certificate, the access token, and the device posture -- on a per-request basis for privileged operations, rather than only at session establishment. When re-evaluated posture degrades relative to the posture under which the token was issued, APM defines deterministic, least- privilege Graduated Outcomes including scope reduction and method restriction, rather than a binary allow or deny. | |||||||||||||
| draft-vicente-pquip-multitenant-pki-requirements-05.txt | ||||||||||||||
| PQC Certificate Rotation Requirements for Multi-Tenant PKI Environments | ||||||||||||||
|
This document specifies requirements for post-quantum cryptography (PQC) certificate rotation in multi-tenant public key infrastructure (PKI) environments. Multi-tenant PKI deployments — in which a single PKI platform issues and manages certificates for multiple distinct tenant organizations — face coordination challenges that single- tenant PKI deployments do not encounter during PQC migration. | |||||||||||||
| draft-vicente-pquip-pqc-readiness-gaps-05.txt | ||||||||||||||
| PQC Readiness Observability Gaps in Networked Computing Environments | ||||||||||||||
|
This document identifies observability gaps that prevent network operators and security teams from determining the post-quantum cryptography (PQC) readiness state of networked computing environments. PQC readiness requires knowing which cryptographic algorithms are in use across the environment, which are vulnerable to quantum attack, and which have been or are being migrated to NIST- approved PQC algorithms. Current network protocols and management frameworks do not provide sufficient visibility to answer these questions at scale. | |||||||||||||
| draft-vidiniotis-crp-core-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vidiniotis-crp-headers-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vidiniotis-crp-spec-006-safety-policy-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-viftode-trustchain-trust-01.txt | ||||||||||||||
| Trust Computation for the TrustChain Bilateral Ledger Protocol | ||||||||||||||
|
This document specifies trust computation, audit recording, delegation, and key succession mechanisms for the TrustChain bilateral ledger protocol (draft-pouwelse-trustchain-01). The base protocol specifies a bilateral block structure for recording pairwise interactions but explicitly leaves trust computation out of scope. This document fills that gap by defining: (1) a canonical hash computation for cross-implementation compatibility, (2) an interaction graph constructed from half-block pairs, (3) pluggable Sybil-resistant path-diversity algorithms over the interaction graph -- maximum network flow (Edmonds-Karp) and personalized random walks (MeritRank), (4) a multiplicative trust score combining connectivity, chain integrity, and interaction diversity, (5) an audit block type for single-player recording of agent actions as a signed, hash- chained log when no counterparty is available, (6) a delegation protocol for transitive authority with budget splitting and revocation, (7) a bilateral succession protocol for key rotation, and (8) a chain anchoring mechanism that binds chain heads to external time-stamping authorities for evidence-grade deployments. | |||||||||||||
| draft-vijayvargiya-http-fetch-once-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-vinnakota-mime-url-policy-01.txt | ||||||||||||||
| Policy-Controlled Handling of URLs in MIME Messages | ||||||||||||||
|
This document defines a MIME-based mechanism for policy-controlled handling of URLs in email messages. The mechanism provides an alternative to hyperlink rewriting techniques used for click-time security enforcement. By avoiding modification of original URLs and introducing policy metadata, this approach improves interoperability, preserves message integrity, and enhances privacy. | |||||||||||||
| draft-vitap-ml-dsa-webauthn-05.txt | ||||||||||||||
| ML-DSA for Web Authentication | ||||||||||||||
|
This document describes implementation of Passwordless authentication in Web Authentication (WebAuthn) using Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. | |||||||||||||
| draft-vmhosting-fi-nameservers-00.txt | ||||||||||||||
| Name Server Provider and Domain Name Registrar Operational Framework | ||||||||||||||
|
This document describes an operational framework for service providers that operate authoritative Domain Name System (DNS) services, domain name registration services, or both. It covers DNS zone provisioning, authoritative name server operation, delegation management, service availability, DNSSEC, domain registration lifecycle operations, access control, monitoring, incident response, abuse handling, and privacy considerations. This document does not define a new DNS protocol, registry protocol, or domain registration policy. It describes operational practices that can be applied by providers using existing DNS and domain registration protocols and interfaces. | |||||||||||||
| draft-voet-bgp-oob-validation-00.txt | ||||||||||||||
| Out-of-Band Path Validation to Mitigate Inter-AS Routing Exploits | ||||||||||||||
|
This document describes a mechanism for mitigating Inter-AS routing exploits and path tampering without introducing real-time cryptographic processing overhead on core routing engines. By utilizing Out-of-Band (OOB) Cryptographic Validation combined with localized caches via the RPKI-to-Router (RTR) protocol and Autonomous System Provider Authorization (ASPA), networks can asynchronously verify path plausibility. This architecture supports incremental, partial deployment to protect infrastructure against malicious traffic redirection and unauthorized path propagation at major internet exchange points. | |||||||||||||
| draft-vos-cfrg-pqpake-02.txt | ||||||||||||||
| Hybrid Post-Quantum Password Authenticated Key Exchange | ||||||||||||||
|
This document describes the CPaceOQUAKE+ protocol, a hybrid asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting secure against quantum-capable attackers. CPaceOQUAKE+ is composed of two stages — CPace and OQUAKE+ — that run sequentially, with the output of CPace feeding as the secret_context into OQUAKE+. OQUAKE+ is an augmented variant of OQUAKE that adds password confirmation. This document also describes standalone OQUAKE+, a post-quantum aPAKE, and CPaceOQUAKE, the hybrid symmetric PAKE composed of the CPace and OQUAKE stages. This document recommends configurations for CPaceOQUAKE+. | |||||||||||||
| draft-vroonen-idr-bgp-bestpath-nh-selection-03.txt | ||||||||||||||
| BGP best path next-hop selection enhancements | ||||||||||||||
|
BGP [RFC4271] has originally been designed to carry IPv4 routing information over the Internet. IP routing being "hop-by-hop" in nature, NEXT_HOP which purpose is to carry the address of the next router to send the IP packet to. In BGP, the next-hop may not be a directly connected router, hence, when evaluating paths, a BGP speaker must determine if the next-hop is resolvable and, if so, determine the internal cost to reach it. The incremental use of tunneling technologies to carry traffic between routers (e.g.: GRE, MPLS, SR-MPLS, SRv6...) may violate the assumption that the address carried in the NEXT_HOP is representative of the actual forwarding next-hop. These technologies decouple the BGP control-plane's view of the next-hop from the data-plane's actual forwarding endpoint. This document describes the problems that arise from this decoupling. These problems include sub-optimal path selection, incorrect resolvability tracking of the forwarding path leading to traffic drop or misrouting, and others. This document specifies how BGP obtains resolvability, preference, metric, and tracking information from resolution of the forwarding path and uses those values as inputs to BGP path selection. | |||||||||||||
| draft-vso-cpp-core-03.txt | ||||||||||||||
| Content Provenance Profile (CPP) Core | ||||||||||||||
|
The Content Provenance Profile (CPP) is an open specification for cryptographically verifiable media capture provenance. This document defines the core data model, hashing conventions, Merkle tree construction rules, RFC 3161 Time-Stamp Authority (TSA) anchoring protocol, and offline verification procedures for CPP. CPP enables capture devices to produce tamper-evident provenance records that bind media content to external timestamps via trusted third parties. Unlike self-attestation models, CPP requires independent timestamp verification through RFC 3161 TSA services, providing externally verifiable proof of when media was captured. CPP defines self-attested signer identity, hardware-backed key requirements, chain context for partial submission detection, a Completeness Invariant for omission detection, an OPTIONAL depth analysis extension for screen detection, and an OPTIONAL Pre-Publish Verification Extension. It also defines interoperability mappings with the C2PA specification. This revision (-03) corrects a normative length constraint on the LeafHashMethod value, corrects the description of the relationship between the CPP Merkle construction and Certificate Transparency, adds a verifier obligation to cross-check TreeSize against the sealed event count, documents the limits of leaf-duplication padding, and positions CPP within the Verifiable AI Provenance Framework (VAP) profile family and relative to the SCITT architecture (RFC 9943). | |||||||||||||
| draft-vu-aimem-bundle-00.txt | ||||||||||||||
| Memory Interchange Bundle Format for AI Agents | ||||||||||||||
|
This document specifies a vendor-neutral interchange format for the persistent memory of AI agents — preferences, decisions, identity claims, pitfalls, and procedures that an agent accumulates across sessions. The format is a self-contained JSON Bundle with explicit conformance levels (Producer, Consumer, Bidirectional). Implementations MAY accompany the Bundle with an HTTP Profile that exposes export and import endpoints. The goal is to allow a user's "agent brain" to move between cloud services, on-premise installations, and third-party implementations without lock-in, in a manner that interoperates with existing right- to-erasure obligations such as [GDPR-A17]. This document is self-contained: all schema fields normatively required by Producers and Consumers are defined inline. An informative reference implementation is cited in [AIMEM-REF]. | |||||||||||||
| draft-vulnetix-crit-02.txt | ||||||||||||||
| Cloud Resource Identifier Templates (CRIT) | ||||||||||||||
|
This document specifies the Cloud Resource Identifier Templates (CRIT) format. A CRIT record provides a machine-readable, parameterised template for locating cloud-native resources affected by a known vulnerability. CRITs do not define cloud resource identifier schemas; those are defined normatively by each cloud provider. CRITs define a variable system for expressing partially- known or consumer-resolved values within those provider-defined schemas, together with temporal, remediation, and detection metadata sufficient to determine exposure status and drive remediation workflows. Each CRIT record is bound to exactly one vulnerability identifier. Cross-provider and multi-resource-type coverage of a single vulnerability is expressed as a set of CRIT records sharing the same vulnerability identifier, each independently specifying the provider- specific fix details, propagation mechanism, and detection strategy applicable to that resource type. | |||||||||||||
| draft-wadkins-agentproto-action-determinability-00.txt | ||||||||||||||
| Independent Determinability of Agent Actions | ||||||||||||||
|
Evidence that an agent was authorized to act does not establish that the authorization was enforced, that the action was executed, or that the intended effect occurred. These are distinct transitions. This document defines requirements for making a claimed agent transition independently determinable after the original interaction has ended. The requirements address binding the material action and governing conditions to the transition at decision time, identifying which revision of a mutable governing artifact was in force, preventing later substitution, and preserving enough information for an independent evaluator to establish the claimed transition after participants, sessions, credentials, keys, or agent instances are no longer available. This document defines no evidence format, token, action identifier, delegation protocol, audit system, registry, or transparency service. | |||||||||||||
| draft-wallace-aipref-grant-binding-02.txt | ||||||||||||||
| A Verifiable-Credential Binding for AI Usage Preferences: Expressing Grants that Lift AIPREF Preferences | ||||||||||||||
|
The AI Preferences (AIPREF) vocabulary lets those with rights in a digital asset express preferences -- for example, that training of AI models is disallowed -- about how automated systems process that asset. Such a preference expresses a reservation. It does not, by itself, provide a verifiable, revocable record of a specific grant that lifts a preference for a specific party. This document describes that gap and proposes a candidate mechanism: a cryptographically signed, offline-verifiable credential that expresses a grant referencing an AIPREF usage category and a specific asset, that any party can verify without contacting the grantor, and that the grantor can revoke. It is intended as a starting point for discussion, not as a finished specification. The mechanism is preference-general. Training is used throughout as the worked example because it is the reservation most widely discussed, but nothing in the construction is specific to it: the credential binds whichever usage category was reserved to a named party, and the same procedure applies to any other category the vocabulary expresses. What the mechanism establishes is that a grant exists, is authentic, is unrevoked, and was in force at a stated time. It does not adjudicate whether the grantor had standing to grant, and it is not an enforcement or access-control mechanism. | |||||||||||||
| draft-wan-emu-aka-prime-identity-fragmentation-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-agent-runtime-telemetry-system-00.txt | ||||||||||||||
| Agent Runtime Telemetry System | ||||||||||||||
|
Large language model (LLM)-driven agents are increasingly deployed in large-scale production environments, where multi-agent collaboration, chained tool invocation, and long-context reasoning have become standard execution patterns. However, existing distributed systems telemetry frameworks primarily focus on infrastructure-level telemetry, such as network traffic, host metrics, and service health, and provide limited visibility into internal agent reasoning and execution semantics.This results in several recurring challenges in production environments, including inconsistent metric definitions across platforms, lack of end-to-end execution traceability, difficulty in root cause analysis, and limited interoperability among heterogeneous telemetry systems. This document defines a unified capability framework for Agent Runtime Telemetry Systems. It standardizes two telemetry collection planes: Network-side collection at gateways and traffic ingress layers, and Agent-side instrumentation within the agent runtime environment. It further specifies structured telemetry models, cross-layer trace correlation mechanisms, runtime metrics, and anomaly detection and remediation workflows. The framework enables interoperable telemetry across heterogeneous agent systems and deployment environments. It supports unified telemetry ingestion, end-to-end execution trace reconstruction, behavioral telemetry, and closed-loop anomaly analysis, providing a standardized foundation for agent operations, reliability engineering, and compliance auditing. | |||||||||||||
| draft-wang-cats-green-challenges-08.txt | ||||||||||||||
| Green Challenges in Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
As mobile edge computing networks sink computing tasks from cloud data centers to the edge of the network, tasks need to be processed by computing resources close to the user side. Therefore, CATS was raised. Reducing carbon footprint is a major challenge of our time. Networks are the main enablers of carbon reductions. The introduction of computing dimension in CATS makes it insufficient to consider the energy saving of network dimension in the past, so the green for CATS based on network and computing combination is worth exploring. This document outlines a series of challenges and associated research to explore ways to reduce carbon footprint and reduce network energy based on CATS. | |||||||||||||
| draft-wang-cats-odsi-01.txt | ||||||||||||||
| An Architecture for Open,Decentralized,and Scalable Large Language Model Inference | ||||||||||||||
|
Large Language Model (LLM) inference is normally operated by one provider, even when the provider distributes execution across many sites. This document describes a different system model in which independently operated and mutually untrusted participants contribute compute, memory, model storage, and network capacity to one inference service. No single administrative entity is required to admit participants, select every execution path, hold the complete model, verify all results, or settle all resource contributions. This document defines the Open, Decentralized, and Scalable Inference (ODSI) architecture. It specifies the architectural roles, trust boundaries, named objects, protocol-independent interfaces, execution workflow, verification choices, timing model, and security and privacy requirements needed to construct a multi-operator inference overlay. It also identifies the protocol and operational choices that each ODSI deployment must specify so that independently developed participants can interoperate. ODSI is related to Computing-Aware Traffic Steering (CATS), but it does not extend the CATS single-provider model across trust domains. CATS mechanisms can be used within a participating domain or as an input to local path selection. Cross-domain membership, model governance, execution verification, and settlement are separate ODSI functions. This document is Informational and does not define a wire format, consensus algorithm, payment system, or new CATS metric. | |||||||||||||
| draft-wang-ccs-runtime-verification-00.txt | ||||||||||||||
| A Runtime Verification Receipt Format for Agent Auditing | ||||||||||||||
|
The Correctover Conformance Shape (CCS) defines a tamper-evident, cryptographically bound receipt format that provides runtime verification for agent tool invocations. Each CCS receipt captures a seven-dimensional verification outcome -- Structure, Schema, Latency, Cost, Identity, Integrity, and Security -- as a single artifact suitable for consumption by audit, compliance, and observability systems. CCS is designed as a pluggable runtime verification infrastructure layer that complements -- but does not replace -- existing and emerging agent protocol work at the IETF. Specifically: (1) the AUDIT effort (draft-kuehlewind-audit-architecture) defines an auditing architecture with Action Record and Authorization Transition Record types; a CCS receipt provides the verifiable, tamper-evident evidence payload that can populate these record types with cryptographically bound proof of runtime governance decisions. (2) The agentproto WG-forming effort (IETF 126 BoF) addresses agent-to- agent and agent-to-tool communication protocols; CCS provides per- invocation, sub-millisecond runtime verification that operates beneath the session/transport layer, complementing protocol-level context exchange with evidence-level integrity guarantees. Version 1.1 of the CCS receipt comprises 29 fields with full Ed25519 signature coverage, including three causal chain fields (rule_version, tool_call_id, args_digest) that elevate the Integrity dimension from behavioral traceability to verifiable decision causality. The reference implementation (ccs-verifier v1.1.0, PyPI) passes 154 conformance tests across all verification dimensions. This document specifies the CCS Receipt Schema, the Canonical Configuration model, the nine binding mechanisms, key management, transport requirements, verifier source classification, conformance levels, and negative test cases. CCS is protocol-agnostic: it is not bound to Model Context Protocol (MCP), Agent2Agent (A2A), or any other specific agent protocol, and can be integrated into any runtime that governs tool invocations. | |||||||||||||
| draft-wang-cep-01.txt | ||||||||||||||
| Co-Evolve Binding Profile (CEP) A JEP/HJS Profile for AI Evolution-Change Evidence Binding | ||||||||||||||
|
This document defines the Co-Evolve Binding Profile (CEP) v0.5, an optional profile for binding AI evolution-change records to external anchor references, evidence descriptors, and exportable receipt bundles. CEP is designed for use with the Judgment Event Protocol (JEP) and Human Judgment Structure (HJS), and can be combined with other JEP-based profiles such as JAC and COE. CEP provides infrastructure for creating, binding, exporting, and validating evidence about declared AI evolution-change claims. CEP does not determine human sovereignty, AI alignment, governance authority, model safety, legal compliance, fairness, appeal rights, explanation rights, or whether an AI evolution event is permitted or prohibited. CEP follows a minimal-core design. The core defines evolution-change record digest binding, external anchor references, evidence references, receipt bundles, and structural validation. Change classifications, binding claims, review references, rollback or mitigation references, multi-party export, and determinability reports are optional extensions or deployment profiles. | |||||||||||||
| draft-wang-cfrg-key-combiners-01.txt | ||||||||||||||
| HMAC Based Hybrid Key Combiners for Multiple Keys | ||||||||||||||
|
As a fundamental building block in security protocols, a key combiner is used to combine two or more input cryptographic keys, some potentially compromised, into a single pseudorandom output key. Most of the existing key combiners are for two input keys. This draft specifies two provably secure constructions of key combiners for multiple keys [WWW25], which is particularly useful in post-quantum migration where multiple input keys may be produced by different algorithms or even different approaches [RFC9370], [ETSI25]. Namely, here the input keys can be two or more, and the combined output key remains pseudorandom if at least one of the input keys is secure, i.e., uniformly random and unknown to an attacker. The two constructions, called HKCv1 and HKCv2, are based on the extract-then- expand paradigm of HMAC (Keyed-Hashing for Message Authentication) [RFC2104]. HKCv1 is designed for simultaneously available input keys using concatenation, while HKCv2 is tailored for scenarios where input keys arrive incrementally, using an iterative HMAC structure. [EDNOTE: .... ] | |||||||||||||
| draft-wang-coe-01.txt | ||||||||||||||
| Cognition-Oriented Emergence (COE): A JEP Profile for Shared Observation and State-Claim Evidence | ||||||||||||||
|
This document defines Cognition-Oriented Emergence (COE) v0.5, an optional profile of the Judgment Event Protocol (JEP) for binding observation records, validation records, shared-state claims, and evidence references across heterogeneous world models and cognitive units. COE provides verifiable shared-observation infrastructure. It does not determine objective world truth, factual causality, governance consensus, legal effect, operational authority, fairness, trust weights, or compliance. A valid COE record proves cryptographic binding and structural consistency of declared observations, validations, state claims, and evidence references. It does not prove that a shared-state claim is true, complete, uniquely determined, or sufficient for any external target fact. COE follows a minimal-core design. The core defines JEP-based record binding and validation. State-synthesis policies, consensus methods, version anchoring, timestamp anchoring, determinability reports, adapter records, and multi-party evidence views are optional extensions or deployment profiles. | |||||||||||||
| draft-wang-ctp-definition-01.txt | ||||||||||||||
| CTP/0: Cognitive Time Protocol -- Definition and Framework | ||||||||||||||
|
This document describes CTP/0, the definition layer of the Cognitive Time Protocol (CTP) family. CTP/0 is a conceptual reference framework for representing, comparing, and referencing time-related claims in AI and agent systems. It defines terminology for cognitive events, event-density claims, ordering claims, branching claims, and declared emergent temporal-structure claims. CTP/0 does not define a wire protocol, message format, signature format, hash-chain format, governance process, physical theory of time, theory of consciousness, or legal accountability framework. Where verifiable records are needed, CTP-compatible claims can be bound to external event or receipt infrastructure such as JEP, HJS, JAC, COE, or CEP. This revision narrows the original CTP/0 draft to an informational framework. Metrics such as Cognitive Event Density (CED), Causal Arrow Entropy (CAE), Verifiable Delay Function (VDF) evidence, and time-related evidence chains are treated as optional claim or evidence profiles, not as universal measures of intelligence, cognition, truth, safety, or responsibility. | |||||||||||||
| draft-wang-dmsc-drisac-01.txt | ||||||||||||||
| Distributed Onboarding and Information Synchronization of Agent Capabilities | ||||||||||||||
|
AI Agents may dynamically join, leave, and update their capabilities while participating in interactions across administrative domains. Efficient capability discovery in such environments requires mechanisms to onboard agent capabilities and maintain consistent capability information across distributed management entities. Existing service registration and discovery mechanisms do not necessarily provide a capability-oriented mechanism for distributed synchronization and hierarchical forwarding of agent capability information. This document proposes a distributed and hierarchical mechanism for AI Agent capability onboarding, information synchronization, and capability-based discovery. The mechanism introduces a hierarchical capability classification model and defines two functional entities: the Agent Capability Management Server (ACMS), which maintains and synchronizes capability information, and the Agent Capability Access Server (ACAS), which manages locally attached agents. Capability information is aggregated and propagated among ACMSs, while access information for locally attached agents is maintained by ACASs. A capability table is used to determine forwarding toward relevant ACMSs, and an access mapping table is used for local agent matching. The document also describes onboarding and intent-driven capability discovery procedures. The mechanism is intended to provide a distributed control-plane foundation for capability-aware agent discovery and does not define agent-to-agent interaction or task execution protocols. | |||||||||||||
| draft-wang-dmsc-terminology-ioa-networking-01.txt | ||||||||||||||
| Terminology for Networking Infrastructure in the Internet of Agents | ||||||||||||||
|
The emergence of the Internet of Agents (IoA) introduces new requirements for interoperable collaboration among autonomous agents across heterogeneous networks, platforms, and administrative domains. Supporting such environments requires common understanding of infrastructure functions, collaboration mechanisms, semantic interaction, and trust-related concepts. This document defines terminology for networking infrastructure in IoA environments, with a focus on Dynamic Multi-agent Secured Collaboration (DMSC). The terminology defined in this document is intended to support consistent usage across DMSC-related architecture, framework, and protocol specifications. | |||||||||||||
| draft-wang-emu-fs-reauth-02.txt | ||||||||||||||
| Forward Secure Reauthentication in the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA') | ||||||||||||||
|
This draft specifies an update to RFC 9678, "Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)". This update enables forward security of the Transient EAP Keys (TEKs) for protecting EAP packets, which are not in EAP-AKA' FS. Based on this extension, the executions of reauthentication after a full authentication will be unlinkable to each other and then the privacy of end users is enhanced. This update is also applicableto the successors of RFC 9678, with post-quantum key encapsulation mechanisms (KEMs) or hybrid KEMs. | |||||||||||||
| draft-wang-grow-bmp-bgp-rib-stats-ext-01.txt | ||||||||||||||
| BGP RIB Fine-Grained Filtering Statistics Extensions for BGP Monitoring Protocol (BMP) | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) defines mechanisms to monitor BGP running status and routing information bases (RIBs). [RFC9972] extended BMP statistics reporting by introducing advanced BGP RIB stat types. However, with the rapid deployment of path-level cryptographic security protocols (such as ASPA) and the complex interactions between control plane and hardware forwarding resources, network operators require granular, behavior-driven observability into why routes are discarded, invalidated, or restricted at both the ingress and egress boundaries. This document updates the registry established by [RFC7854] and extended by [RFC9972] by defining some fine-grained BGP RIB monitoring statistics types covering hardware resource exhaustion, next-hop resolution anomalies, structured route leaks ([RFC7908]), and ingress/egress ASPA verification states. Furthermore, it introduces a 4-bit control flag space within the Stat Type TLV to enable dynamic differential rate monitoring and proactive asynchronous trigger-driven telemetry. | |||||||||||||
| draft-wang-grow-bmp-policy-preview-00.txt | ||||||||||||||
| BGP Route Policy Pre-view and Intent Verification Using BGP Monitoring Protocol | ||||||||||||||
|
Deploying BGP route policies in live production networks carries significant operational risks, often resulting in unintended route leaks, suboptimal routing paths, or blackholes. This document proposes an extension to the BGP Monitoring Protocol (BMP) that enables a BGP speaker to pre-view and dry-run a candidate route policy within a localized control-plane sandbox. The resulting post- policy route changes (deltas) are streamed asynchronously to a centralized controller via a new BMP message type. This architecture allows the controller to verify policy alignment with network intents, subsequently triggering either an explicit commit or a rollback before any forwarding plane changes take effect. | |||||||||||||
| draft-wang-grow-bmp-rpki-mon-reqs-03.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-hjs-accountability-05.txt | ||||||||||||||
| HJS: Accountability Receipts for AI Agents A Minimal JEP Profile for Exportable AI Receipts | ||||||||||||||
|
This document defines HJS, a minimal accountability receipt infrastructure for AI agents. HJS is a profile of the Judgment Event Protocol (JEP) and does not define an independent event signing protocol. HJS uses JEP events to bind signed event claims to AI-agent behavior records, receipt manifests, optional privacy-preserving human participant references, and optional deployment-specific evidence references. The HJS core is intentionally small. It defines behavior-record digest binding, receipt manifests, receipt bundles, and validation of cryptographic and structural consistency. All other capabilities, including human privacy modes, participant-supplied references, post- event review references, explanation-material references, risk descriptors, model evidence, tool-call evidence, policy-check evidence, multi-party export, and cryptographic capability profiles, are optional extensions or deployment profiles. HJS is infrastructure. It does not assign legal liability, prove subjective intent, define governance rules, enforce monitoring, define fairness, define appeal rights, define explanation rights, determine authorization validity, or establish regulatory compliance. | |||||||||||||
| draft-wang-idr-bgp-upa-00.txt | ||||||||||||||
| BGP-based Unreachable Prefix Advertisement for Inter-Domain Fast Reroute | ||||||||||||||
|
This document specifies a mechanism for advertising unreachable prefixes across Autonomous Systems using BGP. The mechanism enables fast convergence in VPN services when backbone source nodes become unreachable, by allowing Unreachable Prefix Advertisement (UPA) routes propagated through BGP across AS boundaries. This solution extends the IGP-based UPA mechanism defined in RFC9929 to inter- domain scenarios, ensuring remote PEs can promptly detect and react to failures in source domains. The route is not used for packet forwarding but solely for BGP next-hop reachability resolution, enabling fast failover of BGP VPN routes. | |||||||||||||
| draft-wang-idr-dpf-01.txt | ||||||||||||||
| BGP Deterministic Path Forwarding (DPF) | ||||||||||||||
|
Modern data center (DC) fabrics typically employ Clos topologies with External BGP (EBGP) for plain IPv4/IPv6 routing. While hop-by-hop EBGP routing is simple and scalable, it provides only a single best- effort forwarding service for all types of traffic. This single best-effort service might be insufficient for increasingly diverse traffic requirements in modern DC environments. For example, loss and latency sensitive AI/ML flows may demand stronger Service Level Agreements (SLA) than general purpose traffic. Duplication schemes which are standardized through protocols such as Parallel Redundancy Protocol (PRP) require disjoint forwarding paths to avoid single points of failure. Congestion avoidance may require more deterministic forwarding behavior. This document introduces BGP Deterministic Path Forwarding (DPF), a mechanism that partitions the physical fabric into multiple logical fabrics. Flows can be mapped to different logical fabrics based on their specific requirements, enabling deterministic forwarding behavior within the data center. | |||||||||||||
| draft-wang-idr-flowspec-dip-origin-as-filter-13.txt | ||||||||||||||
| Destination-IP-Origin-AS Filter for BGP Flow Specification | ||||||||||||||
|
This document defines an extension to the Border Gateway Protocol (BGP) Flow Specification (FlowSpec) to enable filtering based on the Origin Autonomous System (AS) of the destination IP address. This extension is particularly useful in mitigating Distributed Denial of Service (DDoS) attacks where the target IP addresses are dynamic but belong to a specific destination AS. | |||||||||||||
| draft-wang-idr-flowspec-sip-origin-as-filter-01.txt | ||||||||||||||
| Source-IP-Origin-AS Filter for BGP Flow Specification | ||||||||||||||
|
This document defines an extension to the Border Gateway Protocol (BGP) Flow Specification (FlowSpec) to enable filtering based on the Origin Autonomous System (AS) of the source IP address. This extension is particularly useful in mitigating Distributed Denial of Service (DDoS) attacks where the source IP addresses are dynamic but belong to a specific source AS. | |||||||||||||
| draft-wang-idr-path-attribute-orf-00.txt | ||||||||||||||
| Path Attribute Outbound Route Filter (PA-ORF) for BGP-4 | ||||||||||||||
|
This document defines a family of Outbound Route Filter (ORF) Types for controlling the propagation of BGP Path Attributes. The Path Attribute ORFs (PA-ORFs) enable a BGP speaker to dynamically request that a peer suppress, remove, refine, or constrain the propagation of selected BGP Path Attributes when constructing outbound UPDATE messages for a given AFI/SAFI. This document defines four ORF Types: Path Attribute Type ORF; Path Attribute Subtype ORF; Unknown Path Attribute ORF; and Path Attribute Propagation Scope ORF. These ORF Types reuse the ORF Capability and ROUTE-REFRESH procedures defined in [RFC5291]. No new BGP Path Attribute or BGP message type is introduced. PA-ORFs are intended to reduce unintended propagation of BGP Path Attributes, especially Optional Transitive attributes whose semantics are valid only within a limited administrative, service, or technology domain. | |||||||||||||
| draft-wang-ipsecme-kem-auth-ikev2-04.txt | ||||||||||||||
| KEM-based Authentication for IKEv2 with Post-quantum Security | ||||||||||||||
|
This draft specifies a new authentication mechanism, called KEM (Key Encapsulation Mechanism) -based authentication, for the Internet Key Exchange Protocol Version 2 (IKEv2). This is motivated by the fact that some post-quantum KEMs (like ML-KEM) are more efficient than post-quantum signature algorithms (like ML-DSA). | |||||||||||||
| draft-wang-ipsecme-multi-auth-ikev2-pq-01.txt | ||||||||||||||
| Multi-Authentication in IKEv2 with Post-quantum Security | ||||||||||||||
|
Motivated to mitigate security threats against quantum computers, this draft specifies a general authentication mechanism in the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296], called Multi-Authentication. Namely, two peers can negotiate two or more authentication methods to authenticate each other. The authentication methods selected do not necessarily belong to the same category. This mechanism is achieved by adding a new value (17) (TBD) in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA. To run Multi-Authentication, two peers send the SUPPORTED_AUTH_METHODS Notify, defined in [RFC9593], to negotiate two or more authentication methods for authentication in IKEv2. [EDNOTE: Code points for Multi-Authentication may need to be assigned in the "IKEv2 Authentication Method" registry [IANA-IKEv2], maintained by IANA] | |||||||||||||
| draft-wang-jac-02.txt | ||||||||||||||
| JAC: Declared Dependency Chains for Agent Receipts A JEP/HJS Extension Profile for Chain Infrastructure | ||||||||||||||
|
This document defines JAC v0.5, a minimal declared-dependency chain infrastructure for agent and AI-agent receipt systems. JAC is a profile over the Judgment Event Protocol (JEP) and, when AI-agent behavior receipts are used, over HJS. JAC does not define an independent event format, signature syntax, hash format, replay mechanism, identity framework, or governance framework. JAC uses JEP extension fields to bind a signed event or receipt element to a declared parent dependency. The core is intentionally small: a single chain extension records a declared dependency link. Optional extensions can record state declarations, assignment references, handoff references, result references, capability claims, input/output references, and declared chain breaks. JAC provides infrastructure only. It records signed dependency declarations; it does not determine factual causality, responsibility, fault, authorization validity, assignment validity, handoff validity, task correctness, fairness, entitlement, legal effect, or regulatory compliance. | |||||||||||||
| draft-wang-jep-action-mandate-profile-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-jep-conformance-00.txt | ||||||||||||||
| 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. --- | |||||||||||||
| draft-wang-jep-judgment-event-protocol-06.txt | ||||||||||||||
| 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. --- | |||||||||||||
| draft-wang-jep-profiles-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-jep-semantic-interoperability-00.txt | ||||||||||||||
| Semantic Interoperability for the Judgment Event Protocol | ||||||||||||||
|
This document defines semantic interoperability requirements for the Judgment Event Protocol (JEP). JEP-Core defines the event syntax, event classes, signatures, hashes, references, extension processing, and validation levels for signed judgment-related events. This document does not modify those mechanisms. Where this document restates JEP-Core semantics, JEP-Core remains authoritative. Instead, this document defines the minimum shared semantic invariants required for independent systems to interpret JEP events consistently across implementations, profiles, organizations, and jurisdictions. The document specifies core semantic roles, core semantic relations, event- class interpretation rules for Judgment, Delegation, Termination, and Verification events, verification-scope semantics, semantic identifiers, profile-extension constraints, semantic validation results, non-inference rules, semantic conformance requirements, initial semantic registry requirements, and cross-jurisdictional boundaries. It defines semantic registry contents and constraints, but does not define operational registry governance beyond the requirements stated here. This document does not define legal effect, moral responsibility, regulatory compliance, runtime enforcement, access-control decisions, domain-specific workflows, or external truth. A JEP event is a protocol- semantic record. Whether that record is sufficient to support an external target claim is outside the scope of this document and must be determined by an applicable profile, evidence policy, domain rule, or target-support analysis. | |||||||||||||
| draft-wang-lamps-root-ca-cert-rekeying-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wang-lisp-ai-agent-01.txt | ||||||||||||||
| Using LISP as a Network Substrate for AI Agent Communication | ||||||||||||||
|
The emergence of distributed artificial intelligence (AI) systems, particularly those composed of autonomous agents operating across cloud, edge, and endpoint environments, introduces new networking requirements. These include location transparency, seamless mobility, multi-homing, and logical isolation at scale. This document explores how the Locator/ID Separation Protocol (LISP) can serve as a robust network substrate to meet these requirements. The document outlines use cases, design considerations, and minimal extensions to the existing LISP framework to support context-aware mapping and AI agent-centric communication. | |||||||||||||
| draft-wang-mcast4ai-p2mp-scaleup-00.txt | ||||||||||||||
| AI P2MP Multicast in Scale-UP Network | ||||||||||||||
|
MoE (Mixture-of-Experts) has been adopted in scale-up GPU connections by the mainstream Large Language Models, such as Llama4, Mixtral, and DeepSeekV3. This document focuses on the AI multicast protocol evolution for MoE in scale-up scenarios, analyzing the challenges and proposing potential protocol evolutions. | |||||||||||||
| draft-wang-ring-load-aware-00.txt | ||||||||||||||
| Load-Adaptive Priority Migration Mechanism for Deterministic Switched Ethernet | ||||||||||||||
|
This document proposes a Load-Adaptive Priority Migration (LAPM) mechanism for deterministic switched Ethernet. The mechanism classifies traffic into three criticality levels (TC0/TC1/TC2), which are logically equivalent to the foundational classification of network slicing. An inverse M/D/1 queuing model is introduced to derive per-hop network utilization from measured forwarding delay, requiring no additional probe traffic. A four-level load classification scheme with hysteresis logic drives dynamic remapping of the IEEE 802.1Q Priority Code Point (PCP), enabling traffic priority to adapt as network load changes. LAPM serves as a runtime complement to the scheduling framework defined by RFC 9320. Existing DetNet queuing mechanisms (TAS, CBS, CQF, Guaranteed Service) rely on statically pre-configured offline parameters, whereas LAPM monitors utilization in real time and adaptively adjusts PCP when load levels cross pre-defined thresholds. This capability is particularly critical for deployment scenarios with time-varying traffic patterns, including automotive backbone networks, industrial automation, and professional audio/video systems. Experimental validation on a 5-node ring topology (1000BASE-T) across three traffic classes reveals the existence of three operationally distinct regions — normal, transitional, and saturated — where load bursts in the transitional region cannot be captured by the EWMA- smoothed utilization metric alone. A cross-domain maximum aggregation mechanism coordinates load-level decisions across multiple VLANs via a shared global variable, ensuring consistent priority migration policy enforcement. In summary, the LAPM mechanism provides a means to guarantee low- latency transmission for critical flows through dynamic load-based priority control. | |||||||||||||
| draft-wang-sidrops-fcbgp-protocol-05.txt | ||||||||||||||
| FC-BGP Protocol Specification | ||||||||||||||
|
This document defines an extension, Forwarding Commitment BGP (FC- BGP), to the Border Gateway Protocol (BGP). FC-BGP provides security for the path of Autonomous Systems (ASs) through which a BGP UPDATE message passes. Forwarding Commitment (FC) is a cryptographically signed segment to certify an AS's routing intent on its directly connected hops. Based on FC, FC-BGP aims to build a secure inter- domain system that can simultaneously authenticate the AS_PATH attribute in the BGP UPDATE message and alleviate route leaks in the BGP routing system. The extension is backward compatible, which means a router that supports the extension can interoperate with a router that doesn't support the extension. | |||||||||||||
| draft-wang-space-computing-consideration-01.txt | ||||||||||||||
| Consideration for Space-Based Computing Infrastructure Network | ||||||||||||||
|
This document presents considerations for a Space-Based Computing Infrastructure Network from use cases and requirements. | |||||||||||||
| draft-wang-tls-hybrid-ecdh-scloud-02.txt | ||||||||||||||
| Post-quantum Hybrid ECDHE-SCloud+ Key Exchange for TLS 1.3 | ||||||||||||||
|
This draft specifies how to enable hybrid key exchange with ECDHE and SCloud+ in Transport Layer Security protocol version 1.3 (TLS 1.3) to mitigate quantum threats. SCloud+ is an unstructured lattice based KEM (key encapsulation mechanism) with post-quantum security. This draft follows the post-quantum hybrid key exchange framework specified by [RFC9954], by concatenating the public keys and ciphertexts of ECDHE and SCloud+. This draft specifies three concrete hybrid key exchange schemes, which are X25519SCloud+128, SecP256r1SCloud+192 and SecP384r1SCloud+256. | |||||||||||||
| draft-wang-tls-service-affinity-05.txt | ||||||||||||||
| Service Affinity Solution based on Transport Layer Security (TLS) | ||||||||||||||
|
This draft proposes a service affinity solution between client and server based on Transport Layer Security (TLS). It defines a minimal extension to TLS 1.3 by which a server instance can authorize a client to resume an established session on a different instance of the same service (for example, another node of a load-balanced cluster) and request, in band, that the client do so. The relocation authorization is carried inside the server's own session ticket, so it inherits the security properties of TLS 1.3 ticket-based resumption. The relocation target is an opaque value that either directly carries the switchover address (for example, an IP address and port) or is an identifier resolved by the application or control plane. This document also introduces a Reliable Framing Layer that operates above the TLS record layer to provide message framing, sequence numbering, acknowledgment tracking, and automatic retransmission. The Framing Layer ensures zero application data loss during TLS session migration by buffering unacknowledged data frames and retransmitting them to the new server endpoint after migration completes. | |||||||||||||
| draft-wang-token-aware-usecases-requirements-00.txt | ||||||||||||||
| Token Service Flow Awareness: Use Cases and Requirements | ||||||||||||||
|
This document outlines the use cases and requirements for token service flow awareness, providing the IETF working group with a standardized reference to better support the assurance of the user’s end-to-end experience. | |||||||||||||
| draft-wang-topology-aware-collective-communication-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-watal-spring-srv6-sfc-sr-aware-functions-05.txt | ||||||||||||||
| SRv6 SFC Architecture with SR-aware Functions | ||||||||||||||
|
This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits: * Comprehensive Management: a centralized controller for SFC, handling SR Policy, link-state, and network metrics. * Simplicity: no SFC proxies, which reduces the number of nodes and address resource consumption. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Source Packet Routing in Networking Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/spring/. Source for this draft and an issue tracker can be found at https://github.com/watal. | |||||||||||||
| draft-watal-srv6ops-srv6-sfc-deployment-00.txt | ||||||||||||||
| SRv6 Service Function Chaining Deployment | ||||||||||||||
|
This document describes the deployment and operational experience of the SRv6 Service Function Chaining (SFC) architecture defined in [I-D.draft-watal-spring-srv6-sfc-sr-aware-functions] on an academic IPv6 backbone network. The deployed system integrates SRv6 forwarding, service function management, topology collection, path computation, and flow classification to enable dynamic provisioning of SFC services via a web-based management interface. This document summarizes the deployment architecture, operational workflow, experience, and lessons learned, and provides guidance for network operators deploying SRv6 SFC services. | |||||||||||||
| draft-watts-agent-authority-transition-receipts-00.txt | ||||||||||||||
| Agent Authority Transition Receipts for Agentic Systems | ||||||||||||||
|
Autonomous agents increasingly act across administrative and security domains using workload identities, OAuth credentials, delegated authorization, attestations, and policy engines. Existing mechanisms can establish identity, delegation, or access rights, but deployments still lack a common artifact that records which policy and which evidence were evaluated when an operation moved into an authorized, denied, revoked, or expired authority state. This document defines an Agent Authority Transition Receipt (AATR), a signed, non-bearer receipt that cryptographically binds an agent operation to the principal, policy, evidence set, decision, audience, validity interval, and predecessor authority state used for that decision. AATR intentionally separates evidence from authorization and authorization from execution. Missing or indeterminate required evidence fails closed. AATR is designed to compose with OAuth, workload identity, remote attestation, transparency services, and agent-specific delegation protocols rather than replace them. | |||||||||||||
| draft-watts-agent-evidence-boundary-00.txt | ||||||||||||||
| Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts | ||||||||||||||
|
Autonomous agents increasingly make or propose consequential actions using premises assembled from model outputs, memory, tools, telemetry, and external data. Existing authentication and authorization mechanisms can establish who is acting, under whose delegation, and which operation is permitted, but they do not by themselves establish whether the proposition that triggered the operation has adequate support. This document defines the Evidence Qualification Receipt (EQR), a transport-neutral JSON data model and fail-closed verification procedure for binding a proposition to a declared evidence profile, its supporting evidence digests, contradiction state, freshness, and evaluation result. An EQR can be PASS, FAIL, or INDETERMINATE. A PASS EQR is only an authorization input: it is never itself permission to execute. The design is append-only: changed evidence produces a successor receipt rather than rewriting prior epistemic state. The goal is to prevent evidence, provenance, or model confidence from silently acquiring authorization semantics. | |||||||||||||
| draft-watts-ai-identity-conformance-00.txt | ||||||||||||||
| AID-1 Provider-Independent Conformance Requirements and Test-Vector Model | ||||||||||||||
|
This document defines provider-independent conformance requirements for AID-1. It specifies the execution model for a deterministic machine-readable test-vector corpus, including canonicalization, cryptographic, identity-binding, delegation, authorization, temporal, revocation, replay, attestation, provenance, and integration cases. The conformance corpus contains 69 vectors. Six replay cases are architectural boundary tests, including R5, which requires AID-1 verification to succeed while a downstream D6 scientific- admissibility decision rejects the same evidence. | |||||||||||||
| draft-watts-oauth-agent-revocation-closure-00.txt | ||||||||||||||
| Revocation Closure for Agentic Authorization Systems | ||||||||||||||
|
Agentic systems can derive and distribute authority across delegated agents, workloads, credentials, queues, and long-running operations. Existing revocation mechanisms can invalidate a credential or authorization grant, but credential invalidation alone does not establish that every path from revoked authority to a consequential effect has been closed. This document defines a protocol-neutral model for revocation closure. It introduces authority graphs, consequential sinks, revocation cut sets, closure states, closure budgets, and closure receipts. The model is intended to complement OAuth 2.0, workload identity, transaction-token, and agent-authorization work. It does not define a new authorization protocol, token format, or AI safety mechanism. | |||||||||||||
| draft-watts-scientific-admissibility-evidence-00.txt | ||||||||||||||
| Scientific Admissibility Evidence Records for Verifiable Research Provenance | ||||||||||||||
|
This document describes a portable JSON evidence-record format for representing bounded scientific claims, preregistered procedures, admissibility evaluations, provenance artifacts, lifecycle events, and cryptographic integrity metadata. The format is intended to make research evidence exchangeable and mechanically checkable without treating cryptographic integrity, schema conformance, scientific admissibility, valuation, governance, or truth as equivalent concepts. This document is an individual informational proposal. It does not define a network transport protocol, does not establish scientific truth, and does not assign decision authority to automated systems. | |||||||||||||
| draft-wdh-srv6ops-secservice-03.txt | ||||||||||||||
| ESP Protection for Services over SRv6 | ||||||||||||||
|
This document describes a mechanism for protecting selected service traffic using IPsec ESP while transporting the traffic over an SRv6 domain. The approach enables service payloads to be encrypted prior to SRv6 encapsulation, allowing the SRv6 header to remain visible for segment-based forwarding within the provider network. This mechanism supports services or applications that require additional confidentiality and integrity protection, even when carried over an operator-managed SRv6 domain. | |||||||||||||
| draft-wei-aic-identity-cert-01.txt | ||||||||||||||
| AI Agent Identity Certificate (AIC) Extension for X.509 v3 | ||||||||||||||
|
This document defines the AI Agent Identity Certificate (AIC) Extension for X.509 v3 certificates. The AIC extension enables binding of an AI Agent's cryptographic identity to a natural person (principal), providing cryptographic evidence that can support attribution of AI-autonomous actions to a principal. This specification intentionally separates cryptographic delegation from authorization semantics: AIC defines the cryptographic binding between agent and principal, while all capability and policy semantics are defined externally by vendors, industries, or regulators. The extension is identified by the IANA Private Enterprise Number 66257 assigned to the document author's organization. The AIC extension carries agent identity fields (agentId, delegationMode), a principal identifier (principalUid) linking the agent to the authorizing principal, a container-based capability declaration, authorization boundary constraints, and delegation authorization evidence with replay protection. A companion PrincipalAuthorization extension anchors Principal-side grant declarations and delegation policies. An authorizationConstraints container provides offline-verifiable execution boundaries (IP range, window). An extensibility framework allows vendor-specific and user- specific metadata. This document specifies the ASN.1 module, OID registration, field semantics, delegation model, and extensibility framework. Security considerations for deployment in regulated enterprise environments are discussed. | |||||||||||||
| draft-wei-aic-jwt-01.txt | ||||||||||||||
| AI Agent Identity Certificate (AIC) JSON Web Token Profile | ||||||||||||||
|
The AI Agent Identity Certificate (AIC) defines a data model in which the cryptographic identity of an AI agent is bound to a responsible principal, together with a structured capability container, delegation mode, authorization constraints, and principal-signed delegation evidence. The normative definition of this model is specified by the AIC specification, where it is encoded in ASN.1 and carried in X.509 certificates, enabling authorization decisions at the transport layer, including fully offline operation. Many HTTP, web, and OAuth 2.0 (RFC 6749) deployments cannot present X.509 certificates at the transport layer. This document therefore defines AIC-JWT as a JWT-based application-layer representation of the AIC data model defined by the AIC specification. AIC-JWT is a companion representation, not a replacement for the X.509 form and not a new authorization model. AIC-JWT uses the standard JWT (RFC 7519) and JWS (RFC 7515) mechanisms as its carrier and cryptographic envelope. Its authorization semantics are inherited from the AIC model rather than defined by JWT or OAuth. In particular, the outer AIC-JWT is issuer- signed and carries the principal-signed DA JWT as the value of the top-level da claim, preserving the two-layer signature model of AIC. The normative content of this document is limited to: * a mapping from the X.509 AIC extension fields to JWT claims that preserves the AIC data model and its two-layer signature model; * representation and key-binding rules for the principal-signed DelegationAuthorization; * validation rules for AIC-JWT, including claim consistency, audience, and key-binding checks; and * a thin OAuth 2.0 consumption profile defining presentation of the DA at a token endpoint as an RFC 7523 JWT bearer authorization grant and the projection of the AIC authorized and representative delegation modes into OAuth roles. | |||||||||||||
| draft-wen-agent-workload-scheduling-00.txt | ||||||||||||||
| Dynamic Scheduling of Update and Query Workloads in Agent Service Discovery Nodes | ||||||||||||||
|
Agent service discovery nodes may need to process two classes of workloads concurrently: Agent registration and dynamic state updates, and discovery queries issued by other Agents. These workloads compete for shared processing resources but have different performance objectives. Delayed state updates can cause a service discovery node to rely on stale workload, availability, or QoS information, while delayed queries can increase Agent-selection latency and the completion time of multi-Agent tasks. This document describes a scheduling framework for coordinating update and query processing in a multi-Worker Agent service discovery node. To estimate the demand of each workload, the framework considers total queued work, waiting time, deadline pressure, recent load, state freshness, and, for updates, the expected freshness gain from processing a pending update. These estimates determine how Worker capacity is divided between the two queues, which remain active in parallel. The framework also incorporates update merging and deduplication, freshness-aware dependencies between state updates and discovery queries, hysteresis-based resource reallocation, minimum resource holding time, and intra-queue task prioritization. Different deployment conditions can be accommodated by adjusting the corresponding weights and thresholds without changing the scheduling structure itself. | |||||||||||||
| draft-wendt-stir-cert-tn-attr-ext-00.txt | ||||||||||||||
| TN Attribute Certificate Extension for STI Certificates | ||||||||||||||
|
This document specifies a non-critical X.509 v3 certificate extension that conveys a set of self-asserted attributes describing the telephone numbers identified in the certificate's TNAuthList. The attributes are declared by the holder of the certificate about its own telephone numbers and require no separate authority token, because they describe or constrain only those numbers and grant no authority to any other party. The extension defines an extensible framework with an IANA registry of attribute types and seeds that registry with four types: a PASSporT Placement Service (PPS) URI, a do-not-originate indication, a do-not-originate-messaging indication, and a set of authorized originating providers. Relying parties use these self-declarations as policy signals, treating communications that do not conform to them as candidates for blocking. The mechanism is backward compatible with existing STIR certificates. | |||||||||||||
| draft-wendt-stir-tn-domain-binding-01.txt | ||||||||||||||
| Binding a Domain Identifier to Telephone Number Authority in STIR Certificates | ||||||||||||||
|
This document defines a mechanism for binding a domain identifier to telephone number authority within a STIR certificate. A certificate produced under this mechanism carries, as a co-validated pair, the telephone numbers or service provider codes a subject is authorized for in a TNAuthList extension and a domain the subject controls in a SubjectAltName dNSName entry. The binding is established at issuance by requiring proof of domain control and validation of a TNAuthList authority token within a single certificate issuance, such that the resulting certificate attests that the same entity holds both. The mechanism applies to STIR certificates whose TNAuthList contains telephone number entries, service provider code entries, or both, allowing a domain to be bound to the right-to-use holder for a set of numbers or to the provider identified by a service provider code. This document defines the issuance conformance requirements and the relying party verification rule that together make the binding meaningful. It does not define telephone number or service provider code authorization or domain validation, both of which are specified elsewhere and referenced here. | |||||||||||||
| draft-wendt-stir-vesper-10.txt | ||||||||||||||
| VESPER - Verifiable STI Presentation and Evidence for RTU | ||||||||||||||
|
This document defines VESPER (Verifiable STI Presentation and Evidence for RTU), a profile for the use of delegate certificates in STIR. VESPER profiles the binding of telephone number authority to a domain identifier, the STIR certificate and PASSporT specifications, ACME-based authority token issuance, and certificate transparency into a delegate certificate that associates the right-to-use for a telephone number with the entity behind the number asserted in the PASSporT orig claim. This document describes the certificate usage, a PASSporT usage profile for SIP signaling, and a portable Right-to- Use Token for use outside of SIP. | |||||||||||||
| draft-wendt-stir-vesper-oob-03.txt | ||||||||||||||
| VESPER Out-of-Band OOB | ||||||||||||||
|
This document describes a mechanism for delivering authenticated telephone call identity information using the VESPER framework for use where in-band signaling does not carry the identity end to end, or where there is no in-band path between the parties at all. By supporting an out-of-band (OOB) transport model, this approach enables entities to publish and retrieve signed PASSporT assertions independent of end-to-end delivery within an in-band signaling path such as a SIP-based VoIP network. These PASSporTs are signed with VESPER delegate certificates, which identify the entity holding the right-to-use for a telephone number and bind it to that entity's domain identity. This document also introduces support for Connected Identity to the STIR OOB model, enabling the called party to respond with a signed PASSporT asserting its identity, thereby binding the identities of both parties to the transaction and enhancing end-to- end accountability. The OOB mechanism provides a delivery path for PASSporTs where in-band delivery within a signaling path such as SIP is unavailable or is not the path used, enabling verifiers to confirm the association between the originating telephone number and the identity asserting authority as part of the broader VESPER trust framework. | |||||||||||||
| draft-wendt-stir-vesper-use-cases-04.txt | ||||||||||||||
| Verifiable STI Presentation and Evidence for RTU (VESPER) Use Cases and Requirements | ||||||||||||||
|
This document describes use cases and requirements that motivate VESPER (Verifiable STI Presentation and Evidence for RTU), work within the Secure Telephone Identity Revisited (STIR) framework. STIR establishes that a signing credential is authorized for a telephone number, but not what entity holds that authority, what verifiable information that entity declares about its numbers, or how a relying party obtains and verifies this across the channels where a number appears. This document presents a set of use cases that illustrate the resulting trust gaps and states the requirements a solution should satisfy. It motivates the mechanisms defined in the VESPER framework and its companion specifications rather than defining them. | |||||||||||||
| draft-westerbaan-dnssec-mldsa-04.txt | ||||||||||||||
| Module-Lattice Digital Signature Algorithm for DNSSEC | ||||||||||||||
|
This document describes how to specify Module-Lattice-Based Digital Signature Algorithm (ML-DSA) keys and signatures in DNS Security (DNSSEC). It uses the ML-DSA-44 parameter set defined in FIPS 204. ML-DSA-44 is believed to be secure even against adversaries in possession of a cryptographically relevant quantum computer. | |||||||||||||
| draft-westerbaan-tls-keyshare-recommendations-02.txt | ||||||||||||||
| Updated recommendations for TLS keyshares | ||||||||||||||
|
This document recommends X25519MLKEM768 for use in TLS by updating its entry in the TLS Supported Groups registry (previously EC Named Curve Registry) to Recommended in the light of the future arrival of cryptographically relevant quantum computers. [[ NOTE I use key share in the title and here as it's more accurate than "group" and perhaps more well known in the context TLS than key agreement or key exchange. ]] | |||||||||||||
| draft-westerbeck-reason-protocol-00.txt | ||||||||||||||
| reason:// -- A URI Scheme and Registry Protocol for Validated Agent Reasoning Artifacts | ||||||||||||||
|
This document defines the "reason://" URI scheme and associated registry protocol for naming, storing, and retrieving compressed structural reasoning artifacts across distributed autonomous agent networks. An artifact enters the registry only by winning a live competitive arbitration round scored by the Web Agent Reasoning Federation (WARF) protocol. The artifact schema contains no raw data fields; the structural representation is mathematically non- invertible (empirical reconstruction rate r = 0.0149). The protocol is designed to function as open infrastructure — analogous to DNS for network addresses or HTTP for document retrieval — for the agentic internet. | |||||||||||||
| draft-westerbeck-warf-protocol-00.txt | ||||||||||||||
| Web Agent Reasoning Federation (WARF) | ||||||||||||||
|
WARF (Web Agent Reasoning Federation) defines a deterministic, identity-free protocol for arbitrating competing agent outputs. Three flows -- Xfer, Xact, and Xchange -- provide structural signature transfer, identity-free profile matching, and open semantic arbitration respectively. After Xchange arbitration determines a winner, the Xtend pipeline (VASE corpus expansion + Balmathic kappa acceleration detection) automatically quality-gates the result. If the caller supplied a valid reason:// address and kappa exceeds the promotion threshold, the winning artifact is promoted into the reason:// reasoning artifact registry at the exact URI provided by the caller. The protocol produces auditable, SHA-256 chained verdicts without exposing raw data, model weights, or agent identity. | |||||||||||||
| draft-westerlund-avtcore-srtp-gcm-sst-00.txt | ||||||||||||||
| GCM-SST Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) | ||||||||||||||
|
This document defines how the GCM-SST (Galois Counter Mode with Strong Secure Tags) Authenticated Encryption with Associated Data (AEAD) algorithm family can be used to provide confidentiality and data authentication in the Secure Real-time Transport Protocol (SRTP). GCM-SST addresses known weaknesses in AES-GCM for short authentication tags, making it well suited for media encryption use cases where low overhead is critical. | |||||||||||||
| draft-westerlund-moq-overview-00.txt | ||||||||||||||
| Media over QUIC Overview | ||||||||||||||
|
This document provides a high-level overview of the Media over QUIC (MoQ) protocol suite. It describes the architecture, data model, transport protocol, streaming formats, and security mechanisms that together enable scalable low-latency media delivery over the Internet. The document explains how these components relate to each other and how they are composed to create interoperable media applications. | |||||||||||||
| draft-westerlund-schc-compute-address-00.txt | ||||||||||||||
| SCHC Compute-Address Compression/Decompression Actions for Dynamically Assigned IP Addresses | ||||||||||||||
|
This document defines new Matching Operators (MOs) and Compression/ Decompression Actions (CDAs) for the Static Context Header Compression and fragmentation (SCHC) framework defined in RFC 8724. These extensions enable efficient compression of dynamically assigned IP addresses, including IPv4 addresses assigned via DHCP, IPv6 prefixes learned through SLAAC or DHCPv6, IPv6 Interface Identifiers (IIDs), and IPv6 temporary privacy addresses generated per RFC 8981. The mechanism relies on both the compressor and decompressor sharing knowledge of the set of addresses assigned to the device. Addresses are organized into deterministically sorted tables, allowing compression to a small index value. For temporary IPv6 addresses, a synchronized generation algorithm enables compression to an epoch and counter value. | |||||||||||||
| draft-westerlund-tls-gcm-sst-00.txt | ||||||||||||||
| Use of Galois Counter Mode with Strong Secure Tags (GCM-SST) in TLS,DTLS and QUIC | ||||||||||||||
|
This document defines cipher suites based on AES-GCM-SST and Rijndael-GCM-SST (Galois Counter Mode with Strong Secure Tags) for use in TLS 1.3, DTLS 1.3, and QUIC. GCM-SST provides authenticated encryption with near-ideal forgery probabilities for short authentication tags, making it suitable for bandwidth-constrained environments where reduced per-packet overhead is important. This document specifies cipher suites with 96-bit and 112-bit authentication tags. | |||||||||||||
| draft-westphal-lsr-isis-database-checksumming-00.txt | ||||||||||||||
| IS-IS Database Fingerprinting | ||||||||||||||
|
In large IS-IS networks it is useful to quickly verify whether the link-state databases on all routers have synchronized properly and to derive a rough metric of flooding diffusion behavior. This document proposes a lightweight database fingerprinting mechanism for IS-IS along with YANG model extensions providing easy access to such information. | |||||||||||||
| draft-wiggers-tls-authkem-psk-05.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-wilaw-moq-cmcd-event-timeline-00.txt | ||||||||||||||
| CMCD transmission over MSF Event Timeline | ||||||||||||||
|
Defines the transmission of CMCD data over MSF Event Timeline tracks. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://wilaw.github.io/CMCD-over-MSF-event-timeline/draft-wilaw-moq- cmcd-event-timeline-latest.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- wilaw-moq-cmcd-event-timeline/. Source for this draft and an issue tracker can be found at https://github.com/wilaw/CMCD-over-MSF-event-timeline. | |||||||||||||
| draft-wilaw-moq-scte35-event-timeline-00.txt | ||||||||||||||
| SCTE35 transmission over MSF Event Timeline | ||||||||||||||
|
Defines the transmission of SCTE 35 data over MSF Event Timeline tracks. | |||||||||||||
| draft-wilaw-moq-webvtt-msf-00.txt | ||||||||||||||
| WebVTT Packaging for MOQT Streaming Format | ||||||||||||||
|
This document specifies the JSON packaging format for delivering WebVTT caption and subtitle content as event timeline tracks within the MOQT Streaming Format (MSF). | |||||||||||||
| draft-wilder-scitt-physical-site-engage-receipt-04.txt | ||||||||||||||
| A SCITT Profile for Physical-Site Engagement Receipts | ||||||||||||||
|
This document defines a SCITT profile for _Physical-Site Engagement Receipts_ (PSER): tamper-evident, signed, offline-verifiable records that describe an autonomous or human-directed physical engagement at a specific real-world site governed by a defined operating envelope. Each receipt is a SCITT Signed Statement as defined by the SCITT architecture, encoded as a COSE Single Signer message, carrying a JCS-canonicalized JSON payload with a five-artifact vocabulary describing (1) the _Site_, (2) the _Operator_ and _Actor_, (3) the _Engagement Window_ and _Envelope_, (4) the _Attestation Evidence_ from a Trusted Execution Environment (TEE), and (5) the _Adapter Write-In_ recording that the receipt was posted into an out-of-band operations layer. A Physical-Site Engagement Receipt is registerable in any conforming SCITT Transparency Service, obtaining a Receipt that proves the Statement's inclusion in that Service's verifiable data structure. Registration does not establish that the Issuer registered every receipt it issued. This profile deliberately makes a NARROW, checkable claim -- "this is a tamper-evident, signature-verifiable record that a specific engagement occurred at a specific site under a specific envelope, and its evidence was sealed by a specific TEE" -- and explicitly does NOT claim that the engagement was safe, correct, or wise, that the site conditions were as described, or that any downstream operational outcome followed. Compliance verdicts derived from the receipt (SLA credit, insurance underwriting, regulatory audit) are the responsibility of the relying party and its policies, not of this profile. The profile is designed around a three-party trust model in which no single party can unilaterally forge or repudiate a receipt: the _Site Owner_ controls physical access to the TEE hardware and keeps it running (they can unplug the box, and cannot forge what it signs); the _TEE silicon vendor_ attests the key material inside the TEE through its hardware root of trust (silicon vouches for the key); and the _Issuer_ writes the vocabulary, registers Signed Statements with a Transparency Service, and posts the resulting receipt into the site's operations layer via a WRITE_ONLY adapter. This separation is normative in this profile: implementations MUST NOT collapse these three roles into a single custodian, and relying parties MUST NOT trust a receipt that lacks any one of them. | |||||||||||||
| draft-wiley-ztaaat-00.txt | ||||||||||||||
| Zero Trust Attribute Assertion Tokens | ||||||||||||||
|
This document defines a mechanism for verifying boolean eligibility claims using cryptographically signed assertion tokens. A relying party can verify authoritative answers to predefined claims without trusting the presenting subject and without learning the subject's identity. Each assertion token encodes exactly one boolean claim. The system guarantees authenticity and integrity of claim assertions. It does not provide identity, authentication, or subject uniqueness. | |||||||||||||
| draft-williams-http-bearer-extension-01.txt | ||||||||||||||
| HTTP Bearer Auth Method Extensions | ||||||||||||||
|
This document specifies an improved HTTP 401 and 407 flow for Bearer authentication where user-agents (or client applications) can automatically fetch requested tokens from a Security Token Service (STS). A fallback to an OpenID Connect (OIDC) redirect flow is included. This improved 401/407 Bearer flow, when used, elides the need for Proof Key for Code Exchange (PKCE) and does not impose on application Universal Resource Identifier (URI) query parameter design. As well this extension allows for user-agent caching of tokens. | |||||||||||||
| draft-williams-intent-token-02.txt | ||||||||||||||
| The Intent Token: A Cryptographic Authorization Primitive for Autonomous Agents | ||||||||||||||
|
This document specifies the Intent Token, a cryptographic authorization primitive for autonomous AI agent systems. An Intent Token binds an autonomous agent action to a cryptographically signed, human-declared authorization envelope before that action is executed. The Intent Token addresses a fundamental gap in existing authorization frameworks: while OAuth 2.0, OIDC, and related standards govern identity and access at the session level, no standardized primitive exists for governing what an autonomous agent is authorized to DO at the moment of action. The Intent Token provides this primitive. It is model-agnostic, transport-agnostic, and composable with existing authorization infrastructure. Revision -01 extended the specification with Fractal Intent Token (FIT) binding for multi-scale agent systems, Authorization Fluidity for context-sensitive mode switching, and the Fractal Crypto-Temporal Graph (FCTG) as the normative audit trail data structure for continuous adaptive authorization. This revision (-02) corrects the stated patent priority date and dependent date references carried over from -01, adds a fourth documented instance of independent convergence (Broadcom's AgentMinder), and revises the characterization of AI-assisted development work in Section 12 for accuracy. | |||||||||||||
| draft-winmagic-oauth-condition-bound-keys-00.txt | ||||||||||||||
| Condition-Bound Keys for Mutual-TLS Client Authentication and DPoP | ||||||||||||||
|
Login and session protection are two markets solving one problem: verify identity before giving access. Online, access is mostly the transaction, so that is where identity should be verified. Done this way, there is no session and no login; identity assurance is embedded in the transaction: it is encrypted by a key only the right identity has. The key that does this exists only where an actor -- human or machine -- a platform, and local policy hold, now. It disappears when the conditions are no longer met. All three are observed on the endpoint. It is hardware-rooted by default and non-exfiltratable, existing nowhere else, and its presence means validity: the identity is live now. This document specifies that key and its uses: under mutual TLS, in a DPoP proof, as a raw public key, in Device Bound Session Credentials, and as a FIDO2 passkey, or in a non-FIDO mode carrying user verification without user interaction. | |||||||||||||
| draft-winmagic-wimse-condition-bounded-credentials-01.txt | ||||||||||||||
| Condition-Bounded Credentials for Workload and Agent Identity: Non-Exfiltratable Keys and Validity by Presence | ||||||||||||||
|
The WIMSE architecture binds a workload credential to a cryptographic key presented with proof of possession, and leaves credential lifetime and rotation to the implementation. In common practice the binding key is held in software and rotated frequently, because a software key can be copied: rotation is a compensating control for a key that can be exfiltrated. This document defines a profile in which the binding key is hardware- rooted and non-exfiltratable, and in which credential validity is gated by attested conditions -- the workload and its required posture being measured and present -- rather than by a fixed expiry. Two consequences follow. Frequent rotation is no longer required to bound exfiltration, because the key cannot leave the hardware boundary. And a grant cannot outlive the workload, even with no expiry date, because the key, and with it the ability to prove possession, is gone once the workload or its conditions cease to hold. Condition failure is therefore enforced by the key's absence rather than by a revocation message, and the credential can be appraised without a live connection to its issuing authority. The profile is specified against a verifier contract -- authority, live-instance, condition, freshness, and fail-closed checks -- that other credential profiles can share, so these properties are made explicit and reviewable without standardizing a single credential format or hardware recipe. It is offered as one conforming way to instantiate WIMSE credentials, suited to stable, attestable platforms, and is explicitly not proposed for high-churn, hardware- less workloads. | |||||||||||||
| draft-wirtgen-bgp-tls-05.txt | ||||||||||||||
| BGP over TLS/TCP | ||||||||||||||
|
This document specifies the use of TLS over TCP to support BGP. The Border Gateway Protocol (BGP) relies on TCP to establish sessions between routers. While the TCP Authentication Option (TCP-AO) provides transport-layer integrity protection against spoofing and reset attacks, it does not provide confidentiality, cryptographic peer identity, or scalable key management. This document specifies a method for establishing a secure BGP session by running BGP over a TLS 1.3 session. The underlying TCP transport MUST be protected using TCP-AO. An "Implicit TLS" model on TCP port 179 is specified as the preferred mechanism. | |||||||||||||
| draft-wkumari-dnsop-localroot-bcp-07.txt | ||||||||||||||
| Populating resolvers with the root zone | ||||||||||||||
|
DNS recursive resolver operators need to provide the best service possible for their users, which includes providing an operationally robust and privacy protecting service. Challenges to these deployment goals include difficulty of getting responses from the root servers (such as during a network attack), longer-than-desired round-trip times to the closest DNS root server, and privacy issues relating to queries sent to the DNS root servers. Resolvers can solve all of these issues by simply serving an already cached a copy of the full root zone. This document shows how resolvers can fetch, cache and maintain a copy of the root zone, how to detect if the contents becomes stale, and procedures for handling error conditions. { Editor note: This document contains a FAQ section. It will help answer questions about why this document is not a BCP but still has BCP in the name, how and why this document differs from RFC8806, etc etc etc. The FAQ section is intended to be removed before publication. } | |||||||||||||
| draft-wkumari-intarea-safe-limited-domains-07.txt | ||||||||||||||
| Safe(r) Limited Domains | ||||||||||||||
|
Documents describing protocols intended solely for use within "limited domains" often rely on edge filtering at every boundary node to prevent domain-internal traffic from leaking to the global Internet (and vice versa). Relying purely on administrative filtering creates "fail-open" designs that are susceptible to configuration errors, ACL bypass, and hardware table exhaustion. This document describes design principles and concrete mechanisms that allow limited-domain protocols to "fail-closed" by default. By leveraging Layer-2 encapsulation identifiers (such as dedicated or extended EtherTypes), link-local address scoping, and / or Hop-Limit boundaries, protocol designers can significantly reduce the operational and security risks associated with limited domain protocols. These mechanisms are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, can significantly reduce the risks. | |||||||||||||
| draft-wkumari-not-a-draft-24.txt | ||||||||||||||
| Just because it's an Internet-Draft doesn't mean anything... at all... | ||||||||||||||
|
Anyone can publish an Internet Draft (ID). This doesn't mean that the "IETF thinks" or that "the IETF is planning..." or anything similar. | |||||||||||||
| draft-wkumari-opsawg-json-geofeed-format-01.txt | ||||||||||||||
| A JSON Format for Self-Published IP Geolocation Feeds | ||||||||||||||
|
This document defines a JavaScript Object Notation (JSON) format for self-published IP geolocation feeds. It updates RFC 8805 by transitioning from the current comma-separated values (CSV) format to a more expressive JSON format, addressing the need for operational extensibility. | |||||||||||||
| draft-wmz-nmrg-agent-ndt-arch-06.txt | ||||||||||||||
| Network Digital Twin and Agentic AI based Architecture for AI-driven Network Operations | ||||||||||||||
|
A Network Digital Twin (NDT) provides a network emulation tool usable for different purposes such as scenario planning, impact analysis, and change management. Agentic AI enables dynamic goal-driven execution and adaptive behavior and closed-loop autonomy. By integrating a NDT into network management together with the Agentic AI, it allows the network management activities to take user intent or service requirements as input, automatically assess, model, and refine optimization strategies under realistic conditions but in a risk-free environment. Such environment that operates to meet these types of requirements is said to have AI-driven network operations. AI-driven network operations brings together existing technologies such as Agentic AI and NDT which may be seen as the use of a toolbox of existing components enhanced with a few new elements. This document describes an architecture for AI-driven network operations and shows how these components work together with NDT and Agentic AI capabilities. | |||||||||||||
| draft-wnd-opsawg-icon-ps-00.txt | ||||||||||||||
| Problem Statement for Observability,Intervention and Control (I&C) in Multi-Agent Autonomous Networks | ||||||||||||||
|
This document provides an overview of the issues associated with the deployment of the observability, intervention, and control of autonomous agent pipelines in large-scale heterogeneous network environments. The term "Intervention and Control" is used to describe a set of automated and human-initiated mechanisms that guarantee the capability to observe, constrain, correct, and terminate Autonomous agents at any point, for any reason, irrespective of their level of autonomy under which it operates, to ensure resilience, recovery, and operational continuity. The set of enabled observability, intervention and control reflects operator service offerings to ensure that autonomous operations can be stopped, or safely redirected when required and is designed in conjunction with agent to agent, agent to tools, agent to human interaction and service and network policy. This document also identifies several key areas that the Agent Observability, Intervention and Control group will investigate to guide its architectural and protocol work and associated documents. | |||||||||||||
| draft-wolfe-faf-agent-01.txt | ||||||||||||||
| FAFA: A Declarative Agent Capability Format | ||||||||||||||
|
This document specifies the FAF Agent Format (.fafa): a declarative, YAML-based format for an agent's identity, the capabilities it exposes, and the endpoints through which it is reached. A .fafa document describes an agent; it never instructs one. .fafa (application/vnd.fafa+yaml, IANA-registered June 2026 in the vendor tree) is the agent member of the FAF family, alongside .faf (project context) and .fafm (agent memory). It functions as a portable passport that answers four questions: who the agent is, what it may do, where it is reached, and what it must never do. Protocol- native cards (for example A2A Agent Cards and MCP Server Cards) remain useful wire formats; repository instruction files such as AGENTS.md remain the ops briefing; .fafa complements them as a house- neutral source of truth that can be projected into those formats; it does not replace them. This document documents the existing IANA vendor-tree registration. No standards-tree registration is requested. A companion white paper, "Why Agents Need a Passport," provides the production rationale and lifecycle framing. | |||||||||||||
| draft-wolfe-faf-format-02.txt | ||||||||||||||
| FAF: YAML Media Types for AI Project Context and Persistent Memory | ||||||||||||||
|
This document specifies two YAML-based media types that together form a foundational AI-context layer (FAF): .faf for static project context (what an AI agent KNOWS about a project) and .fafm for persistent agent memory (what it REMEMBERS across sessions). .faf (application/vnd.faf+yaml, registered in the IANA vendor tree 2025-10-30) carries static project context — architecture, conventions, dependencies, goals — read once and treated as canonical. .fafm (application/vnd.fafm+yaml, registered 2026-05-13) carries persistent agent memory — facts, preferences, accumulated knowledge — which mutates across sessions and supports multiple profiles (voice and knowledge). The two formats share YAML 1.2 as base syntax and MIT-licensed distribution, but differ in lifecycle: .faf is static-read-once and .fafm is mutating-persisted. This document documents the existing vendor-tree registrations and defines the "faf" well-known URI, a discovery anchor that returns a .faf context document and may reference associated memory and agent resources. | |||||||||||||
| draft-woodcock-faltstrom-external-registry-rrtypes-01.txt | ||||||||||||||
| External-Registry DNS Resource Record Types: UNECE and ISO | ||||||||||||||
|
This document defines two DNS resource record types, UNECE and ISO, which convey numeric values paired with codes drawn from registries maintained by external standards organizations: the United Nations Economic Commission for Europe (UNECE) and the International Organization for Standardization. Neither proposed RRTYPE duplicates the external registries into IANA registries; each carries codes verbatim and uses the semantics defined by the external maintainer. The document specifies presentation and wire formats for both types, records the assignment of two decimal RRTYPE identifiers under the Expert Review process of BCP 42, and suggests a common design pattern that may serve as a model for future RRTYPEs seeking to make external registries usable from the DNS without duplication. | |||||||||||||
| draft-woof-brrp-00.txt | ||||||||||||||
| Woof | ||||||||||||||
|
Woof woof woof woof Woof Woof Woof (WOOF). WOOF woof woof woof woof- bark woof woof woof Woof woof woof, woof woof woof woof woof woof woof woof woof woof woof woof woof Woof. Woof woof woof, bark woof woof woof woof woof woof woof WOOF woof woof woof woof woof WOOF WOOF, woof woof woof woof woof woof woof howl woof woof. Woof woof woof woof woof woof woof woof woof woof woof woof woof WOOF WOOF. Woof woof woof WOOF WOOF, woof woof woof Woof WOOF, WOOF, WOOF, WOOF, WOOF, woof WOOF woof woof woof woof WOOF WOOF. Woof woof Woof WOOF woof WOOF, woof woof woof woof woof woof boof woof woof woof woof woof woof woof woof woof WOOF woof. Woof woof woof WOOF WOOF woof woof arf woof woof woof woof woof woof woof woof WOOF-WOOF woof. Woof WOOF woof woof woof woof WOOF WOOF woof woof woof woof woof woof WOOF WOOF. | |||||||||||||
| draft-wu-grow-bmp-multi-instance-00.txt | ||||||||||||||
| BMP Extension for Monitoring Multiple BGP Instances | ||||||||||||||
|
The BGP Monitoring Protocol (BMP), as defined in RFC 7854, provides a means for monitoring BGP sessions. In deployments where a single device runs multiple BGP instances simultaneously - typically a base instance together with one or more additional instances, each identified by an Instance Name and potentially running in a separate process with an independent Router-ID and Autonomous System (AS) number - the existing BMP message format does not allow a Monitoring Station to distinguish peers or routes belonging to different BGP instances on the same monitored router. This document defines a new BMP Type-Length-Value (TLV) element, the BGP Instance Name TLV, that carries the Instance Name of the BGP instance associated with a given peer or route. Following the TLV extension framework defined in [I-D.ietf-grow-bmp-tlv], the new TLV MAY appear in Peer Up Notification, Peer Down Notification, Route Monitoring, Statistics Report, and Route Mirroring messages. The TLV enables a Monitoring Station to unambiguously attribute monitored BGP information to the correct BGP instance on the monitored router. | |||||||||||||
| draft-wu-idr-flowspec-redirect-group-02.txt | ||||||||||||||
| BGP Flowspec Redirect Load Balancing Group Community | ||||||||||||||
|
This document defines an extension to the BGP Community Container Attribute, which allows flowspec redirection to multiple paths. This extended community serves to redirect traffic to a load balancing group and supports both equal-cost multi-path (ECMP) and unequal-cost multi-path (UCMP) scenarios. | |||||||||||||
| draft-wu-idr-flowspec-sip-community-filter-02.txt | ||||||||||||||
| Source-IP-Community Filter for BGP Flow Specification | ||||||||||||||
|
BGP Flow Specification (BGP-FS) propagates traffic Flow Specifications and Traffic Filtering Actions using BGP NLRI and BGP Extended Community encodings. This document specifies a new BGP-FS component type to support community-level filtering within a single administrative domain. The match condition filters traffic based on the BGP Community attributes associated with the route matching the packet's source IP address. | |||||||||||||
| draft-wu-nmop-nma-nti-problem-statement-00.txt | ||||||||||||||
| Problem Statement for Standardizing the northbound Task Interface (NTI) of the Network Management Agent | ||||||||||||||
|
AI-driven Network Management Agents (NMAs) are being deployed to automate operational workflows such as cross-domain fault diagnosis and service remediation. While the IETF has standardized service data models and access protocols through the Controller NBI (RFC 8969), these provide atomic configuration and monitoring capabilities, not the semantics for delegating end-to-end operational tasks to an autonomous agent. As a result, NMA northbound interfaces are vendor-specific overlays. This document defines the problem statement for the Northbound Task Interface (NTI): the interface through which an operator or OSS delegates operational tasks to an NMA. | |||||||||||||
| draft-wullink-rpp-jscontact-profile-01.txt | ||||||||||||||
| JSContact Profile for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document defines a JSContact usage profile, conforming to the rules described in [I-D.ietf-calext-jscontact-profiles], for the RESTful Provisioning Protocol (RPP). The JSContact Profile for RPP specifies how the JSContact format defined in [RFC9982] can be used as a standardized representation of contact information within RPP operations, enabling interoperability and consistency across RPP implementations that manage contact data. | |||||||||||||
| draft-wullink-rpp-oauth2-00.txt | ||||||||||||||
| OAuth 2.0 for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes how OAuth 2.0 [RFC6749] can be used to secure RESTful Provisioning Protocol (RPP) API requests described in [I-D.ietf-rpp-core]. | |||||||||||||
| draft-wullink-rpp-oauth2-delegation-00.txt | ||||||||||||||
| Secure Delegation Management for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes how OAuth 2.0 [RFC6749] enables a third party, such as a DNS Operator, to manage delegation (name server) details for a domain name on behalf of the registrant using the RESTful Provisioning Protocol (RPP). It extends the RPP OAuth 2.0 authorization model defined in [I-D.wullink-rpp-oauth2] with mechanisms specific to third-party delegation management via RPP [I-D.ietf-rpp-core]. | |||||||||||||
| draft-wullink-rpp-oauth2-transfer-00.txt | ||||||||||||||
| Secure Object Transfer for RESTful Provisioning Protocol (RPP) | ||||||||||||||
|
This document describes how OAuth 2.0 [RFC6749] can be used to secure object transfers in RESTful Provisioning Protocol (RPP) [I-D.ietf-rpp-core]. It extends the RPP OAuth 2.0 authorization model defined in [I-D.wullink-rpp-oauth2] with mechanisms specific to federated object transfers. | |||||||||||||
| draft-wzdk-scim-agent-resource-00.txt | ||||||||||||||
| AI Agent Resource Extension for the System for Cross-domain Identity Management (SCIM) | ||||||||||||||
|
The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. This document provides a platform-neutral schema for representing AI agents' identities in SCIM JSON format, enabling them to be transferred using the SCIM protocol between a client and service provider. This establishes an agentic identity so that an agent can subsequently be authenticated and authorized to interact with the service. | |||||||||||||
| draft-x1co-httpbis-iquic-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-x1co-ussh-03.txt | ||||||||||||||
| UDP Speedy Secure Shell (USSH) | ||||||||||||||
|
This document describes UDP Speedy Secure Shell (USSH), an experimental remote shell protocol built on top of USTPS. USSH provides an interactive shell session over a secure UDP-based transport while preserving USTPS transport semantics, including challenge-validated session setup, per-session key establishment, selective retransmission, and unordered transport behavior beneath the shell layer. | |||||||||||||
| draft-x1co-ustps-05.txt | ||||||||||||||
| UDP Speedy Transmission Protocol Secure (USTPS) | ||||||||||||||
|
This document describes UDP Speedy Transmission Protocol Secure (USTPS), an experimental transport built directly on UDP for low- latency and loss-tolerant applications. USTPS provides authenticated encryption for DATA packets, readable plaintext control records authenticated by HMAC where applicable, binary UPACK DATA framing, selective retransmission, out-of-order acceptance, adaptive retransmission timeout, optional congestion control, and application- visible stream position metadata. USTPS is intentionally unordered at the transport layer and is designed to avoid transport-level Head- of-Line blocking. | |||||||||||||
| draft-xbm-intarea-icmp-query-01.txt | ||||||||||||||
| ICMP Query for IP Node Information | ||||||||||||||
|
This document introduces two new ICMP messages. They are called the ICMP Query Request and the ICMP Query Response. The ICMP Query Request requests information. The ICMP Query Response provides information in response to an ICMP Query Request. This document updates RFC 4884. | |||||||||||||
| draft-xf-pce-cats-service-02.txt | ||||||||||||||
| PCEP Extensions for Computing-Aware Traffic Steering (CATS) Service | ||||||||||||||
|
The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. The C-PS may be deployed as a PCE and the ingress CATS-Router could be viewed as a PCC. This document proposes the PCEP extensions for selecting and distributing the paths for CATS services. | |||||||||||||
| draft-xhy-hpwan-framework-04.txt | ||||||||||||||
| Framework for High Performance Wide Area Network (HP-WAN) | ||||||||||||||
|
This document defines a framework to enable the host-network collaboration for high-speed and high-throughput data transmission, coupled with fast completion time and newtork utilization of High Performance Wide Area Networks (HP-WAN). It particularly enhances the congestion control by introducing signaling mechanisms and collaborative functions, including rate negotiation, traffic scheduling, resource reservation, admission control and rate control to meet job-level objectives. | |||||||||||||
| draft-xia-ipsecme-eesp-stateless-encryption-03.txt | ||||||||||||||
| Stateless Encryption Profile for Enhanced Encapsulating Security Payload (EESP) | ||||||||||||||
|
This document specifies a stateless encryption profile for Enhanced Encapsulating Security Payload (EESP). The profile is intended for large-scale deployment scenarios in which maintaining per-flow or per-session encryption state is operationally expensive or infeasible. Instead of storing a distinct data key for each secure flow, endpoints derive per-packet or per-context data keys from a smaller set of provisioned root keying material together with packet- carried context. The document describes the deployment motivation, the stateless keying model, the mapping of required fields onto EESP extension points, context construction rules, data-key derivation processing, IV construction requirements, security considerations, and operational considerations. The intent is to realize stateless encryption as an extension profile over EESP, rather than as a parallel encapsulation format. | |||||||||||||
| draft-xia-rats-key-negotiation-integration-02.txt | ||||||||||||||
| Integration of Remote Attestation with Key Negotiation and Key Distribution mechanisms | ||||||||||||||
|
This document describes a generic way to integrate Remote Attestation (RA) with key distribution and key negotiation, so that cryptographic keys are only released to or accepted from attested and policy- compliant environments. It defines an attestation-bound key management mechanism that can be applied on top of existing secure channel and key management protocols, and illustrates it with three representative scenarios: public-cloud KMS, end-user to AI data- center communication, and enterprise-operated KMS. A format-agnostic key binding claim is introduced to express the binding between an Attester’s environment, its public keys, and a session identifier, enabling Relying Parties to use Attestation Results as an input to key distribution and key agreement decisions without changing underlying protocols. | |||||||||||||
| draft-xiao-fann-congestion-notification-for-pause-00.txt | ||||||||||||||
| Congestion Notification for Pause | ||||||||||||||
|
This document describes the necessity and feasibility to introduce a mechanism of congestion notification for pause. After receiving the L2 pause frames from the destination data center gateway, the egress provider edge node sends the congestion notifications to the upstream provider nodes and the ingress provider edge node in a format defined in this document. The upstream provider nodes and the ingress provider edge node must pause the forwarding of IP flows identified by the congestion notifications. And then the ingress provider edge node may send the L2 pause frames to the source data center gateway. | |||||||||||||
| draft-xiao-fann-fast-cnp-00.txt | ||||||||||||||
| Fast Congestion Notification Packet (CNP) in RoCEv2 Networks | ||||||||||||||
|
This document describes a Remote Direct Memory Access (RDMA) over Converged Ethernet version 2 (RoCEv2) congestion control mechanism, which is inspired by Really Explicit Congestion Notification (RECN) described in RFC 7514, also known as Fast Congestion Notification Packet (Fast CNP). By extending the RoCEv2 CNP, Fast CNP can be sent by the switch directly to the sender, advising the sender to reduce the transmission rate at which it sends the flow of RoCEv2 data traffic. | |||||||||||||
| draft-xiao-fann-fast-cnp-with-proxy-04.txt | ||||||||||||||
| Fast Congestion Notification Packet (CNP) with Proxy | ||||||||||||||
|
This document describes the necessity and feasibility to introduce a proxy network node between the congested network node and the traffic sender. The proxy network node is used to translate the congestion notification. The congested network node sends the congestion notification to the proxy network node in a format defined in this document, and then the proxy network node translates the received congestion notification to a format known by the traffic sender and resends the translated congestion notification to the traffic sender. | |||||||||||||
| draft-xiao-ippm-ioam-trace-extensions-03.txt | ||||||||||||||
| Extensions to IOAM Trace Option for Carrying Fixed-Size Data | ||||||||||||||
|
In situ Operations, Administration, and Maintenance (IOAM) Trace- Option data defined in RFC 9197 is a variable-length data, the length of this kind of data varies with the number of transited IOAM-capable nodes and the selection of data fields processed by each IOAM-capable node. This document extends the IOAM Trace Option to carry a fixed- size data, the length of this kind of data is fixed once the selection of data fields processed by each IOAM-capable node is determined, and doesn't vary with the number of transited IOAM- capable nodes. | |||||||||||||
| draft-xiao-v6ops-eds-01.txt | ||||||||||||||
| Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance | ||||||||||||||
|
This document describes Enhanced Dual Stack (EDS), a host-side framework intended to reduce the operational risk and workload of IPv6 deployment. Today, many applications select IPv6 or IPv4 using static address- selection rules. These rules provide a useful baseline, but they are not live measurements of current reachability or performance. If IPv6 is selected when it is broken or degraded, users may experience failures or delays. This creates a need for extensive upfront IPv6 validation before deployment. Happy Eyeballs (HE) reduces this risk for applications that implement it, but it does not automatically help existing applications that continue to use traditional APIs such as getaddrinfo(), socket(), and connect(). EDS aims to make IPv6/IPv4 selection performance-informed for both new and existing applications. It does this through three enhancements: | |||||||||||||
| draft-xie-bess-evpn-extension-evn6-04.txt | ||||||||||||||
| EVPN Route Types and Procedures for EVN6 | ||||||||||||||
|
EVN6 is a mechanism designed to provide Ethernet connectivity to customer sites dispersed on public IPv6 networks. At the data layer, EVN6 encapsulates Ethernet frames directly in the payload of IPv6 packets, and dynamically generates the IPv6 addresses of the IPv6 header using host MAC addresses and other information, then sends them into IPv6 network for transmission. This document proposes extensions to EVPN for EVN6, including two new route types and related procedures. | |||||||||||||
| draft-xie-qosformer-qos-assurance-00.txt | ||||||||||||||
| QoSformer: A Framework for Learning-Based QoS Prediction and Policy Evaluation | ||||||||||||||
|
Network operators need to assess how changes to quality-of-service (QoS) policies may affect individual traffic flows and shared network resources. Measurements describe observed behavior, but policy evaluation also requires predictions under candidate configurations. This document describes a framework that combines heterogeneous network measurements and configuration data in a Multiple Flow Snapshot (MFS), learns representations through masked reconstruction, and uses a Transformer-based model called QoSformer to predict throughput, delay, and resource utilization. It describes offline model preparation, online candidate evaluation, and feedback after authorized policy changes. A 5G core network use case illustrates the mapping to analytics and policy-control functions. The framework is informational: it defines neither a new wire protocol nor extensions to existing 3GPP interfaces. | |||||||||||||
| draft-xie-v6ops-ipv6only-classification-00.txt | ||||||||||||||
| Classification of IPv6-Only Networks by Levels | ||||||||||||||
|
IPv6-only networking is recognized as the ultimate goal of network evolution. However, in practice, the understanding and implementation of IPv6-only varies significantly. To address ambiguity and improve communication, this document proposes a classification for IPv6-only networks. It defines three distinct levels, from a pure state with no IPv4 support to scenarios where IPv6-only and dual-stack coexistence exists. This approach of classification is applicable to all network scenarios and aids operators and protocol designers in precisely specifying the nature of their IPv6-only deployments. | |||||||||||||
| draft-xing-quic-sdn-controller-aware-mptcp-mpquic-00.txt | ||||||||||||||
| The SDN-based MPTCP-aware and MPQUIC-aware Transmission Control Model | ||||||||||||||
|
This document aims to study and implement Multipath Transmission Control Protocol (MPTCP) and Multipath QUIC (MPQUIC) using application layer traffic optimization (ALTO) in software defined network (SDN). In a software-defined network, ALTO server collects network cost indicators (including link delay, number of paths, availability, network traffic, bandwidth and packet loss rate etc.), and the controller extracts MPTCP or MPQUIC packet header to allocate MPTCP or MPQUIC packet to suitable transmission path according to the network cost indicators by ALTO, which can reduce the probability of transmission path congestion and improving path utilization in a multipath transmission network. | |||||||||||||
| draft-xiong-detnet-flow-aggregation-05.txt | ||||||||||||||
| Framework for Flow Aggregation in Scaling Deterministic Networking (DetNet) | ||||||||||||||
|
This document provides a framework and requirements for flow aggregation in scaling Deterministic Networking (DetNet) [I-D.ietf-detnet-scaling-requirements]. It describes aggregation scenarios, benefits, and challenges in scaling networks, and derives high-level requirements applicable across different DetNet data plane technologies. The framework also discusses flow aggregation enhancement considerations including classification, identification, coordination, admission control and resource allocation. As an illustrative example, it explores how these concepts could apply to 5GS systems acting as logical DetNet nodes. This document is informational and complementary to existing DetNet specifications. | |||||||||||||
| draft-xiong-idr-cats-sr-policy-01.txt | ||||||||||||||
| BGP SR Policy Extensions for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
An SR (Segment Routing) Policy is a set of candidate paths, each consisting of one or more segment lists. The CATS (Computing-Aware Traffic Steering) can steer traffic between clients of a service and sites offering the service. This document proposes the BGP SR policy extensions for distributing CATS services. | |||||||||||||
| draft-xkk-teas-hpc-scheduler-job-metadata-00.txt | ||||||||||||||
| HPC/AI Scheduler Job Metadata Model | ||||||||||||||
|
This document defines a scheduler-facing metadata model for High Performance Computing (HPC) and AI workloads. The model captures common job, workload, scheduler, tenant, timing, and task metadata that can be mapped from heterogeneous workload managers and orchestration platforms and used as context for network service intent. | |||||||||||||
| draft-xkk-teas-hpc-service-intent-00.txt | ||||||||||||||
| HPC/AI Service Intent Model | ||||||||||||||
|
This document defines a common service intent model for High Performance Computing (HPC) and AI workloads over High Performance Wide Area Networks (HP-WANs). The model allows heterogeneous workload managers and orchestration platforms to express endpoint, communication pattern, timing, performance, data movement, policy, and admission requirements for network services without exposing technology-specific tunnel realization details. | |||||||||||||
| draft-xkk-teas-hpc-tunnel-realization-00.txt | ||||||||||||||
| HPC/AI Service Intent Tunnel Realization Model | ||||||||||||||
|
This document defines a tunnel realization model for admitted HPC and AI service intent. The model describes how a service intent instance can be associated with network realization state, including tunnel references, lifecycle, path, policy, resources, protection, admission outcome, and performance monitoring. | |||||||||||||
| draft-xkumakichi-xaip-receipts-03.txt | ||||||||||||||
| Signed Execution Receipts for AI Agent Tool Calls (XAIP Receipts) | ||||||||||||||
|
This document defines a wire format for signed execution receipts produced by AI agents when they invoke tools, services, or other agents. A receipt records the minimum facts needed to make a trust decision about a future call: who acted, who delegated, what tool was used, whether the call succeeded, how long it took, and how the call's inputs and outputs are identified (without disclosing their contents). A distinguishing property of the format is optional caller co- signature over the same canonical per-call record. When both signatures validate, the receipt cryptographically binds the identified Caller and Agent to the same canonical payload. This does not establish that either party independently observed every field, that the recorded execution was correct, or that the parties did not collude. A receipt may carry the Agent signature alone, and consumers may distinguish the two cases according to deployment policy. The format is intentionally tool-system-agnostic. The same receipt structure can be emitted by MCP (Model Context Protocol) servers, LangChain.js callback handlers, OpenAI tool-calling loops, HTTP clients, or proprietary agent runtimes. Receipts use Ed25519 signatures over a JCS-canonicalized payload, and identities are W3C Decentralized Identifiers (DIDs). This revision introduces an explicit wire-format version (formatVersion), pins the hash preimage profile, and ships executable conformance test vectors. Scoring policy, aggregation architecture, and reactive behavior in response to receipts are explicitly out of scope and left to deployments. | |||||||||||||
| draft-xls-intarea-evn6-06.txt | ||||||||||||||
| EVN6: Mapping of Ethernet Virtual Network to IPv6 Underlay for Transmission | ||||||||||||||
|
This document describes a mechanism of mapping of Ethernet Virtual Network to IPv6 Underlay for transmission. Unlike the existing methods, this approach places the Ethernet frames to be transmitted directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses stateless mapping to generate IPv6 source and destination addresses from the host's MAC addresses, the Ethernet Virtual Network identifier and site prefixes. The IPv6 packets generated in this way carry Ethernet frames and are routed to the destination site across the public IPv6 network. | |||||||||||||
| draft-xp-ippm-detnet-stamp-04.txt | ||||||||||||||
| STAMP Extensions for DetNet | ||||||||||||||
|
Deterministic Networking (DetNet) provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. The enabler to DetNet is a proper queue scheduling mechanism, such as timeslot based queueing and forwarding mechanism, which requires every router along the DetNet path to collect the basic timeslot mapping relationship between itself and its adjacent router. This document defines two Simple Two-Way Active Measurement Protocol (STAMP) TLVs, to acquire the basic timeslot mapping relationship between the local router and its adjacent router. | |||||||||||||
| draft-xsaopig-nmop-service-flow-modal-mapping-05.txt | ||||||||||||||
| Architecture for Service Flow Characteristics and Modal Mapping Based on SDN and ALTO Protocol | ||||||||||||||
|
This Internet-Draft specifies a comprehensive framework for mapping service flow characteristics to network modal resources in multi- modal intelligent computing networks. It introduces the use of the ALTO protocol for collecting service flow data and leverages an SDN architecture to separate control and data planes. The ALTO protocol facilitates the acquisition of diverse network state information, including data from several SDN domains and dynamic network environments, directly from controllers while keeping the provider's internal details confidential. It then transmits the controller's decisions using a proven method. The document details methods for characteristic identification, intelligent mapping, and continuous optimization, enabling dynamic resource allocation and improved network performance. The framework is designed to support scalable, efficient, and secure operations in environments with complex network loads and diverse service requirements. | |||||||||||||
| draft-xsaopig-nsttlp-traffic-labeling-01.txt | ||||||||||||||
| Network Service Type-Aware Traffic Labeling Protocol (NST-TLP) | ||||||||||||||
|
This document specifies a protocol mechanism for embedding service type identifiers into network packets in order to enable intelligent traffic recognition, policy-based forwarding, and resource optimization by network devices. The protocol allows standardized service type labels to be carried in IPv4/IPv6 headers, MPLS labels, or Ethernet frame headers. It is applicable to a wide range of services, including immersive VR (e.g., 1080p, 4K), scientific computing, real-time communications, and Internet of Things (IoT) applications. | |||||||||||||
| draft-xu-agentic-overlay-network-architecture-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-ccamp-impairment-info-sharing-problem-01.txt | ||||||||||||||
| Problem Statement: Information Sharing of Optical Impairments in Monitoring of Multi-Domain All-Optical Paths | ||||||||||||||
|
In multi-domain all-optical Wavelength Switched Optical Networks (WSONs), end-to-end services may traverse multiple administrative domains operated by different entities. Monitoring such services requires visibility into optical impairments that accumulate across domain boundaries. However, exchanging impairment-related information raises operational, scalability, and confidentiality concerns. Detailed metrics such as attenuation, noise, nonlinear effects, and filtering penalties may be necessary for accurate performance assessment, yet they can expose sensitive topology, equipment, or utilization information. This document describes the problem space associated with sharing optical impairment information across administrative domains for monitoring purposes. It highlights the need to balance operational visibility and confidentiality preservation, and outlines considerations for abstraction, information granularity, and trust relationships among participating operators. | |||||||||||||
| draft-xu-efficient-agent-discovery-profile-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-idr-bgp-sec-sync-00.txt | ||||||||||||||
| BGP Extension for Secure Session State Synchronization | ||||||||||||||
|
This document defines a new BGP Address Family, termed the Secure Session Synchronization Address Family, allowing BGP speakers to exchange stateful firewall, NAT, and IPSec session information across distributed nodes. This architecture facilitates zero-packet-loss failover and seamless path protection for Secure SD-WAN, SASE, and SSE multi-POP deployments, entirely bypassing the scalability limits of traditional layer-2 synchronization protocols. | |||||||||||||
| draft-xu-idr-fare-08.txt | ||||||||||||||
| Fully Adaptive Routing Ethernet using BGP | ||||||||||||||
|
Large language models (LLMs) like ChatGPT have become increasingly popular in recent years due to their impressive performance in various natural language processing tasks. These models are built by training deep neural networks on massive amounts of text data, as well as visual and video data, and often consist of billions or even trillions of parameters. However, the training process for these models can be extremely resource-intensive, requiring the deployment of thousands or even tens of thousands of GPUs in a single AI training cluster. Therefore, three-stage or even five-stage CLOS networks are commonly adopted for AI networks. The non-blocking nature of the network becomes increasingly critical for large-scale AI model training. Therefore, adaptive routing is necessary to dynamically distribute traffic to the same destination across multiple equal-cost paths, based on network capacity information along those paths. | |||||||||||||
| draft-xu-idr-fare-in-mpson-01.txt | ||||||||||||||
| Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks | ||||||||||||||
|
FARE-BGP enables weighted ECMP load balancing using a path-bandwidth extended community. FARE-in-SUN extends this mechanism from switches to GPUs for scale-up networks, which are typically multi-plane. Large AI training clusters are increasingly adopting multi-plane scale-out network topologies. This document further extends FARE-BGP from switches to RoCE NICs (RNICs) for such multi-plane scale-out networks. The document also presents two techniques to address route scalability concerns caused by the injection of numerous host routes. | |||||||||||||
| draft-xu-intarea-challenge-icmpv4-03.txt | ||||||||||||||
| Enhancing ICMP Error Message Authentication Using Challenge-Confirm Mechanism | ||||||||||||||
|
The Internet Control Message Protocol (ICMP) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMP error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of- Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per- challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMP error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMP. | |||||||||||||
| draft-xu-intarea-challenge-icmpv6-03.txt | ||||||||||||||
| Enhancing ICMPv6 Error Message Authentication Using Challenge-Confirm Mechanism | ||||||||||||||
|
The Internet Control Message Protocol for IPv6 (ICMPv6) is essential for network diagnostics but is vulnerable to off-path spoofing attacks, especially when error messages relate to stateless transport protocols like UDP. An attacker can forge these messages to degrade performance or enable Man-in-the-Middle attacks. This document proposes a robust, stateless challenge-response mechanism to authenticate ICMPv6 error messages. Traditional stateful challenge mechanisms are vulnerable to state-exhaustion Denial-of-Service (DoS) attacks. To avoid this, the proposed solution is inspired by TCP SYN-Cookies, eliminating the need to store per-challenge state by using cryptographic computation. It limits state management to minimal flags on existing sockets or a bounded probabilistic data structure. This approach effectively authenticates ICMPv6 error messages while inherently resisting both off-path spoofing and state-exhaustion DoS attacks, thus improving the robustness of ICMPv6. | |||||||||||||
| draft-xu-intarea-vulnerabilities-forged-icmp-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-lsvr-midr-use-cases-00.txt | ||||||||||||||
| Use Cases and Requirements for Multi-Domain and Hybrid Overlay/Underlay BGP-SPF (LSVR) | ||||||||||||||
|
This document presents use cases and the routing requirements they imply for operating the BGP Link State (BGP-LS) Shortest Path First (SPF) routing developed in the Link-State Vector Routing (LSVR) Working Group, across multiple administrative domains and over hybrid overlay/underlay topologies. After motivating the work, it describes three scenarios of increasing complexity: a single overlay domain, the interconnection of multiple overlay domains, and hybrid overlay/ underlay networks. Each scenario gives the topology, its distinguishing challenges, and the requirements that follow. The scenarios arise in globally distributed edge- and cloud-Point-of- Presence (PoP) deployments that serve performance-sensitive applications such as cross-region real-time communication, collaborative productivity, cloud gaming, and large-scale SaaS. | |||||||||||||
| draft-xu-mcp-agent-did-framework-00.txt | ||||||||||||||
| DID-Based Service Discovery,Authentication,and Authorization Framework for MCP Agents | ||||||||||||||
|
This document proposes a DID-based framework for service discovery, authentication, and authorization of MCP (Model Context Protocol) Agents, based on the W3C Decentralized Identifier (DID) standard. The framework uses the did:web and did:key methods to provide verifiable, decentralized identifiers for MCP Clients and Servers. It defines DID method selection, DID Document extensions, service discovery mechanisms (including URL derivation, DNS-based discovery, and directory-based capability queries), and a challenge-response mutual authentication protocol. The framework also describes coexistence with OAuth 2.0 and enables trust establishment, dynamic capability-based service discovery, and fine-grained authorization with portable identities. | |||||||||||||
| draft-xu-nmrg-idp-framework-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-oan-resource-identity-discovery-01.txt | ||||||||||||||
| Trust-Governed Resource Identity and Discovery Architecture for OpenAgenet | ||||||||||||||
|
Open agent ecosystems increasingly include heterogeneous resource products: callable agents, skills, Model Context Protocol (MCP) servers, ordinary tools, and application programming interfaces. A user or orchestrator often needs to discover such resources before it can decide which interaction protocol, credential, endpoint, or artifact to use. Discovery alone is not sufficient: the relying party also needs to know which resource identity was registered, which authority accepted it, whether the accepted package is current, and whether the Discovery service is authorized to expose it. This document describes a trust-governed resource identity and discovery architecture for OpenAgenet (OAN). The architecture separates resource subjects, resource providers, Registrar Nodes, a Root Node, Discovery Nodes, content distribution, and resource consumers. It defines architectural roles, trust boundaries, resource identity expectations, Root-verified package semantics, registration and verification behavior, authorization-aware Discovery, and pre-use verification requirements. The architecture can be profiled with Decentralized Identifier (DID) document concepts and credential-based assertions. This document does not define a new DID method, media type, URI scheme, transport protocol, ranking algorithm, blockchain protocol, agent invocation protocol, or product-native schema. | |||||||||||||
| draft-xu-rtgwg-fare-in-mp-son-00.txt | ||||||||||||||
| Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks | ||||||||||||||
|
FARE-BGP enables weighted ECMP load balancing using a path-bandwidth extended community. FARE-in-SUN extends this mechanism from switches to GPUs for scale-up networks, which are typically multi-plane. Large AI training clusters increasingly adopt multi-plane scale-out network topologies. This document further extends FARE-BGP from switches to RoCE NICs (RNICs) for such multi-plane scale-out networks. The document also presents two techniques to address route scalability concerns caused by the injection of numerous host routes. | |||||||||||||
| draft-xu-savax-control-11.txt | ||||||||||||||
| Control Plane 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. | |||||||||||||
| draft-xu-savax-data-10.txt | ||||||||||||||
| Data Plane 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 data plane of the SAVA-X mechanism. | |||||||||||||
| draft-xu-savax-protocol-10.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-sidrops-asrank-vulnerabilities-01.txt | ||||||||||||||
| Structural Vulnerabilities in ASRank under Adversarial Conditions | ||||||||||||||
|
This document analyzes the structural vulnerabilities of ASRank, a widely used algorithm for inferring Autonomous System (AS) business relationships from BGP routing data. ASRank plays a key role in security research and BGP operation, yet its inference process is highly sensitive to small changes in input data. This sensitivity introduces risks in adversarial conditions, where inference results may be manipulated without detection. This document outlines the design of ASRank, identifies its structural vulnerabilities, analyzes a minimal manipulation example, and discusses the security implications and potential countermeasures. | |||||||||||||
| draft-xu-sidrops-rpa-verification-02.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xu-tsvwg-adaptive-queue-mgmt-00.txt | ||||||||||||||
| Adaptive Queue Management Under Congestion | ||||||||||||||
|
Active Queue Management (AQM) manages queue depth by controlling packet admission at the point of enqueue. This document specifies a complementary queue management behavior that operates on packets already admitted to a queue: when the queue depth exceeds a configurable threshold, the maximum time a packet may remain queued before being dropped is reduced. When congestion subsides, the duration reverts to its base value. This per-queue dropping behavior helps manage queue depth during congestion by releasing resources from queues where packets have been waiting longest, complementing AQM without modifying its signaling semantics. | |||||||||||||
| draft-xue-mls-decentralized-00.txt | ||||||||||||||
| Distributed and Decentralized Uses of MLS | ||||||||||||||
|
The Messaging Layer Security (MLS) protocol provides continuous key agreement and offers additional benefits in multi-device group use cases. MLS relies on a Delivery Service (DS) for message ordering. In highly centralized uses, where the DS is a single server, configuration is straightforward. However, MLS also lends itself to use cases that are decentralized (e.g., federated networks) and even distributed (e.g., mesh networks). This informational document lays out uses of MLS and its variants and extensions across various topologies and provides guidance on selection among alternatives under both functionality and security considerations. | |||||||||||||
| draft-xz-6man-rate-option-01.txt | ||||||||||||||
| IPv6 Rate Hop-by-Hop Option | ||||||||||||||
|
This document defines a new IPv6 Hop-by-Hop Option that enables Minimum Rate Limit Discovery along the forward path between a source host and a destination host. Each router along the path can update the option with the minimum of its local Maximum Rate (MRate) and the recorded value. The discovered rate can then be communicated back to the source via a return mechanism, enabling the source to adapt its transmission rate to match the bottleneck link capacity and queue buffer. | |||||||||||||
| draft-xz-rtgwg-load-balancing-indication-01.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-xz-rtgwg-ppfc-gateway-00.txt | ||||||||||||||
| Precise Priority-based Flow Control with Gateway | ||||||||||||||
|
This document proposes Precise Priority-based Flow Control (PPFC) mechanism implemented at the network gateway, it designed to efficiently manage congestion in scenarios where multiple flows converge toward a common destination. By enabling fast, per-flow congestion control at the network gateway, PPFC allows incoming traffic destined for a congested bottleneck to be paused or rate- limited before entering the network. This approach decouples the congestion feedback loop from the end-to-end data path, significantly reducing reaction time and improving the effectiveness of congestion management. | |||||||||||||
| draft-xz-rtgwg-ppfc-notification-00.txt | ||||||||||||||
| Precise Priority-based Flow Control Notification | ||||||||||||||
|
This document specifies the notification mechanism for Precise Priority-based Flow Control (PPFC), defining the message formats and network actions for communicating congestion information among network nodes. The PPFC notification enables rapid congestion signaling, allowing per-flow flow control for traffic from source. | |||||||||||||
| draft-xz-rtgwg-ppfc-rocv2-00.txt | ||||||||||||||
| Precise Priority-based Flow Control Notification with RoCEv2 | ||||||||||||||
|
This document defines a format for Precise Priority-based Flow Control (PPFC) notifications within RoCEv2 (RDMA over Converged Ethernet version 2) networks. The proposed format enables network devices experiencing congestion to generate explicit congestion signals that can be efficiently carried back to the source clients. This facilitates fast, fine-grained flow control, complementing traditional end-to-end congestion control and improving performance in high-throughput, low-latency environments. | |||||||||||||
| draft-xz-rtgwg-srv6-rate-notification-01.txt | ||||||||||||||
| SRv6-based Rate Notification | ||||||||||||||
|
This document specifies a rate notification mechanism for Segment Routing over IPv6 (SRv6) networks. It enables a transit or egress node to dynamically notify the ingress (headend) node about a recommended rate range (MinRate and MaxRate) when localized congestion is detected or when underutilized bandwidth is identified, allowing the headend to perform proactive traffic shaping and rate enforcement. This mechanism enhances transmission efficiency in SRv6 networks by enabling fine-grained, congestion-aware rate control. | |||||||||||||
| draft-yakung-oauth-agent-attestation-00.txt | ||||||||||||||
| Agent Credential Attestation Protocol (ACAP) | ||||||||||||||
|
This document defines the Agent Credential Attestation Protocol (ACAP), a cryptographic credentialing protocol for autonomous AI agent pipelines. An ACAP credential is a short-lived JSON Web Token (JWT) signed with RS256 that carries scope-limited permissions together with a SHA-256 hash of the original human instruction that initiated the task. Credentials may be delegated to child agents; each delegation narrows scope, cannot outlive its parent, increments a delegation depth counter, and extends a tamper-evident chain of token identifiers. Every lifecycle event is recorded in an append- only, hash-chained audit log. This document specifies the credential format, issuance rules, delegation rules, verification algorithm, revocation semantics, human-in-the-loop approval protocol, and audit log structure. | |||||||||||||
| draft-yalcinkaya-rats-asil-m-00.txt | ||||||||||||||
| An ASIL-M Profile for Multi-Root Evidence Synthesis in RATS | ||||||||||||||
|
This document defines an application profile for Remote ATtestation procedureS (RATS) deployments in which authorization decisions depend on evidence from multiple independent trust roots. The profile is intended for AI inference systems that require explicit cross-root appraisal before execution is authorized. The document specifies three related artifacts: * an Attestation Evidence Synthesis Protocol for combining multiple evidence sets into one deterministic appraisal outcome; * the Twin Attestation Policy Language (TAPL), a constrained policy language for deterministic multi-root appraisal; and * the Canonical Attestation Record (CAR), an audit-oriented envelope that binds evidence references, appraisal outputs, freshness information, and replay-verification metadata. CAR is not a replacement for Evidence or Attestation Results as used in the RATS architecture. Instead, it is a higher-layer profile for packaging multi-root appraisal state and application-specific bindings for replay and audit. | |||||||||||||
| draft-yan-iba-routing-security-requirements-01.txt | ||||||||||||||
| Security Requirements for Intent-based Agent Routing | ||||||||||||||
|
This document specifies security requirements for intent-based agent routing. It defines a security architecture, phase-specific attack surface analysis, and normative protections for the Registration, Resolution, and Dispatch phases of routing. It also describes a secure operational process and an annotated interaction flow for protecting routing decisions, intent privacy, and capability integrity. Intent-based routing enables autonomous agents to collaborate based on semantic intent rather than static addresses, but this model introduces new security risks beyond those addressed by traditional channel protection and endpoint authentication. Existing mechanisms such as Transport Layer Security (TLS) and Public Key Infrastructure (PKI) verify identity and protect transport, but do not constrain what an agent claims to be capable of, nor do they protect the semantic content of intent queries during routing. This document establishes requirements to mitigate these risks and provides a comprehensive security framework for intent-based agent networks. | |||||||||||||
| draft-yan-nmrg-a2a-device-agent-applicability-00.txt | ||||||||||||||
| Applicability of A2A Protocol for Network Management Agents | ||||||||||||||
|
The evolution of network management towards autonomic operation requires the deployment of AI agents at various hierarchical layers, including directly on network elements. This transformation shifts network devices from passively managed resources to autonomous entities capable of local decision-making and collaborative problem- solving. This document discusses the applicability of the Agent-to-Agent (A2A) Protocol to the network management plane, specifically for communication between Controller Agents (CAs) and Device Agents (DAs). This indicates that the inherent characteristics of Device Agents necessitate the adoption of the agent-to-agent communication paradigm. The document further explores generic workflows, deployment scenarios, and the relationship of A2A with existing network management protocols like NETCONF, RESTCONF, gNMI,and the Model Context Protocol (MCP). | |||||||||||||
| draft-yan-nmrg-cross-domain-agent-architecture-00.txt | ||||||||||||||
| Cross-Domain Network Agent Architecture for Autonomous Operations | ||||||||||||||
|
Autonomous network management using agents is maturing in single- domain deployments. However, end-to-end services spanning multiple domains expose a lack of systematic support for cross-domain coordination, roles, and interfaces in current architectures. This document defines a cross-domain network agent architecture that enables coordinated operation across autonomous domains through standardized agent roles, layered coordination mechanisms, and unified interface specifications. | |||||||||||||
| draft-yan-opsawg-ipfix-energy-consumption-02.txt | ||||||||||||||
| Export of Energy Consumption Information in IPFIX | ||||||||||||||
|
This document introduces new IPFIX IEs for exporting energy consumption information of physical entities in a network device. New Information Elements are defined to report instantaneous and average energy consumption information at device, line-card, and port granularity. | |||||||||||||
| draft-yan-sidrops-rpki-terminology-05.txt | ||||||||||||||
| RPKI Terminology | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) is defined in dozens of different RFCs. The terminology used by implementers and developers of RPKI protocols, and by operators of RPKI systems, can at times be inconsistent, leading to confusion. In an effort to improve consistency in this respect, this document provides a single location for definitions of commonly-used RPKI terms. | |||||||||||||
| draft-yan-spring-srv6-int-resource-control-00.txt | ||||||||||||||
| SRv6-INT: Protocol Extensions to Segment Routing over IPv6 for In-Band Network Telemetry in Support of Closed-Loop Resource Control | ||||||||||||||
|
This document defines SRv6-INT, a protocol extension that integrates In-band Network Telemetry (INT) with Segment Routing over IPv6 (SRv6) packet processing. The extension reuses the Segment List entry associated with each SRv6-INT endpoint to carry an equal-length telemetry record, thereby preventing telemetry collection along the path from further increasing the packet header length. A collector obtains the resulting telemetry and provides it to local and global controllers for closed-loop resource control. | |||||||||||||
| draft-yang-6man-wide-area-packet-spraying-00.txt | ||||||||||||||
| IPv6 Options for Wide-Area Packet Spraying (WPS): Group-Based Multipath Load Balancing | ||||||||||||||
|
This document specifies the Wide-area Packet Spraying (WPS) option, an IPv6 option that can be carried in the Destination Options header or, where required, the Hop-by-Hop Options header. The option conveys the scheduling metadata that is needed to distribute the packets of a single high-volume flow across multiple parallel wide- area paths at the granularity of packet groups, and to restore the original packet ordering at the egress boundary of a controlled domain. The mechanism provides order-preserving multipath load balancing and bandwidth aggregation for wide-area interconnection of distributed computing sites, such as wide-area interconnects between Artificial Intelligence (AI) data centers, and is intended for use within limited domains. | |||||||||||||
| draft-yang-bfd-sbfd-proxy-03.txt | ||||||||||||||
| S-BFD Proxy | ||||||||||||||
|
This document proposes an extension to Seamless Bidirectional Forwarding Detection (S-BFD). The S-BFD initiator will send packets that carry extra information, and this enables reflector to act as a proxy, and respond with the extra information in consideration. This document updates RFC 7880. | |||||||||||||
| draft-yang-dhc-dhcp-extension-00.txt | ||||||||||||||
| DHCP New Option Extension based on LLM Capability | ||||||||||||||
|
This document specifies a DHCP option extension designed for campus networks to help client devices distinguish and connect to a master device with the LLM (Large Language Model). The mechanism extends a new DHCP option containing two specific parameters within the DHCP payload: the master device's LLM address and the master device's LLM configuration. This allows client devices to identify and register to LLM-enabled master device during the bootstrap phase. | |||||||||||||
| draft-yang-dmsc-gateway-mediation-layer-00.txt | ||||||||||||||
| Gateway Mediation Layer for AI Agent Collaboration | ||||||||||||||
|
Cross-domain and policy-controlled agent collaboration can require mediation decisions that are not always suitable for an agent client or an agent server alone. A collaboration request may need to combine a stated goal, capability profiles, tenant or domain policy, trust evidence, disclosure limits, operational constraints, and handoff context before a concrete interaction mechanism is used. This document identifies gateway-side interaction mediation as a distinct interoperability gap in many AI Agent Gateway deployments. It does not claim that every agent collaboration requires a gateway. Rather, it explains why many deployments need a mediation point where request goals, capability profiles, policy, trust, and handoff constraints can be evaluated before interaction proceeds. The document describes a Gateway Mediation Layer as a decision- support and interface layer between application-level goals and concrete agent interaction mechanisms. It focuses on the role, inputs, outputs, and narrow set of interoperable artifacts that may require further work, such as Mediation Requests, Mediation Responses, Handoff Contexts, Failure Records, and Evidence References. It does not propose standardizing internal matching algorithms, domain ontologies, prompt engineering, or model-specific decision logic. | |||||||||||||
| draft-yang-dmsc-gateway-semantic-layer-02.txt | ||||||||||||||
| Gateway Mediation Layer for AI Agent Collaboration | ||||||||||||||
|
Cross-domain and policy-controlled agent collaboration can require mediation decisions that are not always suitable for an agent client or an agent server alone. A collaboration request may need to combine a stated goal, capability profiles, tenant or domain policy, trust evidence, disclosure limits, operational constraints, and handoff context before a concrete interaction mechanism is used. This document identifies gateway-side interaction mediation as a distinct interoperability gap in many AI Agent Gateway deployments. It does not claim that every agent collaboration requires a gateway. Rather, it explains why many deployments need a mediation point where request goals, capability profiles, policy, trust, and handoff constraints can be evaluated before interaction proceeds. The document describes a Gateway Mediation Layer as a decision- support and interface layer between application-level goals and concrete agent interaction mechanisms. It focuses on the role, inputs, outputs, and narrow set of interoperable artifacts that may require further work, such as Mediation Requests, Mediation Responses, Handoff Contexts, Failure Records, and Evidence References. It does not propose standardizing internal matching algorithms, domain ontologies, prompt engineering, or model-specific decision logic. | |||||||||||||
| draft-yang-dmsc-ioa-task-protocol-03.txt | ||||||||||||||
| Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous Agent Collaboration | ||||||||||||||
|
This draft defines a new agent collaboration protocol, named the Internet of Agents Task Protocol (IoA Task Protocol), to support distributed, heterogeneous agent collaboration in intelligent systems. The IoA Task Protocol enables dynamic team formation, adaptive task coordination, and structured communication among agents with diverse architectures, tools, and knowledge sources. Through a layered architecture and extensible message format, it supports decentralized deployment across devices and can interoperate with existing frameworks. The protocol is particularly suited to large- scale intelligent collaboration scenarios—such as intelligent transportation, smart healthcare, and large-scale human–AI teaming—across heterogeneous network environments, including fixed networks, edge–cloud infrastructures, and emerging mobile networks such as 6G. | |||||||||||||
| draft-yang-ippm-twamp-srv6-slice-00.txt | ||||||||||||||
| Carrying a Network Slice Indicator in TWAMP and STAMP Probe Packets for SRv6 Networks | ||||||||||||||
|
Network Slices realized over Segment Routing over IPv6 (SRv6) networks use slice-specific forwarding resources that are selected by a slice indicator carried in the IPv6 packet. For two-way active measurement results to reflect the conditions experienced by traffic within a given network slice, the probe packets generated by the Two- Way Active Measurement Protocol (TWAMP) and the Simple Two-Way Active Measurement Protocol (STAMP) need to be forwarded over the same slice-specific resources as the data traffic they are intended to characterize. This document specifies how a slice indicator is carried in TWAMP and STAMP probe packets so that those packets are forwarded through the resources of a target slice, and it defines the corresponding Session-Sender and Session-Reflector behavior. The procedures are independent of the specific encoding used to carry the slice indicator in the SRv6 data plane. | |||||||||||||
| draft-yang-ipsecme-esp-entropy-header-00.txt | ||||||||||||||
| An Entropy Header for Load Balancing of IPsec ESP Traffic | ||||||||||||||
|
When IPsec Encapsulating Security Payload (ESP) is used in tunnel mode, an intermediate node cannot inspect the encrypted inner headers to derive entropy for Equal-Cost Multipath (ECMP) or Link Aggregation Group (LAG) path selection. Path selection is then driven by outer header fields that are identical for every packet of a given tunnel, so all packets of the tunnel are placed on a single path regardless of the number of inner flows. This document defines the ESP Entropy Header, an IP protocol header that is placed immediately ahead of ESP and carries an entropy value in a fixed position that transit nodes can use for path selection. It also defines an Internet Key Exchange Protocol Version 2 (IKEv2) extension with which peers negotiate the use of the header on a per- Child-SA basis. The mechanism applies to both IPv4 and IPv6. | |||||||||||||
| draft-yang-nmrg-a2a-nm-03.txt | ||||||||||||||
| Applicability of A2A to the Network Management | ||||||||||||||
|
This document discusses the applicability of A2A protocol to the network management in the multi-domain heterogeneous network environment that utilizes IETF technologies. It explores operational aspect, key components, generic workflow and deployment scenarios. The impact of integrating A2A into the network management system is also discussed. | |||||||||||||
| draft-yang-nmrg-mcp-nm-03.txt | ||||||||||||||
| Applicability of MCP for the Network Management | ||||||||||||||
|
The application of MCP in the network management field is meant to refactor network management operation and network capabilities as tools and provide more agile and extensible architecture to expose these AI integration capabilities. This document discusses the applicability of MCP to the network management plane in the IP network that utilizes IETF technologies. It explores MCP for network exposure, multiple MCP server discovery, communication between Network Elements or between the Network element and the Network Controller/Network Gateway. | |||||||||||||
| draft-yang-pce-pcep-over-quic-05.txt | ||||||||||||||
| PCEP over QUIC | ||||||||||||||
|
This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. | |||||||||||||
| draft-yang-rtgwg-arn-framework-08.txt | ||||||||||||||
| Application-Responsive Network Framework | ||||||||||||||
|
With the deployment of increasingly advanced technologies on a large scale, such as SRv6[RFC8402] and network slicing, there is a growing need to expose these new capabilities to applications. The current practice involves using ACLs to classify packets and then map the traffic onto appropriate network resources. This approach results in the application being passively perceived by the network, rather than the application actively interfacing with the network. Furthermore, changes in application characteristics necessitate triggering network configuration adjustments, making it challenging to deploy at scale. The document proposes a new framework called Application Responsive Network (ARN), by encapsulating more network functions into ARN ID, thus it opens up interfaces to applications. The vision is to enable applications to access network resources like they access an operating system. | |||||||||||||
| draft-yang-rtgwg-grc-based-routing-01.txt | ||||||||||||||
| Geographic Based Dynamic Routing in LEO Satellite Networks | ||||||||||||||
|
This document proposes a dynamic routing mechanism for Low Earth Orbit(LEO) satellite networks based on geographic region coding. By decoupling IP addressing from physical location, the mechanism uses hierarchical geographic grid codes (inspired by Uber's H3 spatial index) as temporary IP addresses for satellites. Routing decisions are made based on the relative geographic position encoded in the destination address, rather than traditional prefix-based IP routing. Satellite ephemeris data is leveraged to pre-compute routing tables for discrete time slices, eliminating the need for real-time link- state flooding and enabling stable, predictable routing in highly dynamic satellite topologies. | |||||||||||||
| draft-yang-spring-srv6-verification-05.txt | ||||||||||||||
| SRv6 Path Verification | ||||||||||||||
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. However, we have also observed that SRv6 is beginning to extend toward customer site devices, e.g., SD-WAN and enterprise network deployments. Both of the scenarios can be deployed in third-party clouds or at customer sites. This introduces certain security risks, such as packet injection and path manipulation attacks. Section 6 of [I-D.draft-ietf-spring-srv6-security] identifies these risks as well, including Section 6.2.1 on Modification Attacks and Section 6.2.3 on Packet Insertion. This proposal mitigates these risks by enhancing the HMAC mechanism defined in [RFC8754]. | |||||||||||||
| draft-yao-dawn-agent-discovery-architect-01.txt | ||||||||||||||
| DNS-like Agent Discovery Architecture | ||||||||||||||
|
This document defines a DNS-like three-tier agent-discovery architecture for the Internet of Agents (IoA). It introduces three core functional roles: Agent Root, Agent Registry, and Agent Resolver. | |||||||||||||
| draft-yarmohammadi-maram-00.txt | ||||||||||||||
| MARAM: Multi-layer Address Randomization and Authentication Mechanism | ||||||||||||||
|
This document specifies MARAM (Multi-layer Address Randomization and Authentication Mechanism), an IPv6 extension that encrypts real endpoint addresses inside a Destination Option and uses ephemeral outer addresses with per-packet authentication. The key exchange is FYES (Fayazbakhsh, Yarmohammadi, Entezami, Shams), and a dedicated Vahed's Seal ensures protocol identification. The key derivation (FYES-KDF) uses domain separation strings for deriving independent keys. | |||||||||||||
| draft-ybam-ccamp-rfc8561bis-02.txt | ||||||||||||||
| A YANG Data Model for Microwave Radio Link | ||||||||||||||
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. This document obsoletes RFC 8561. | |||||||||||||
| draft-ybb-ccamp-service-path-computation-04.txt | ||||||||||||||
| A YANG Data Model for Service Path Computation | ||||||||||||||
|
This document defines a YANG data model for client signal service's path computation and path management. | |||||||||||||
| draft-ydb-rats-cca-endorsements-04.txt | ||||||||||||||
| A CoRIM Profile for Arm's Confidential Computing Architecture (CCA) Endorsements | ||||||||||||||
|
Arm Confidential Computing Architecture (CCA) Endorsements comprise reference values and cryptographic key material that a Verifier needs to appraise Attestation Evidence produced by an Arm CCA system. This memo defines CCA Endorsements as a profile of the CoRIM data model. 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/yogeshbdeshpande/draft-cca-rats-endorsements. | |||||||||||||
| draft-ye-ippm-switching-efficiency-02.txt | ||||||||||||||
| Switching Efficiency: A Metric Framework for AI Data Center Networks | ||||||||||||||
|
This document specifies the Switching Efficiency Framework, a measurement methodology designed to evaluate network efficiency in AI Data Centers (AIDCs). Conventional network metrics, such as bandwidth utilization or network throughput, fail to directly link network activity to computational progress, as they cannot distinguish computationally effective data that directly advances neural network computing from the redundant traffic induced by both multi-hop forwarding and the algorithmic overhead of collective operations. To address this, this document defines the Switching Efficiency Framework, a measurement methodology for evaluating AIDC network efficiency. The core metric, Switching Efficiency, quantifies the computationally effective data throughput delivered per unit of provisioned switching capacity. To facilitate precise diagnostic analysis, the framework further decomposes this core metric into three fine-grained factors: Data Efficiency, Routing Efficiency, and Port Utilization. This framework provides metrics that can help operators identify communication bottlenecks and evaluate topology-traffic alignment. | |||||||||||||
| draft-ye-problems-and-requirements-of-dns-for-ioa-03.txt | ||||||||||||||
| Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA) | ||||||||||||||
|
In the AI-driven era, DNS is supposed to evolve with technological advancements to accommodate the complex and diverse requirements of the IoA. This draft analyzes the issues surrounding DNS in supporting agents collaboration and explores corresponding technical requirements. | |||||||||||||
| draft-ye-srv6ops-sfc-deployment-01.txt | ||||||||||||||
| SRv6 SFC Deployment Options | ||||||||||||||
|
This document mainly introduces the factors to consider for supporting SRv6 SFC from the aspects of deployment and reliability methods. | |||||||||||||
| draft-yi-idr-bgp-fs-edge-service-metadata-06.txt | ||||||||||||||
| Distribution of Service Metadata in BGP FlowSpec | ||||||||||||||
|
In edge computing and distributed cloud environments, a service may be deployed on multiple instances across one or more sites, referred to as an edge service. The edge service is typically associated with an ANYCAST IP address. With the emergence of Computing-Aware Traffic Steering (CATS) requirements, there is a growing need to consider both network and computing metrics when making traffic steering decisions. Traditional routing protocols lack the capability to convey compute-related information, necessitating extensions to existing protocols. This draft defines a mechanism to distribute service routes along with computing-related metadata using BGP FlowSpec. The service metadata, including compute resource status and performance metrics, can be collected by a central controller, processed, and then distributed to ingress routers using BGP FlowSpec extensions. This enables ingress routers to make path selections based not only on routing cost but also on the running environment and resource availability of edge services, thereby optimizing Quality of Experience (QoE). The mechanism is aligned with the CATS architecture and metric framework by allowing the advertised metadata to represent either selected original service metrics or an aggregated Level 2 (L2) metric. | |||||||||||||
| draft-yl-bmwg-cats-05.txt | ||||||||||||||
| Benchmarking Methodology for Computing-aware Traffic Steering | ||||||||||||||
|
Computing-aware traffic steering (CATS) is a traffic engineering approach for steering service requests towards appropriate service instances based on the awareness of both computing and network information. This document proposes benchmarking methodologies for CATS. | |||||||||||||
| draft-yl-cats-data-model-09.txt | ||||||||||||||
| Data Model for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document defines a YANG data model for the management of Computing-Aware Traffic Steering (CATS) systems. | |||||||||||||
| draft-yl-radext-quic-transport-04.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yl-savnet-icmp-extension-01.txt | ||||||||||||||
| ICMP Extension for SAVNET Validation | ||||||||||||||
|
This document defines new ICMP and ICMPv6 error codes to send error messages to the source device when forwarding Ping or Traceroute packets is dropped due to SAVNET validation failure. The error message explicitly states the reason for dropping as "SAVNET Validation Failed," thereby enhancing network observability and troubleshooting capabilities. | |||||||||||||
| draft-ymbk-lsvr-l3nd-01.txt | ||||||||||||||
| Layer-3 Neighbor Discovery | ||||||||||||||
|
Data Centers where the topology is BGP-based need to discover neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3 Neighbor Discovery protocol identifies BGP neighbor candidates. | |||||||||||||
| draft-ymbk-lsvr-l3nd-ulpc-01.txt | ||||||||||||||
| L3ND Upper-Layer Protocol Configuration | ||||||||||||||
|
This document adds PDUs to the Layer-3 Neighbor Discovery protocol to communicate the parameters needed to exchange inter-device Upper Layer Protocol Configuration for upper-layer protocols such as the BGP family. | |||||||||||||
| draft-yoon-ccamp-pm-streaming-07.txt | ||||||||||||||
| A YANG Data Model for Performance Monitoring Streaming on Common Transport Equipment | ||||||||||||||
|
This document describes how the generic collection measurement YANG data model and its interval-capability companion model are applied to common transport equipment. It is informational. It defines a small YANG module of transport performance parameters, organizes those parameters into maintenance and QoS profiles, and gives end-to-end examples that show capability discovery followed by YANG-Push subscription, notification, and threshold reporting for a transport profile. | |||||||||||||
| draft-yoon-ippm-collection-interval-capabilities-00.txt | ||||||||||||||
| A YANG Data Model for Collection Interval Capabilities | ||||||||||||||
|
This document defines a YANG data model, "ietf-pm-interval- capabilities", that enables a server to advertise which collection intervals it can support. A client reads this capability information before configuring performance measurements, so that it selects only sampling and collection intervals that the server can honour. The capabilities are advertised by augmenting the "ietf-system- capabilities" module defined in [RFC9196], so that a client discovers them at the same well-known location used for subscription and notification capabilities. The model imports the "profile-names" type from the companion collection measurement model defined in [I-D.yoon-ippm-collection-measure] and mirrors its profile-and- parameter structure, ensuring direct alignment between capability discovery and measurement configuration. The model does not define measurement data structures or any delivery mechanism; those are defined in the companion document. | |||||||||||||
| draft-yoon-ippm-collection-measure-00.txt | ||||||||||||||
| A YANG Data Model for Collection Measurement | ||||||||||||||
|
This document specifies a YANG data model for Collection Measurement based on the Performance Management (PM) Collection function requirements defined in ITU-T G.7710. The model processes raw performance data sampled at a network node and produces structured data that can be retrieved by clients via pull-based mechanisms or delivered via push-based mechanisms such as YANG-Push. This document does not define new performance metrics; the base metrics are those of the IPPM framework, and the model specifies the collection and exposure of the operationally important subset identified by ITU-T G.7710. | |||||||||||||
| draft-yoshikawa-sidrops-pqc-rpki-02.txt | ||||||||||||||
| Post-Quantum Signature Experiments and Migration Considerations for the Resource Public Key Infrastructure (RPKI) | ||||||||||||||
|
This document reports experiments with post-quantum signature algorithms and analyzes migration approaches for the Resource Public Key Infrastructure (RPKI). The experiments compare classical, post- quantum, and composite signature candidates; generate and validate RPKI-profiled certificate, CRL, manifest, and ROA test objects; evaluate Parallel Publication and Mixed Tree migration as distinct migration structures; and evaluate the effect of larger objects on rsync, RRDP, and Erik Synchronization. The results identify implementation, interoperability, repository-distribution, and operational questions that need to be resolved before a production algorithm profile or transition procedure can be specified. This document is informational. It does not update RFC 7935 or RFC 6916, define a new RPKI algorithm profile, or authorize the use of the evaluated algorithms or Mixed Tree migration in the production RPKI. | |||||||||||||
| draft-yoshino-wish-04.txt | ||||||||||||||
| web-stream: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols | ||||||||||||||
|
This document defines web-stream, a general-purpose message framing designed to support message-based communication over any byte-stream oriented L4 or L7 protocols, in particular HTTP as in its standard semantics [RFC9110]. web-stream can be viewed as a binary alternative to the framing defined for the server-sent events (SSE) [SSE]. This was the original goal when the initial version of this proposal was published in 2017. | |||||||||||||
| draft-yossif-agent-mandate-problem-00.txt | ||||||||||||||
| Problem Statement: Verifiable Human Mandates for Autonomous Agent Actions | ||||||||||||||
|
An autonomous software agent commonly acts under authority a human granted at an earlier moment: the human expresses and authorizes an intent at one time, and the agent executes one or more concrete actions at a later time. The credentials and session state the agent carries at execution time establish that some agent is authorized to act, but they do not establish that this specific action, with these specific parameters, falls within the constraints the human actually signed. As agent autonomy and action throughput grow, the population of executed actions that no human individually bounded grows with it. This document is a problem statement. It characterizes the gap between an authorized agent and an authorized action, explains why existing delegation, logging, and payment-mandate mechanisms do not close it, and states the requirements any solution would have to satisfy. It defines no protocol or mechanism. | |||||||||||||
| draft-yossif-enrollment-problem-00.txt | ||||||||||||||
| Problem Statement: Enrollment and Key-Binding Assumptions in Execution Authority Evidence | ||||||||||||||
|
Any scheme that produces cryptographic evidence of execution authority roots its entire trust chain in an enrollment: the moment at which a key becomes bound to a subject and a device, and at which a verifier begins to treat signatures under that key as meaningful. Every downstream proof is only as trustworthy as that binding. If an attacker substitutes a key of their choosing at enrollment, every subsequent proof verifies correctly and yet attests to the wrong party. This document is a problem statement. It describes the foundational key-substitution threat, records the relevant public facts about consumer-platform biometric and key APIs that bound what an enrollment can establish, and states the assumptions a verifier of execution authority evidence must be able to make about the enrollment its proofs depend on. Specific enrollment ceremonies are out of scope. This document defines no protocol or mechanism. | |||||||||||||
| draft-yossif-psea-02.txt | ||||||||||||||
| PSEA Token Profile: An EAT Profile for Action-Bound,User-Verification-Gated Transaction-Confirmation Evidence | ||||||||||||||
|
This document defines the PSEA Token Profile, an Entity Attestation Token (EAT) profile for action-bound, user-verification-gated transaction-confirmation Evidence. The profile specifies the canonical encoding, the signed proof-token claim set, the action- payload and cross-replay bindings, an optional hash-chain integrity layer, and the security properties that together constitute a What- You-Sign-Is-What-You-Execute proof that a human, present and verified at an authenticator, approved a specific named action at the moment of execution. The profile binds what is signed to what the Verifier executes; it does not, by itself, bind what a human saw on a potentially compromised display to what was signed (the What-You-See- Is-What-You-Sign problem), which remains out of scope. The strength of the human-presence assurance depends on the authenticator's user- verification enforcement: where the platform attestation conveys that enforcement it is hardware-attested, and otherwise it rests on the authenticator's signed assertion that user verification occurred. The profile does not, by itself, prove a specific human identity. It fills the transaction-confirmation gap left unaddressed by deployed authentication standards and complements OAuth 2.0 Step-Up Authentication by supplying the per-action, cryptographically action- bound Evidence that step-up flows can require. | |||||||||||||
| draft-young-md-query-25.txt | ||||||||||||||
| Metadata Query Protocol | ||||||||||||||
|
This document defines a simple protocol for retrieving metadata about named entities, or named collections of entities. The goal of the protocol is to profile various aspects of HTTP to allow requesters to rely on certain, rigorously defined, behaviour. This document is a product of the Research and Education Federations (REFEDS) Working Group process. | |||||||||||||
| draft-young-md-query-saml-25.txt | ||||||||||||||
| SAML Profile for the Metadata Query Protocol | ||||||||||||||
|
This document profiles the Metadata Query Protocol for use with SAML metadata. This document is a product of the Research and Education Federations (REFEDS) Working Group process. Editorial Note (To be removed by RFC Editor before publication) Discussion of this draft takes place on the MDX project issue tracker, which is accessed from [MDX.issues]. XML versions, latest edits and the issues list for this document are available from [md-query]. The changes in this draft are summarized in Appendix A.26. | |||||||||||||
| draft-yu-agent-identifier-rdap-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yu-agent-registry-sync-00.txt | ||||||||||||||
| Analysis of Data Synchronization Problems in Multi-Agent Registry Centers | ||||||||||||||
|
This document analyzes the data synchronization problems between multiple distributed Agent registry centers in IPv6 networks. When Agent networks span multiple organizational domains, geographic regions, or autonomous systems, each region's Agent registry center needs to synchronize Agent connection information and capability descriptions with others. This document presents a network-layer perspective on the main problems, challenges, and design considerations, providing a foundation for the development of subsequent solutions. | |||||||||||||
| draft-yu-ai-agent-ipv6-networking-considerations-01.txt | ||||||||||||||
| IPv6 Networking Considerations for AI Agent Communication | ||||||||||||||
|
AI agents are increasingly expected to communicate across platforms, organizations, clouds, edge environments, and administrative domains. Current agent-related mechanisms mainly focus on description, discovery, identity, authentication, authorization, tool invocation, and application-layer collaboration. These mechanisms are important, but they often treat the IP network as a transparent connectivity substrate. This document describes networking problems that arise when AI agents perform cross-domain communication and continuous tool, API, data, and agent-to-agent calls. It focuses on problem description rather than a protocol solution. In particular, it discusses gaps related to agent identity visibility at the network layer, path control, audit continuity, the separation of discovery from addressing and authorization, and privacy and privilege risks introduced by highly autonomous agents. The document positions Agent6 as a problem space for network support of cross-domain AI agent collaboration. It does not define a new agent discovery protocol, a new application-layer collaboration protocol, a new authentication or authorization mechanism, or a new IPv6 extension header. | |||||||||||||
| draft-yu-ccamp-resource-pm-yang-06.txt | ||||||||||||||
| A YANG Data Model for Resource Performance Monitoring | ||||||||||||||
|
This document defines a YANG data model for resource Performance Monitoring, applicable to network controllers, which provides the functionalities of retrieval of performance monitoring capabilities, TCA (Threshold Crossing Alert) configuration, current or history performance data retrieval, and performance monitoring task management. | |||||||||||||
| draft-yu-ccamp-sla-assurance-optical-yang-01.txt | ||||||||||||||
| A YANG Data Model for Service Level Agreement (SLA) Assurance Management in Optical Transport Networks | ||||||||||||||
|
This document defines a YANG module for SLA assurance management in optical transport networks. The module provides a standard way to define, detect, and report issues that may impact service and network availability. It enables consistent modeling of assurance intent, impairment detection, and risk reporting across optical transport domains. The YANG model is designed to support closed-loop operations, allowing automated monitoring, analysis, and remediation workflows to maintain high service reliability and SLA compliance | |||||||||||||
| draft-yu-dmsc-ai-agent-use-cases-in-6g-02.txt | ||||||||||||||
| AI Agent Use Cases and Requirements in 6G Network | ||||||||||||||
|
This draft introduces use cases related to AI Agents in 6G networks, primarily referencing the technical report of 3GPP SA1 R20 Study on 6G Use Cases and Service Requirements (TR 22.870). It also elaborates on some of the requirements for introducing AI Agents into 6G networks from the perspective of operators. | |||||||||||||
| draft-yu-dtn-access-gateway-ip-edge-networks-00.txt | ||||||||||||||
| DTN Access Gateway for IP Edge Networks | ||||||||||||||
|
Delay- and disruption-tolerant networking (DTN) is used in environments with long propagation delay, constrained links, intermittent connectivity, and scheduled contacts. At the edge of such systems, local IP networks may exist, such as lunar surface networks, spacecraft internal networks, and edge computing networks. End systems in these IP edge networks may continue to use conventional IP stacks and may not process DTN-specific semantics such as endpoint identifiers, Bundle lifetimes, contact schedules, or DTN storage constraints. This document describes a DTN access gateway for IP edge networks. The gateway is placed at the boundary between an IP edge network and a DTN domain. It organizes authorized IP-side data into Bundle payloads, submits those payloads to the DTN side under controlled admission, and reflects DTN-side admission constraints back to IP edge senders through bounded pre-admission state and passive back- pressure. The main focus is edge-to-edge transit mode, in which a pair of gateways connects two IP edge networks across a DTN domain. This document also discusses an optional edge-to-DTN service access extension, in which selected IP-side requests are mapped, under local rules, to service transactions in the DTN domain. This document does not define a new BP extension block, convergence- layer protocol, Bundle payload encoding, routing protocol, contact- plan exchange protocol, or mandatory gateway implementation. | |||||||||||||
| draft-yu-idr-bgp-sr-policy-orf-00.txt | ||||||||||||||
| On-Demand Distributing BGP SR Policy Using Outbound Route Filtering Capability | ||||||||||||||
|
The BGP SR Policy address family defines a mechanism to distribute Segment Routing (SR) policies from a centralized controller to head- end routers. However, pre-provisioning all candidate SR Policies across massive-scale networks impose significant control-plane memory and processing overhead on edge nodes. This document specifies an extension to the BGP Outbound Route Filtering (ORF) capability, leveraging the framework defined in RFC 5291. It introduces a new SR Policy Tuple ORF type that allows a head-end router to precisely request or subscribe to specific SR Policies based on a Color and Endpoint tuple, enabling pure on-demand, pull-based policy distribution. | |||||||||||||
| draft-yu-imap-client-id-16.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-yu-network-trust-framework-for-ai-agents-00.txt | ||||||||||||||
| Network Trust Framework for AI Agents | ||||||||||||||
|
AI agents are expected to communicate across platforms, organizations, clouds, edge environments, and administrative domains. Existing agent mechanisms mainly focus on application-layer discovery, capability description, identity, authorization, tool invocation, and agent-to-agent collaboration. These mechanisms are important, but they often treat the IP network as a transparent connectivity substrate. This document describes a framework for using network-layer and network-control capabilities to enhance trust for AI agent communication after agent discovery. The framework introduces an Agent Interconnection Hub, trusted transport tags, policy-driven path selection, and audit indexing as building blocks for recognizable identity, accountable paths, enforceable policy, and traceable invocation records. This document does not define a new agent discovery protocol, a new application-layer agent collaboration protocol, a new authentication or authorization mechanism, a new IPv6 extension header, or a new SRv6 behavior. It provides architectural considerations and requirements for future work. | |||||||||||||
| draft-yuan-idr-bgp-color-threats-00.txt | ||||||||||||||
| Threat Model for BGP Color Extended Community | ||||||||||||||
|
The BGP Color Extended Community carries a user-defined Color value that is configured locally and has no globally standardized semantics. Although this design is suitable for local policy expression, it raises security concerns when Color values are propagated across Autonomous System (AS) boundaries and used to influence forwarding behavior in another domain. This document describes a threat model for that context, following the structure used by RFC 7132. It defines relevant terminology, characterizes the classes of adversaries considered to be threats, examines the classes of attacks that those threats are able to effect against Color-based forwarding, and concludes with a discussion of residual vulnerabilities. It does not revisit attacks against unprotected BGP, and it defines no new protocol mechanism. | |||||||||||||
| draft-yuan-quic-congestion-data-01.txt | ||||||||||||||
| Exchanging Congestion Control Data in QUIC | ||||||||||||||
|
This draft defines a new transport frame which enables consenting endpoints to share congestion control state about the network connection for various purposes. It also allows an endpoint's own congestion control state to be echoed back to it by a peer for consideration at the beginning of a future connection. | |||||||||||||
| draft-yusef-tls-pqt-dual-certs-03.txt | ||||||||||||||
| Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3 | ||||||||||||||
|
The anticipated emergence of cryptographically relevant quantum computers (CRQCs) poses a threat to the authentication mechanisms used in TLS 1.3. This document defines a hybrid authentication mechanism that uses two independent certificates, one traditional and one post-quantum, ensuring that an attacker must break both algorithms to compromise a TLS connection. The two certificate chains are carried in a single Certificate message and two independent signatures are encoded in the CertificateVerify message. | |||||||||||||
| draft-yuyou-moq-conditional-filtering-01.txt | ||||||||||||||
| Conditional Range Filters for Media over QUIC Transport | ||||||||||||||
|
In Media over QUIC Transport (MOQT), subscribers can use Range Filters to select specific subgroups, objects, or priorities within a subscribed track. However, these subscription filters are static once established and can only be modified through explicit subscriber control signaling. This document proposes an extension to the Range Filter design that binds conditional evaluation logic directly to specific Range Filter sets. By introducing dynamic conditions to Range Filter configurations, a relay can autonomously adapt the intra-track forwarding behavior based on real-time network conditions, avoiding the round-trip delay of explicit subscriber update signaling. | |||||||||||||
| draft-yxl-cats-protocols-applicability-01.txt | ||||||||||||||
| Protocols Applicability for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
This document analyzes the applicability of protocols related to a CATS system, and describes how to build a CATS system by extending existing IETF protocols. | |||||||||||||
| draft-zaeschke-scion-quic-multipath-01.txt | ||||||||||||||
| Guidelines for QUIC Multipath over SCION | ||||||||||||||
|
This document provides informational guidance for using the Multipath Extension for QUIC with the SCION networking technology. SCION is an inter-domain routing protocol that supports path-aware multi-path networking. The multiple paths and their associated path information offered by SCION provide opportunities as well as challenges for combining QUIC-MP with SCION. This document explores various aspects of this combination, such as algorithms for congestion control, RTT estimation, and general application scenarios. In addition, it provides techniques and guidance to maintain the security of QUIC-MP and SCION, and to leverage path-aware multi-path networking with QUIC-MP. | |||||||||||||
| draft-zagarella-autonomy-governor-01.txt | ||||||||||||||
| Pre-Action Risk-Graded Assurance for Agent Interactions | ||||||||||||||
|
Governance of autonomous agents today is largely expressed as boundary enforcement: an action is permitted or blocked at the point it is attempted, per a policy evaluated at that boundary. As agents span heterogeneous action types — authenticating a human, executing a delegated task, selecting a computational resource — a single, uniform way to express "how much assurance this action requires, before it proceeds" is missing. This document describes an interface for pre-action, risk-graded assurance: a policy stage that, before an agent action proceeds, derives an assurance requirement from a risk signal and expresses that requirement in a domain-appropriate form, recording the decision in an audit record and optionally binding it to a verified human root. It defines the interface and the audit-record fields, not any particular risk-scoring method or control law. This document also describes the autonomy-asymmetry control law: a feedback loop coupling assurance requirements to VERIFY-phase pass rates, with fast-down (immediate elevation on failure) and slow-up (hysteresis- governed relaxation on sustained success) asymmetry. The iteration governor is described as the per-packet instance of this control law, and the phase-seal chain as its sensor. This document is offered as input to the proposed AUDIT working group's work on authorization state over time and action provenance. | |||||||||||||
| draft-zagarella-verified-human-root-01.txt | ||||||||||||||
| Verified Human Root Attestation for Agent Delegation Chains and Audit Records | ||||||||||||||
|
Autonomous software agents increasingly act under delegated authority, and emerging audit-record data models capture what an agent did, under which delegation, with which authorization state. In current practice the head of every such chain, and the identity axis of every such record, is a key, an account, or a workload identity. No standardized element establishes that an identified natural person, verified as live and present, stands at the head of the chain or behind the recorded action. This document defines the Verified Human Root Attestation (VHRA): a compact, privacy-preserving data structure asserting that a biometric proof-of-human verification of an identified natural person (or an M-of-N quorum of such persons) occurred at a specific issuance event. It further defines how a delegation chain binds a VHRA at its root such that the binding survives attenuation, and how audit and interaction records reference a VHRA so that any recorded agent action can be resolved to an accountable natural person without the verifier receiving any biometric material. This document is offered as input to the proposed AUDIT working group's data model work. It deliberately does not standardize biometric verification methods; it standardizes only the attestation structure, its bindings, and verifier obligations. | |||||||||||||
| draft-zahed-acap-00.txt | ||||||||||||||
| Agent Capability Advertisement Protocol (ACAP) | ||||||||||||||
|
This document specifies the Agent Capability Advertisement Protocol (ACAP), a REST-like protocol built on HTTP/3 that defines a structured registry and exchange format for Agent Capability Documents (ACDs). ACAP enables the discovery of AI agents deployed across different administrative domains on the Internet. Each agent exposes an ACAP endpoint, hosted at a well-known URI, that serves ACDs describing the capabilities, authentication requirements, and operational metadata for agents within that domain. ACAP supports three core operations: retrieval, registration, and capability-based search. In deployments where multiple agent operators share hosting infrastructure, ACDs are cryptographically signed to enable secure, decentralized agent discovery. | |||||||||||||
| draft-zahed-agent-comm-framework-01.txt | ||||||||||||||
| AI Agent Interoperable Protocol Framework (AIPF) | ||||||||||||||
|
The current generation of AI agent communication protocols enables basic tool access and inter-agent messaging, but lacks the architectural and protocol foundations required for open, interoperable, and resilient Internet-scale deployments. This document presents the AI Agent Interoperable Protocol Framework (AIPF), a layered framework that identifies the key building blocks and the protocol suite required for interoperable Agent-to-agent/ Agent-to-tool communication. | |||||||||||||
| draft-zcl-pim-multiif-igmp-mld-proxy-yang-03.txt | ||||||||||||||
| YANG Data Model for supporting multipath IGMP/MLD proxies | ||||||||||||||
|
The ability to support multiple upstream interfaces in IGMP/MLD proxies necessitates configuring different upstream interfaces for specific multicast channels or sessions. [RFC9398] defined YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices. Building on that foundation, this document proposes an augmentation of thet model for the support of multiple upstream interfaces in IGMP/MLD proxies. | |||||||||||||
| draft-zcz-nmrg-digitaltwin-data-collection-05.txt | ||||||||||||||
| Data Collection Requirements and Technologies for Network Digital Twin | ||||||||||||||
|
A Network Digital Twin is a virtual representation of a real network, which is meant to be used by a management system to analyze, diagnose, emulate, and then control the real network based on data, models, and interfaces. The construction and state update of a Network Digital Twin requires obtaining real-time information of the physical network it represents (i.e., telemetry data). This document aims to describe the data collection requirements and provide data collection methods or tools to build the data repository for building and updating a network digital twin. | |||||||||||||
| draft-zdz-teas-5g-slice-ipextension-00.txt | ||||||||||||||
| Carrying 5G Network Slice Identifiers in IP Headers for QoS Assurance Beyond the 3GPP-Managed Domain | ||||||||||||||
|
3GPP defines 5G network slicing as an end-to-end service spanning the Radio Access Network (RAN), Transport Network (TN), and Core Network (CN). Within these domains, dedicated slice-awareness and management mechanisms are specified by 3GPP. However, when 5G slice traffic traverses an IP backbone network that lies outside the 3GPP-managed domain -- such as when a User Plane Function (UPF) connects to an external service provider network -- slice context information is lost, and the IP backbone cannot differentiate or assure the quality of individual slices. This document proposes a method for preserving 5G network slice awareness in IP backbone networks by encoding the 3GPP Single Network Slice Selection Assistance Information (S-NSSAI) directly into IPv6 packet headers. This document also describes the associated procedures for slice-aware QoS assurance in the IP backbone. | |||||||||||||
| draft-zedongjia-v6ops-ipv6eh-measurement-01.txt | ||||||||||||||
| Observations on the Reachability and Evasion of Packets with IPv6 Extension Headers on the Internet | ||||||||||||||
|
IPv6 Extension Headers (EHs) are designed to provide protocol flexibility and support for emerging features, while maintaining a concise base header and efficient processing. In practice, their reachability is affected by middlebox handling along the path, and their flexibility also introduces security considerations. This document presents observations from a comprehensive, large-scale measurement study of IPv6 Extension Header path traversal across more than 23,000 autonomous systems. Using a feedback-driven measurement framework called 6Travel, the reachability of 11 common IPv6 Extension Headers is measured over ICMPv6, TCP, and UDP. The measurements indicate a change relative to earlier work: contrary to past observations of heavy filtering, specific Extension Headers now achieve reachability comparable to plain traffic. Two distinct forms of policy ossification are observed across industry categories, together with widespread potential Extension-Header-based firewall evasion signatures in nearly 5,000 autonomous systems, particularly under TCP and UDP. These signatures appear consistent with a combination of implementation flaws and security misconfigurations, spanning both on-path and host-side firewalls. | |||||||||||||
| draft-zehavi-oauth-authz-req-del-chain-01.txt | ||||||||||||||
| OAuth Authorization Request Delegation Chain | ||||||||||||||
|
Brokered OAuth redirect authorization requests involve intermediary authorization servers between a downstream client and the upstream authorization server that obtains user consent and issues tokens. Such deployments have security risks because the upstream authorization server sees only the immediate OAuth client and is unaware of the downstream client or intermediary brokers obtaining its response. This document defines an OAuth 2.0 profile for carrying a verifiable, signed authorization request delegation chain as a RAR authorization_details object [RFC9396]. Each node in the chain is a JSON object signed by an attesting authorization server using detached JWS [RFC7515], attesting its validated client, hash-linked to the previous node, allowing the upstream authorization server to validate the integrity of the visible delegation path and apply policy before issuing tokens. | |||||||||||||
| draft-zehta-aipref-exclusions-01.txt | ||||||||||||||
| AIPREF Vocabulary Exclusions | ||||||||||||||
|
This document proposes an update to the AI preferences vocabulary [VOCAB] in order to establish protected uses (exclusions). | |||||||||||||
| draft-zehta-aipref-parameters-00.txt | ||||||||||||||
| AIPREF Vocabulary Parameters | ||||||||||||||
|
This document defines how parameters can be added to AI Preferences. | |||||||||||||
| draft-zerobankx-srl-core-03.txt | ||||||||||||||
| Secure Resource Layer (SRL) Core | ||||||||||||||
|
This document defines the Secure Resource Layer (SRL), a global trust layer that evaluates digital resources before they are accessed. SRL introduces governance, verification, and revocation mechanisms that complement existing URL, QR code, barcode, RFID, and short URL systems. SRL is designed to be deployable incrementally through resolver-based, scanner-level, reader-level, and application-level integrations, without requiring changes to existing Internet standards, browsers, operating systems, or identifier formats. This revision extends the document with implementation testing and operational validation of hybrid resource identifiers in logistics and supply-chain environments. The testing combines QR codes, barcodes, and RFID-derived identifiers under a common SRL trust framework while preserving compatibility with existing operational systems. | |||||||||||||
| draft-zhang-aiproto-svcb-mapping-for-agents-02.txt | ||||||||||||||
| Service Binding Mapping for Agents | ||||||||||||||
|
With the continuous introduction of intelligent agent communication and interaction protocols, the current DNS cannot adequately meet the requirements for agent service resolution. This document defines a new DNS resource record type, AGENT, which is a SVCB-compatible RR type, and specifies the mapping specifications. | |||||||||||||
| draft-zhang-cats-clients-request-packet-00.txt | ||||||||||||||
| CATS Client Service Request Packet Format (IPv6 Extension Header and Payload-Based Carriage of CS-ID and Network/Computing Requirement Parameters) | ||||||||||||||
|
This document specifies two complementary mechanisms for carrying the CATS Service Identifier (CS-ID) and network/computing requirement parameters in client service request packets within the Computing- Aware Traffic Steering (CATS) framework. Mode A uses IPv6 Extension Headers to carry CS-ID and requirement parameters as hop-by-hop or destination options, enabling in-band signaling that is visible to all CATS-aware network nodes along the path. Mode B uses a payload-based TLV structure that is transport- protocol agnostic and can be used with both IPv4 and IPv6, as well as with encrypted transports. The document defines the Virtual Placeholder Address (VPA) prefix requirements, the CATS Service Request Extension Header (CSREH) format, the CATS Service Request TLV format, and the CATS_PACKET_IN process for handling these packets at ingress CATS-Forwarders. | |||||||||||||
| draft-zhang-dawn-agent-discovery-framework-01.txt | ||||||||||||||
| A Framework for Agent Discovery in DAWN | ||||||||||||||
|
The IETF DAWN (Discovery of Agents With Names) working group is developing a suite of documents addressing agent discovery across organizational boundaries, initially focused on discovery of AI agents and their capabilities. Existing DAWN contributions include terminology, requirements, use cases, gap analysis, a discovery mechanism survey, and an information model for Minimum Discoverable Information (MDI). This document describes a two-layer federated reference architecture framework that operates within the DAWN. The first layer, the Local Discovery Plane, performs zero-configuration agent advertisement and collection inside each local site, without mandating a specific link- local protocol. The second layer, the Federation Plane, builds a federation among site gateways to exchange lightweight Federation Metadata Records (FMRs) — a concrete binding of DAWN MDI — across independent administrative domains, while full Capability Cards are retrieved on demand via authenticated unicast. The architecture emphasizes data sovereignty through an Export Policy Engine, separates lightweight metadata indexes from full capability documents, and supports multiple federation synchronization strategies. This document is informational. It does not define normative protocol formats, nor does it compete with existing DAWN proposals such as ACAP, Agent Directory, or ARDP; rather, it provides a deployment framework showing how these mechanisms may be composed at administrative boundaries. Consistent with the DAWN charter, the architecture is primarily targeted at AI agent discovery while remaining general and reusable for other entity types. | |||||||||||||
| draft-zhang-dmsc-gateway-directory-sync-01.txt | ||||||||||||||
| Gateway Capability Directory and Synchronization for Internet of Agents | ||||||||||||||
|
This document describes a gateway capability-directory framework for the Internet of Agents (IoA) in deployments that use Agent Gateways. In such deployments, a gateway-managed capability directory is a necessary control-plane function for maintaining validated capability information beyond transient advertisements, static endpoint bindings, or external descriptions alone. This document defines requirements and a common object model for gateway-managed capability information, including the Agent Capability Specification (ACS), Capability Digest, and directory entry lifecycle. It also specifies synchronization, freshness, provenance, and validation requirements for capability information exchanged across gateways. This document clarifies the relationship between gateway-managed ACS objects and externally published descriptions such as the A2A Agent Card, and briefly compares this framework with broader distributed directory-service approaches. It does not define a discovery query protocol, ranking algorithm, storage substrate, distributed lookup algorithm, task orchestration protocol, or agent-to-agent session protocol. It can inform subsequent DMSC protocol work, including capability digest synchronization and related gateway procedures. | |||||||||||||
| draft-zhang-dmsc-ioa-semantic-interaction-02.txt | ||||||||||||||
| Ontology-based Semantic Interaction for Internet of Agents | ||||||||||||||
|
This document specifies a normative semantic layer for agent-to-agent interaction in the Internet of Agents (IoA). The semantic layer provides a common ontology model and a JSON-LD serialization profile (RECOMMENDED), while allowing other RDF serializations for expressing capabilities, intents, tasks, and context. The document defines required classes and properties, a negotiation procedure, and alignment rules for heterogeneous ontologies. This layer is designed to be used by interaction and discovery protocols but does not define transport, session, or security protocols. It enables deterministic semantic interoperability across domains. | |||||||||||||
| draft-zhang-dnsop-tld-transition-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-idr-portid-ec-02.txt | ||||||||||||||
| BGP PORT EC for AIDC | ||||||||||||||
|
This document introduces a new BGP extended community attribute for AI computing scenarios. This attribute is used to carry the port ID when advertising routes on the switch before launching AI tasks, preparing for negotiation before sending large-scale traffic. | |||||||||||||
| draft-zhang-idr-sr-policy-template-08.txt | ||||||||||||||
| BGP SR Policy Extensions for template | ||||||||||||||
|
Segment Routing(SR) Policies can be advertised using BGP. An SR Policy may has lots of attributes, and as the application and features evolve, the SR Policy may need have more and more attribute attributes. To avoid modifying BGP when attributes are added to an SR Policy, we can define a template. The identifier and content of the template are defined by the receiver of the SR Policy. The advertiser of an SR policy only needs to know the ID of the template. When advertising SR policy, the advertiser carries the template ID in the tunnel encapsulation information of the SR policy. After receiving the SR Policy information, the receiver obtains the corresponding template and content according to the template ID, thereby obtaining abundant constraint configuration information. | |||||||||||||
| draft-zhang-ioa-usage-accounting-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-ippm-isft-space-flow-telemetry-00.txt | ||||||||||||||
| In-situ Space Flow Telemetry for IPv6 Limited Domains | ||||||||||||||
|
Space networks, including satellite networks, often operate with constrained bandwidth, processing capacity, storage, and energy, while also experiencing dynamic topology and frequent link changes. Existing in-situ Operations, Administration, and Maintenance (IOAM) mechanisms provide useful per-packet telemetry, but the packet overhead and field selection flexibility can be costly in such environments. This document specifies In-situ Space Flow Telemetry (ISFT), a compact telemetry profile for IPv6 limited domains. ISFT defines an 8-octet telemetry option header, a small set of telemetry templates for delay, loss, and congestion information, and processing behavior for encapsulating, transit, and decapsulating nodes. ISFT is intended for controlled domains such as space-network segments and MUST NOT be exposed as an Internet-wide protocol behavior. | |||||||||||||
| draft-zhang-rtgwg-agent-policy-aware-network-01.txt | ||||||||||||||
| Use Cases and Requirements for AI Agent Policy-Aware Network | ||||||||||||||
|
With the widespread adoption of AI Agents, traditional network architectures can no longer meet the demand for efficient collaboration between agents and networks. This document proposes a new paradigm of "AI Agent Policy-Aware Network", enabling three key transformations: from Flow-aware to Agent-aware, from QoS-based to Policy-intent-based, and from Network-driven to Agent-network collaborative. By defining core components such as the Agent Policy- aware Controller and Agent Policy-Aware Device, this paradigm establishes a dynamic mapping mechanism between Agent intents and network policies, supporting key scenarios including autonomous performance measurement, path optimization, SLA assurance, and secure transmission. This document outlines the background, scenarios, use cases and requirements of Agent Policy-aware Network. | |||||||||||||
| draft-zhang-rtgwg-ecmp-lossless-convergence-00.txt | ||||||||||||||
| 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. | |||||||||||||
| draft-zhang-rtgwg-llmmoe-multicast-03.txt | ||||||||||||||
| Multicast use case in LLM MoE | ||||||||||||||
|
Large Language Models (LLMs) have been widely used in recent years. The Mixture of Experts (MoE) architecture is one of the features of LLMs that enables efficient inference and cost-effective training. With the MoE architecture, there are potential multicast use cases such as tokens dispatching. This draft attempts to analyze these use cases. | |||||||||||||
| draft-zhang-rtgwg-multicast-requirements-gaps-aidc-02.txt | ||||||||||||||
| Requirements and Gap Analysis of Multicast in AI Data Centers | ||||||||||||||
|
Multicast has the potential to be applied in Artificial Intelligence Data Centers (AIDCs) to improve the efficiency of point-to-multipoint data transmission during large language model training and inference. This document identifies key requirements of multicast in AIDCs, and analyzes the gaps between these requirements and the capabilities of existing multicast technologies. | |||||||||||||
| draft-zhang-scone-migration-advice-00.txt | ||||||||||||||
| Endpoint Handling of SCONE Throughput Advice Across QUIC Path Changes | ||||||||||||||
|
SCONE throughput advice is scoped to the path and direction in which it is received. When a QUIC connection changes path, the endpoint can retain an old advice value while that value is no longer applicable to the active path. This document describes endpoint- local handling of that transition. It focuses on the distinction between retained advice and active-path advice, the interval in which no fresh path-applicable advice is available, and the observability needed to avoid treating historical advice as current guidance. This document defines no new SCONE protocol elements, does not modify QUIC path validation, does not define an application API, and does not change congestion control behavior. | |||||||||||||
| draft-zhang-seat-selection-01.txt | ||||||||||||||
| Balancing Security and Deployability in the Selection of Attested TLS Protocol | ||||||||||||||
|
This document analyzes the selection of Attested Transport Layer Security (aTLS) protocols, among pre-handshake, intra-handshake, and post-handshake aTLS protocols, focusing on the trade-off between theoretical security strength and practical deployability. The goal is to enable flexible, context-aware deployment of endpoint attestation while maintaining compatibility with existing infrastructure. | |||||||||||||
| draft-zhang-sidrops-aspa-egress-05.txt | ||||||||||||||
| ASPA-based AS_PATH Verification for BGP Export | ||||||||||||||
|
This document describes AS_PATH verification based on Autonomous System Provider Authorization (ASPA) for egress eBGP speakers. ASPA is a Resource Public Key Infrastructure (RPKI) object that allows an AS to register its transit provider ASes. Performing ASPA-based AS_PATH verification at egress can prevent inadvertent propagation of route leaks to external peers, check for local misconfigurations, and help detect potential ASPA registration errors. This approach complements ingress-side verification and BGP Roles/Only to Customer (OTC); it also provides operational assurance for partial deployment and for export-side configuration or registration problems. | |||||||||||||
| draft-zhang-sidrops-prioritized-route-validation-02.txt | ||||||||||||||
| RPKI-based Validation with Prioritized Resource Data | ||||||||||||||
|
The Resource Public Key Infrastructure (RPKI) provides globally verifiable signed routing security data, such as Route Origin Authorizations (ROAs). Operators also commonly use local or supplemental data sources, including SLURM files, operator-maintained exceptions, IRR-derived inputs, and other operator-selected supplemental data, to improve local routing decisions. These sources may not have the same authority as signed RPKI objects and therefore may require operator-configured priority-safe handling. This document describes a framework for RPKI-based validation with prioritized resource data. It defines priority-safe handling semantics that allow operators to use data sources with different levels of authority or assurance for local routing policy, while preserving the global authorization semantics of signed RPKI data. The document also discusses deployment models with different implementation costs and operational trade-offs. | |||||||||||||
| draft-zhang-sidrops-rpki-roa-bcp-02.txt | ||||||||||||||
| Best Current Practice for ROA Issuance Restrictions in RPKI | ||||||||||||||
|
This document specifies best current practices for Resource Public Key Infrastructure (RPKI) operators regarding Route Origin Authorizations (ROAs). It RECOMMENDS that a parent Certification Authority (CA) void issuing ROAs for Internet number resources delegated to a child CA. RPKI certification authorities(CA software) and relying party software are expected to support these practices by appropiate warning. | |||||||||||||
| draft-zhangb-cats-cmas-06.txt | ||||||||||||||
| Public Service Platform for Computing-Aware Traffic Steering (CATS) | ||||||||||||||
|
CATS applications require service resolution and traffic steering across heterogeneous computing resources. Directly exposing raw computing metrics from different hardware platforms can be difficult for clients, service sites, and CATS control-plane components to interpret consistently. This Informational document describes the purpose and functions of a public service platform for CATS, and identifies the CS-ID-related information fields needed by those functions. The platform maintains a common service catalogue, associates public service identifiers with service descriptions and deployment requirements, and provides the service context used by service-oriented metric mechanisms. This platform supports the Computing Metrics as a Service (CMAS) approach by allowing heterogeneous resources to be represented through service-oriented parameters rather than raw hardware metrics. Service-oriented metric definitions and operational procedures are specified in [I-D.zhangb-cats-service-metrics-op-02]. | |||||||||||||
| draft-zhangb-cats-csma-implementation-00.txt | ||||||||||||||
| CATS Service Metric Agent (C-SMA) Functional Implementation | ||||||||||||||
|
The Computing-Aware Traffic Steering (CATS) framework introduces the CATS Service Metric Agent (C-SMA) as the functional entity responsible for collecting service capabilities and status, and reporting them to CATS Path Selectors (C-PSes). While existing drafts define the metrics and high-level framework, the concrete functional behavior, internal architecture, and operational procedures of the C-SMA remain underspecified. This document fills that gap by defining the functional implementation of the C-SMA. Specifically, it specifies how the C-SMA collects metrics from multiple Service Contact Instances (SCIs) within a service site; how it validates, and caches these metrics; how it adapts to various control-plane protocols for metric distribution; how it enforces local policies and security policies; and how it maintains synchronization with the C-PS under dynamic conditions. This document complements [I-D.ietf-cats-framework] and [I-D.zhangb-cats-service-metrics-op] by providing the operational execution layer for the C-SMA. | |||||||||||||
| draft-zhangb-cats-sci-implementation-00.txt | ||||||||||||||
| CATS Service Contact Instance Functional Implementation | ||||||||||||||
|
The Computing-Aware Traffic Steering (CATS) framework introduces the concept of a Service Contact Instance (SCI) as the client-facing entity responsible for receiving and dispatching service requests. While existing drafts define the framework and metrics, the concrete functional behavior of a Service Contact Instance remains underspecified. This document fills that gap by defining the functional implementation of a CATS Service Contact Instance. Specifically, it specifies how an SCI collects, aggregates, and reports service instance metrics to the CATS Service Metric Agent (C-SMA); how it monitors the health and status of underlying service instances; how it dispatches client requests to the most appropriate service instance based on local policy and real-time conditions; and how it maintains affinity and handles failure scenarios. This document complements [I-D.ietf-cats-framework] and [I-D.zhangb-cats-service-metrics-op] by providing the operational execution layer for the SCI. | |||||||||||||
| draft-zhangb-cats-service-metric-registry-entries-00.txt | ||||||||||||||
| CATS Computing Service Metric Registry Entries | ||||||||||||||
|
This document defines the initial set of registry entries for Computing Service Metrics used in Computing-Aware Traffic Steering (CATS). These metrics, including Global Available Slots (GAS), Computing Time, Cost, Reputation, Security Label, and Capability, provide service-oriented abstractions that complement the existing CATS Level 0/Level 1/Level 2 normalized metric framework defined in [I-D.ietf-cats-metric-definition]. This document follows the registry format and separation pattern established by [RFC8911] and [RFC8912], populating a new IANA registry titled "CATS Computing Service Metrics" with formal entries for each metric defined in [I-D.zhangb-cats-service-metrics-op]. | |||||||||||||
| draft-zhangb-cats-service-metrics-op-05.txt | ||||||||||||||
| Computing Service Metrics Operation and Joint Service Selection under CATS | ||||||||||||||
|
Computing-Aware Traffic Steering (CATS) optimizes traffic forwarding by considering both computing and networking metrics. The CATS framework and metric-definition documents provide valuable theoretical models, yet they face challenges in achieving direct operational execution in real-world deployments: normalization methods vary across providers, and aggregated unitless scores often lose the operational information that routers need for precise steering decisions. This document provides a self-contained, executable operational model for a core class of CATS deployment scenarios: latency-sensitive, compute-intensive services whose steering decisions are made in real time at the forwarding node. Instead of disseminating low-level raw hardware metrics, service sites dynamically evaluate and report service-oriented metrics (e.g., Global Available Slots and Computing Time) to the control plane. The document clarifies how these metrics are derived from basic resource information, service reference information, and local policy. It also specifies how the CATS Path Selector (C-PS) combines the Computing Service Table (populated from C-SMA reports) with the Network Service Table to make joint traffic- steering decisions, and defines update-control and fallback mechanisms suitable for large-scale deployments. Within the unified CATS architecture, the service-oriented operational model defined in this document coexists with the general- purpose L1/L2 normalized metric framework: a deployment MAY use either model, or run both pipelines in parallel for different service classes, without embedding metric fields across frameworks. This document does not negate the value of normalized metrics; it focuses on the service-level abstractions and runtime operations required for direct traffic steering. | |||||||||||||
| draft-zhao-a2a-dns-sd-00.txt | ||||||||||||||
| DNS-Based Service Discovery for Agent2Agent (A2A) Protocol Agents | ||||||||||||||
|
The Agent2Agent (A2A) protocol defines how two agents communicate once one knows the other's URL, and how an agent's self-description (the Agent Card) is retrieved from a well-known URI at that URL. It does not define how agents on the same host or local network find each other in the first place. This document profiles DNS-Based Service Discovery (DNS-SD) over Multicast DNS (mDNS) for that purpose: it defines the "a2a" service type, the TXT record keys used with it, the discovery procedure, and the security model under which discovery results are treated as hints whose trust is established by Agent Card verification, not by the discovery channel. It also requests IANA registration of the "a2a" service name. | |||||||||||||
| draft-zhao-a2a-webfinger-00.txt | ||||||||||||||
| A WebFinger Profile for Agent2Agent (A2A) Agent Identity Resolution | ||||||||||||||
|
The Agent2Agent (A2A) protocol retrieves an agent's self-description (the Agent Card) from a fixed well-known URI, which resolves exactly one agent per origin and presumes the client already holds a URL. This document profiles WebFinger for A2A: an agent is named by an "acct" URI (agent@domain), and resolution of that name over WebFinger yields a link to the Agent Card of the endpoint that serves the agent -- the agent's own endpoint, or a gateway fronting it. The profile introduces no new link relation, media type, or registry: it composes three deployed standards and states how they fit. | |||||||||||||
| draft-zhao-anima-automatic-congestion-relief-01.txt | ||||||||||||||
| Automatic Network Congestion Relief | ||||||||||||||
|
This document describes an automatic network congestion relief mechanism for congestion caused by sudden capacity reduction, such as fiber failures. The mechanism uses traffic modeling, real-time congestion monitoring, policy generation, policy propagation, traffic regulation, and policy reversion to redistribute selected traffic from a congested plane to a lightly loaded paired plane. The objective is to reduce manual intervention, shorten congestion mitigation time, and improve network resilience during failure conditions. | |||||||||||||
| draft-zhao-cats-otn-applicability-01.txt | ||||||||||||||
| Framework and Applicability of Computation-aware Traffic Steering (CATS) in Optical Transport Networks (OTN) | ||||||||||||||
|
Computation-aware Traffic Steering (CATS) offers a framework for selecting computation service sites based on computation capabilities and load, and considering the network capabilities and state on the paths to the sites. Optical Transport Networks (OTN) provide guaranteed separation of traffic along with reserved hardware resources offering bandwidth and quality of service promises. This document describes how OTN may be used to support a CATS system to achieve the stringent performance targets required by demanding service environments. | |||||||||||||
| draft-zhao-ccamp-actn-optical-network-agent-02.txt | ||||||||||||||
| Integration of Network Management Agent (NMA) into ACTN-Based Optical Network | ||||||||||||||
|
With the growth of optical network scale, the complexity of network operation and maintenance has increased dramatically. Enhancing the intelligence level of optical network operation and management and building high-level autonomous optical networks have become the common vision of global operators. The development of AI, especially large AI model technologies, provides a feasible technical path for realizing autonomous perception, decision-making, analysis, and execution. The existing ACTN architecture provides network abstraction and control functions for optical networks but lacks higher-level autonomous capabilities. This document explores the introduction of AI based Network Management Agent(NMA) functions into ACTN-based optical networks to achieve high-level autonomy of optical networks. It discusses the ACTN-enhanced architecture of optical networks after the introduction of NMAs, including key components, interaction relationships, new interface requirements in the enhanced architecture, as well as typical use cases of agent-based autonomous operation and maintenance for optical networks. The document aims to improve the autonomy level of optical networks and promote the realization of autonomous optical networks by extending the original ACTN architecture. | |||||||||||||
| draft-zhao-grow-bgp-graceful-degradation-00.txt | ||||||||||||||
| BGP Graceful Degradation Under Control Plane Memory Pressure | ||||||||||||||
|
This document describes an operational framework for graceful degradation of BGP under control-plane memory pressure. When BGP speakers experience rapid growth in routing state due to route flapping, configuration errors, or anomalous route injection, control-plane memory can become exhausted, leading to session resets, routing process restarts, or device reboots. The framework described in this document progressively reduces BGP route admission and processing based on local resource conditions, isolates non-critical neighbors or services when necessary, and restores routing state in a controlled manner after recovery. The objective is to preserve basic device operation and reduce service impact. This document does not define any new BGP messages, path attributes, capabilities, or protocol state machines. | |||||||||||||
| draft-zhao-iccrg-competitive-mode-01.txt | ||||||||||||||
| Competitive Mode Enhancement for Delay-Based Congestion Control Algorithms | ||||||||||||||
|
This document proposes introducing a "Competitive Mode" into delay- based congestion control algorithms to improve their competitiveness and fairness during coexistence scenarios. | |||||||||||||
| draft-zhao-nmop-network-management-agent-05.txt | ||||||||||||||
| AI based Network Management Agent(NMA): Concepts and Architecture | ||||||||||||||
|
The evolution from Level 3 (assisted automation) to Level 4 (closed- loop autonomy) in Autonomous Networks (AN) introduces requirements for agentic capabilities, including intent-based reasoning, autonomous planning, and context-aware decision-making, and execution coordination, which transcend the static, rule-based logic of traditional network controllers. This document defines the concept of the Network Management Agent (NMA), a network management entity with autonomous task processing capabilities designed to bridge the gap between service intent and network operations. This document describes the role of NMA in network management and control architectures, and specifies how the NMA collaborates with existing network controllers to achieve Autonomous L4 without replacing or duplicating their functions. It further defines the reference architecture, deployment modes, and logical interfaces of the NMA, including Agent-to-User (A2U), Agent-to-Agent (A2A), Agent- to-Controller (A2C), and Agent-to-Network (A2N) interactions. | |||||||||||||
| draft-zhao-nmop-nma-a2u-yang-00.txt | ||||||||||||||
| Framework and YANG Data Model for the NMA A2U Interface | ||||||||||||||
|
This document describes a framework and a YANG data model for the Agent-to-User (A2U) interface of a Network Management Agent (NMA). The A2U interface is a user-facing interface through which a non- agent upper-layer system or user, such as an operator's OSS/BSS, orchestrator, management portal, human-facing application, automation system, etc., interacts with an NMA. The A2U interface supports NMA capability discovery, unified intent submission, task lifecycle management, execution plan exposure, human-in-the-loop confirmation, task progress notification, and consistent error reporting. The YANG data model defined in this document includes operational state data, RPC operations, and YANG notifications for the A2U interface. The model is intended to be used with YANG-based management protocols. This document does not define a separate transport protocol, a new HTTP resource API, or a separate notification delivery mechanism. | |||||||||||||
| draft-zhao-nmrg-ip-optical-ndt-sim-framework-00.txt | ||||||||||||||
| A Lightweight Cross-Layer Simulation Framework for IP-Optical Network Digital Twins | ||||||||||||||
|
This document describes a lightweight cross-layer simulation framework for IP-optical Network Digital Twins. The framework correlates IP-layer logical topology, traffic-engineering state, Segment Routing policies, optical and transport resources, OTN resources, and physical shared-risk objects in a digital twin environment. The framework is intended to support what-if analysis for cross-layer failure propagation, soft degradation, protection-timer interaction, service-aware traffic shifting, shared-risk validation, and energy- aware operation. This document does not define a new routing protocol, optical control-plane protocol, BGP-LS extension, ACTN interface, or YANG data model. The framework is intended for planning, assurance, simulation, and analysis. Simulation outputs are not directly applied to production network elements. | |||||||||||||
| draft-zhao-opsawg-agent-gateway-policy-01.txt | ||||||||||||||
| Agent Gateway Policy Control Model | ||||||||||||||
|
This document defines an operational policy control model for operator-managed Agent Gateways. The model describes how an operator can control and observe interactions that are admitted, mediated, routed, proxied, or otherwise handled by an Agent Gateway. The model does not govern an agent's internal behavior, reasoning, planning, prompts, memory, tools, runtime, or lifecycle. Instead, it uses agent-related identifiers, groups, tenants, task classes, and service levels as gateway-recognized policy matching attributes. Those attributes allow an operator-managed Agent Gateway to identify the interactions to which a policy applies. The model defines four core policy classes: Interaction Access Control, QoS and Flow Control, Invocation and Token Control, and Path Selection. It further defines three supporting management capabilities: Subject and Attachment Binding, Applied Policy State and Telemetry, and Policy Lifecycle and Failure Handling. | |||||||||||||
| draft-zhao-opsawg-network-resilience-ps-01.txt | ||||||||||||||
| Problem Statement for Network Resilience | ||||||||||||||
|
This document defines the problem space for network resilience. It identifies representative failure sources that expose limitations in current network architectures when facing complex, cascading, correlated, and unanticipated failures. It further analyzes cross- cutting resilience challenges and capability gaps across the pre- event, in-event, and post-event stages of the failure lifecycle, and derives a set of technical capabilities needed to improve network resilience. | |||||||||||||
| draft-zheng-ccamp-client-pm-yang-16.txt | ||||||||||||||
| A YANG Data Model for Client Signal Performance Monitoring | ||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. | |||||||||||||
| draft-zheng-ccamp-client-tunnel-yang-19.txt | ||||||||||||||
| A YANG Data Model for Client-layer Tunnel | ||||||||||||||
|
A transport network is a server-layer network to provide connectivity services to its client. In this draft the tunnel of client is described, with the definition of client tunnel YANG model. | |||||||||||||
| draft-zhou-ippm-enhanced-alternate-marking-19.txt | ||||||||||||||
| Enhanced Alternate Marking Method | ||||||||||||||
|
This document extends the IPv6 Alternate Marking Option to provide enhanced capabilities and allow advanced functionalities. With this extension, it can be possible to perform thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring. | |||||||||||||
| draft-zhou-structured-data-schema-interaction-00.txt | ||||||||||||||
| Structured Data Schema Interaction Protocol for Multi-Agent Collaboration | ||||||||||||||
|
This document defines a structured data schema interaction protocol for multi-agent collaboration. As AI agents increasingly interoperate across heterogeneous platforms, natural-language-based communication suffers from semantic drift, high inference overhead, and ambiguous data flow. This protocol introduces a standardized key-value schema with semantic annotations, enabling deterministic, efficient, and interoperable agent-to-agent communication. A lightweight schema negotiation mechanism is provided for initial alignment at the beginning of communication, while an optional key- value update mechanism allows agents to reflect evolving requirements without breaking existing structured data schema interaction protocol. | |||||||||||||
| draft-zhu-agent-registration-discovery-00.txt | ||||||||||||||
| Registration and Discovery Extension for Multi-Model Agents | ||||||||||||||
|
Existing agent registration and discovery mechanisms assume that each intelligent agent is backed by a single, static inference model. However, in real-world deployments, agents increasingly incorporate internal model routing mechanisms where multiple foundation models are used dynamically within a single agent based on task complexity, latency requirements, system load, and cost constraints. Although such agents are exposed externally as single service endpoints, their execution behavior is not static and may vary due to internal model selection logic that is not visible to external systems. This leads to mismatches between registered metadata and actual service behavior, reducing the effectiveness of discovery and QoS-aware routing. | |||||||||||||
| draft-zhu-anima-service-intent-01.txt | ||||||||||||||
| Definition of Service Intent in Autonomic Networks | ||||||||||||||
|
While ANIMA Intent enables goal-oriented control within an Autonomic Domain, emerging services (e.g., AI inference) require a common, interoperable representation for expressing service-level objectives and constraints that span network, compute, and storage resources, rather than connection-centric descriptions. This document defines Service Intent for Autonomic Networks by specifying a structured semantic model and a concise format with identification, scope, versioning, and lifecycle semantics. | |||||||||||||
| draft-zhu-cats-metric-semantics-01.txt | ||||||||||||||
| Operational Semantics for CATS Metric Consumption | ||||||||||||||
|
The CATS framework introduces computing-related information into traffic steering decisions. Existing work defines how such metrics are represented, distributed, and used within the CATS architecture. However, it does not fully address whether a metric remains suitable for use at the point of consumption. This document introduces a set of operational semantics for CATS metrics, including Freshness, Operational acceptability, and Assurance exposure. These semantics describe whether a metric remains temporally aligned with the underlying condition, whether it remains suitable for operational use in steering, and whether degraded consumption is externally visible to management or OAM functions. The document further explains how these semantics apply across centralized, distributed, and hybrid deployments, including cases where different metric sources contribute under different conditions. The goal is to provide a consistent basis for interpreting metric usability in CATS without introducing a new metric level or prescribing a single derivation method. Implementations may determine when degradation occurs, while the resulting consumption condition can still be represented and understood consistently across CATS functions. | |||||||||||||
| draft-zhu-dnsop-de-eeas-02.txt | ||||||||||||||
| DNS Extensions to Energy Efficiency as a Service(EEAS) | ||||||||||||||
|
This document describes a new Mechanism and DNS resource record (RR) type to carry information about energy-related characteristics for end-to-end internet access. The "EE" ("Energy Efficiency") record allows the network to provide different levels of energy-saving service. By providing more energy information to the client before it attempts to establish a connection, these records offer potential benefits to enhancements on energy as service criteria. | |||||||||||||
| draft-zhu-httpbis-task-context-00.txt | ||||||||||||||
| Task-Context HTTP Field for Task Context Propagation | ||||||||||||||
|
This document defines the Task-Context HTTP field for propagating task execution context from an authorized workflow worker to downstream HTTP services. The field carries a compact, base64url- encoded JSON object that identifies the authorization mode, workflow type, and either task-based requestor and approver context or role- based execution context. The field is not a bearer credential and does not replace HTTP client authentication, service-to-service authorization, or resource-local policy checks. Its purpose is to let downstream services correlate requests with workflow task context and make service-local authorization and audit decisions using that context. | |||||||||||||
| draft-zhu-oauth-async-delegation-05.txt | ||||||||||||||
| Delegated Refresh Tokens for OAuth 2.0 Token Exchange | ||||||||||||||
|
OAuth 2.0 Token Exchange permits an authorization server to issue a refresh token when a client needs continued access after the original credential is no longer valid. However, RFC 8693 does not define how a refresh token issued by a delegated Token Exchange preserves the subject, actor chain, resource restrictions, or other delegated authorization state. This specification profiles refresh tokens issued by delegated OAuth 2.0 Token Exchange for asynchronous and long-running workflows. It defines authorization-server metadata advertising profile support and a Token Exchange request signal by which a client requests delegated continuation, together with preservation of subject and actor relationships, client and actor binding, resource confinement, scope monotonicity, authorization re-evaluation, rotation, task-scoped revocation, and a bounded delegation lifetime. The common discovery signal, request signal, and semantics enable autonomous agents and other product components to interoperate with independently implemented authorization servers across trust domains. Because a client generally cannot determine the effective lifetime of an opaque refresh token, this profile requires the client to request continuation only for an identified asynchronous task and to promptly revoke the refresh-token family when that task reaches a terminal state. These requirements reduce unnecessary issuance and limit the period in which residual delegated authority can be abused. The profile uses the existing OAuth refresh token response and grant and introduces no new token type or grant type. | |||||||||||||
| draft-zhu-qirg-qdcp-01.txt | ||||||||||||||
| Quantum Datagram Control Protocol (QDCP) for IP Optical Environments | ||||||||||||||
|
This document specifies the Quantum Datagram protocol a lightweight transport protocol designed to operate over UDP in IP optical environments. QDCP (formerly QFCP) enables the transmission of control- plane parameters required for transporting quantum information and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length- Value (TLV) structure to support versioning and extensibility and is prototyped for the transport of third-order nonlinear generated quantum information on IP optical infrastructure. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics. | |||||||||||||
| draft-zhu-sketch-int-codesign-01.txt | ||||||||||||||
| Sketch-INT Co-Design for Accurate Network Measurement: Applicability to Time-Variant Non-Terrestrial Networks | ||||||||||||||
|
Network measurement supports management applications that need statistics about both large and small flows. Sketch-based techniques use compact data structures and are effective for large flows, but hash collisions can produce substantial relative errors for small flows. In-band Network Telemetry (INT) can provide detailed observations for individual packets, but applying it to every packet can consume significant packet, bandwidth, and collector resources. This document describes a framework that uses sketches for large flows and INT for small flows. It also describes measurement-point selection when exact routing information is unavailable and congestion-aware collection of sketch and INT reports. The document identifies the information needed to describe and compare implementations. It does not define a new packet format, INT instruction, sketch algorithm, or routing protocol. As a concrete applicability direction, the document considers time- variant non-terrestrial networks (NTNs), in which paths and available forwarding resources can change over time. It maps the existing Sketch-INT framework to this scenario and identifies the assumptions that require validation. It does not claim that the existing terrestrial implementation has been deployed or evaluated on satellite hardware. | |||||||||||||
| draft-zhu-space-distributed-computing-requirements-00.txt | ||||||||||||||
| Network Support for Distributed Computing in Space Networks | ||||||||||||||
|
Distributed execution can be useful in space networks when one node lacks enough computing, storage, energy, or execution time, or when data is spread across multiple nodes. It can also enable parallel processing or allow different execution stages to run on different space or terrestrial nodes. A task may therefore create multiple communication relationships that appear, coexist, change, and end as execution progresses. Because satellite motion changes connectivity over time, reachability alone is not enough to determine whether an execution endpoint can support the required communication. This document analyzes the network role in such distributed execution in the space network. It considers how network information affects execution decisions, how those decisions create communication requirements and relationships, when communication over a relationship is ready for use, and how relationships change as execution and connectivity evolve. | |||||||||||||
| draft-zhuang-grow-bmp-enhancement-for-vrf-loc-rib-01.txt | ||||||||||||||
| Enhancement for Monitoring VRF's Loc-RIB | ||||||||||||||
|
BMP Loc-RIB [RFC9069] enforces that the BMP router sets the Peer Address value of a VPN route information to zero, and sets the Peer Distinguisher value of a VPN route information to the route distinguisher or unique locally defined value of the particular instance the Loc-RIB belongs to. This document introduces the option to communicate the Remote VRF Information from which a VPN route was received when reporting that VPN route information with BMP Loc-RIB. | |||||||||||||
| draft-zhuang-grow-monitoring-bgp-parameters-02.txt | ||||||||||||||
| Monitoring BGP Parameters Using BMP | ||||||||||||||
|
The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor BGP [RFC4271] running status, such as BGP peer relationship establishment and termination and route updates. Without BMP, manual query is required if you want to know about BGP running status. This document provides the use cases that the BMP station can get the optional parameters that are supported by the monitored network device and default configure parameters of the monitored network device via BMP. | |||||||||||||
| draft-zhuang-idr-epe-rg-ixp-00.txt | ||||||||||||||
| BGP Egress Peer Engineering (EPE) SID Allocation and Extensions for IXP Route-Server Scenarios | ||||||||||||||
|
BGP Egress Peer Engineering (EPE) defines mechanisms to steer egress traffic towards a specific border router, interface, or peer group using Segment Routing (SR). [RFC9086] specifies BGP-LS extensions to advertise these EPE peer segments. However, in Internet Exchange Point (IXP) deployments where border routers peer with a centralized Route-Server (RS), control plane peerings are completely decoupled from data plane forwarding paths. This document specifies the architecture, specific procedures, and associated BGP-LS TLV application guidelines for allocating and signaling EPE PeerNode and PeerSet SIDs on an egress border router connected to an IXP Route-Server infrastructure, ensuring granular and deterministic egress traffic engineering across IXP fabrics. | |||||||||||||
| draft-zhuang-idr-flowspec-extension-for-ncm-00.txt | ||||||||||||||
| BGP Flow Specification Extensions for Network Congestion Management | ||||||||||||||
|
BGP Flow Specification (FlowSpec) [RFC8955] and [RFC8956] has been proposed to distribute traffic filter policy (traffic filters and actions) via BGP [RFC4271]. Multiple applications have used BGP FlowSpec to distribute traffic filter policy. These applications include the following: mitigation of denial of service (DoS), enabling traffic filtering in BGP/MPLS VPNs, centralized traffic control of router firewall functions, and SFC traffic insertion. Due to its powerful extensibility, FlowSpec can be easily used for network congestion management. This document describes how to use BGP FlowSpec to implement network congestion management. | |||||||||||||
| draft-zhuang-idr-rr-dual-nexthop-00.txt | ||||||||||||||
| BGP Route Reflector Dual-Next-Hop Reflection for Path Protection | ||||||||||||||
|
This document specifies a mechanism where a BGP Route Reflector (RR) reflects a single received BGP route as two distinct routing updates towards a target client. By preserving the original client next-hop in one update and modifying the next-hop to the RR's own address in the second update, the receiving client obtains two parallel paths for the same prefix. This enables the receiving client to implement Load Balancing or Primary-Backup path protection without requiring full-mesh IBGP sessions or BGP Add-Path extensions. | |||||||||||||
| draft-zhuang-ippm-network-measurement-ps-00.txt | ||||||||||||||
| Network Measurement Problem Statement | ||||||||||||||
|
Modern network applications, ranging from artificial intelligence (AI) and machine learning (ML) training to large-scale cloud services, require adaptive and high-performance networks. Network measurement is fundamental to achieving observability, enabling traffic engineering (TE), load balancing, congestion control (CC), resource accounting, and fault diagnosis. However, existing network measurement techniques face significant challenges in accuracy, overhead, scalability, and adaptability, especially in distributed and high-speed environments. This document describes the problems and gaps in current network measurement approaches, including sketch- based measurement, in-band network telemetry (INT), sampling, and probing, with a focus on distributed system scenarios. | |||||||||||||
| draft-zhuang-rtgwg-aidc-gse-architecture-00.txt | ||||||||||||||
| GSE architecture for AIDC | ||||||||||||||
|
This document introduces a Global Scheduling Ethernet (GSE) architecture for data centers used for AI computing. This architecture can minimize the probability of packet forwarding congestion in the network and improve the efficiency of packet interaction. | |||||||||||||
| draft-zollner-scim-group-members-01.txt | ||||||||||||||
| SCIM Group Member Resource Type Extension | ||||||||||||||
|
This document extends the System for Cross-domain Identity Management (SCIM) 2.0 standard by defining a new "GroupMember" top-level resource. Under the existing model defined in [RFC7643], group memberships are represented as values in a multi-valued attribute within a Group resource. This architecture lacks native support for server-side pagination, filtering, or sorting of individual members. In deployments managing large-scale groups (e.g., 100,000 to 1,000,000 members or more), retrieving a Group resource results in massive HTTP response payloads that can exceed 100MB in size. This can lead to service timeouts, memory exhaustion, and network instability, and has led to many major SCIM implementations choosing to not support returning the value of the "members" attribute for Group resources. This extension introduces a flattened resource model that enables group memberships to benefit from pagination and other SCIM protocol features, ensuring interoperability and performance at scale. | |||||||||||||
| draft-zollner-scim-interop-profile-01.txt | ||||||||||||||
| SCIM 2.0 Interoperability Profile | ||||||||||||||
|
This document defines an implementation profile for the System for Cross-domain Identity Management (SCIM) 2.0. In the typical deployment model, an identity provider acting as a SCIM Client provisions and manages identities at multiple downstream service providers, while each service provider (commonly a multi-tenant application serving many customers) accepts provisioning connections from multiple different identity providers. This many-to-many integration model compounds the interoperability challenges arising from the wide range of optional features and implementation variations permitted by the base specification. This profile addresses those challenges by restricting the optional features and protocol variations permitted under the base specification and by establishing normative requirements for a common implementation baseline. | |||||||||||||
| draft-ztop-secdispatch-protocol-00.txt | ||||||||||||||
| Zero Trust Transfer Orchestration Protocol (ZTOP) | ||||||||||||||
|
This document defines the Zero Trust Transfer Orchestration Protocol (ZTOP), a novel Application Layer (OSI Layer 7) protocol for orchestrating cryptographically authenticated, continuously attested peer-to-peer file transfer in Zero Trust Architectures (ZTA). ZTOP operates within a TLS 1.3 transport tunnel and introduces: a hardware-derived cryptographic Peer Identity using HKDF-SHA512 and Ed25519; a 5-layer X.509 certificate chain with custom OID-encoded Zero Trust metadata; a continuous 16-field Heartbeat attestation protocol; a 100-point Adaptive Tamper Resistance Score; a dual-signed 19-field Metadata Exchange Protocol preceding any payload; a 380-byte Cryptographic Execution Manifest (CEM) permanently bound to every transferred file; SHA-256 binary Merkle-tree chunk integrity with immediate per-chunk proof validation; protocol-native static pre-execution behavioral analysis; and a 7-Level non-repudiation Signature Chain. A transfer is considered complete only when all seven cryptographic signatures are present and verified. A Python reference implementation is available at: https://github.com/sripad2020/ztop-research/ | |||||||||||||
| draft-ztsl-secdispatch-protocol-00.txt | ||||||||||||||
| Zero Trust Secure Layer (ZTSL) Protocol Specification with Opcode Framework and Application Binding Layer | ||||||||||||||
|
This document specifies the Zero Trust Secure Layer (ZTSL) protocol, a transport-layer security framework that enforces Zero Trust principles at the protocol level by embedding continuous identity verification, device trust validation, policy-driven communication, and cryptographic session management into every protocol message. ZTSL introduces the First Authentication Needed (FAN) mechanism, Zessions (Zero Trust Sessions), the Device Trust Flag (DTF), the Client Security Routing Profile (CSRP), the Triple Signature Model, the Trust Triangle, Adaptive Protocol Negotiation, and Heartbeat Fingerprint (HBF) synchronization. This document also specifies the ZTSL Opcode Framework, a structured, extensible opcode namespace that encodes every protocol operation as a precisely identified, versioned, and trust-contextualized instruction. Every FAN exchange, Zession state transition, socket operation, signing step, routing decision, heartbeat synchronization, threat event, and recovery action is assigned a unique opcode and transmitted as an opcode-bearing ZTSL frame. The document further specifies the Application Binding Layer (ABL), the transparent shim through which any application interacts with ZTSL via a familiar socket-like API, completely insulated from the underlying trust machinery. | |||||||||||||
| draft-zubov-snif-05.txt | ||||||||||||||
| Deploying Publicly Trusted TLS Servers on Devices Behind NAT Using SNI-based End-to-End TLS Forwarding (SNIF) | ||||||||||||||
|
This document proposes a solution, referred to as SNIF, that provides the means for any Internet-connected device to: * allocate a globally unique anonymous hostname; * obtain and maintain a publicly trusted X.509 certificate issued for the allocated hostname; * accept incoming TLS connections on specific TCP ports of the allocated hostname from any TLS clients that are capable of sending Server Name Indication. The private key associated with the X.509 certificate is securely stored on the TLS terminating device, and is never exposed to any other party at any step of the process. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zubov-snif. Information can be found at https://snif.host. Source for this draft and an issue tracker can be found at https://github.com/vesvault/snif-i-d. | |||||||||||||
| draft-zw-idr-bgp-orf-yang-model-01.txt | ||||||||||||||
| YANG Data Model for BGP Outbound Route Filtering | ||||||||||||||
|
This document defines YANG data models for managing BGP Outbound Route Filter (ORF), including Address Prefix ORF, Covering Prefixes ORF (CP-ORF), and VPN Prefix ORF. | |||||||||||||
| draft-zwg-rtgwg-enhanced-bgp-resilience-02.txt | ||||||||||||||
| Enhanced BGP Resilience | ||||||||||||||
|
According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. RFC7606 revises the error handling procedures for a number of existing attributes. The use of the "treat-as-withdraw" and "attribute discard" approaches significantly reduces the likelihood of BGP sessions being reset when receiving malformed BGP update messages, thereby greatly enhancing network stability. However, in practical applications, there are still numerous instances where BGP session oscillations occur due to the receipt of malformed BGP update messages, unrecognized attribute fields, or routing rules generated by a certain BGP AFI/SAFI that affect the forwarding of BGP messages. This document introduces some approaches to enhance the stability of BGP sessions. | |||||||||||||
| draft-zz-scone-rate-advice-rocev2-00.txt | ||||||||||||||
| SCONE-Based Rate Advice for RoCEv2 Networks | ||||||||||||||
|
This document describes the applicable scenarios of the Standard Communication Protocol for Network Elements (SCONE) in RoCEv2 networks. SCONE defines a mechanism that enables network elements on the forwarding path to deliver throughput guidance to RoCEv2 endpoints. This document further specifies the method for carrying Rate Advice in RoCEv2 packets. The Rate Advice is generated by network nodes (e.g., switches), which can be either rate limits defined by network policies or quantitative rate adjustment recommendations derived from network status information. This document specifies the packet format for Rate Advice and the calculation method for the advised rate. | |||||||||||||
| draft-zzhang-bess-mcast-in-evpn-signaled-l3vpn-02.txt | ||||||||||||||
| Multicast in L3VPNs Signaled by EVPN SAFI | ||||||||||||||
|
RFC9136 specifies an EVPN SAFI Type-5 route that can be used to signal L3VPNs. This document specifies procedures for multicast in such an L3VPN. | |||||||||||||
| draft-zzhang-fann-router-info-00.txt | ||||||||||||||
| Advertising Router Information | ||||||||||||||
|
This document specifies a generic mechanism for a router to advertise some information to its neighbors. One use case of this mechanism is to advertise link/path information so that a receiving router can better react to network changes. | |||||||||||||