Reports experiments with post-quantum signature algorithms and analyzes migration approaches for the Resource Public Key Infrastructure (RPKI). It compares classical, post-quantum, and composite signature candidates; generates and validates RPKI-profiled certificate, CRL, manifest, and ROA test objects; and evaluates Parallel Publication and Mixed Tree migration structures, plus the effect of larger objects on rsync, RRDP, and Erik Synchronization. The results identify implementation, interoperability, repository-distribution, and operational questions to resolve before a production algorithm profile or transition procedure can be specified. Informational: it does not update RFC 7935 or RFC 6916, define a new RPKI algorithm profile, or authorize use of the evaluated algorithms.
Defines the Agent Action Decision Protocol (AADP), a two-phase wire contract between a Policy Decision Point (PDP) that authorizes agent actions and the Policy Enforcement Points (PEPs) that perform them. Where most agent-security work focuses on identity, AADP addresses whether a specific proposed action, with specific argument values, may be performed now and under what conditions. It specifies verdicts with machine-readable reasons, obligations that fail closed, budget reservation semantics, approval and idempotency behavior, evidence requirements, and evaluation invariants any conformant decision point must observe, including that an irreversible action is never executed autonomously. The protocol is transport-agnostic so decision and enforcement points can be implemented independently.
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 verification outcomes (pass, fail, unknown), and normative requirements for implementations.
Profiles WebFinger for the Agent2Agent (A2A) protocol. A2A normally retrieves an Agent Card from a fixed well-known URI, which resolves exactly one agent per origin and presumes the client already holds a URL. Here an agent is named by an "acct" URI (agent@domain), and resolving that name over WebFinger yields a link to the Agent Card of the endpoint serving the agent, whether its own endpoint or a fronting gateway. The profile introduces no new link relation, media type, or registry, composing three deployed standards and stating how they fit together.
Profiles DNS-Based Service Discovery (DNS-SD) over Multicast DNS (mDNS) so that Agent2Agent (A2A) agents on the same host or local network can find each other, which the base A2A protocol does not address. It defines the "a2a" service type, the TXT record keys used with it, the discovery procedure, and a security model in which discovery results are treated as hints whose trust is established by Agent Card verification rather than by the discovery channel. It also requests IANA registration of the "a2a" service name.
Defines the AI Agent Identity Certificate (AIC) extension for X.509 v3 certificates. The extension binds an AI agent's cryptographic identity to a natural person (principal), providing cryptographic evidence that can support attribution of AI-autonomous actions to that principal. It separates cryptographic delegation from authorization semantics: AIC defines the agent-to-principal binding while capability and policy semantics are defined externally. The extension carries agent identity fields, principal identification, capability declarations, authorization boundary constraints, and delegation evidence with replay protection; a companion PrincipalAuthorization extension provides principal-side grants. The document specifies the ASN.1 module, OID registration, field semantics, delegation model, and extensibility framework.
Describes mapping of end-to-end 5G network slices to Transport Network (TN) slices. In 5G, user data-plane packets over the RAN and Core use IP across many segments; when end-to-end slices consume network resources they must be mapped to TN slices providing the required bandwidth, latency, and isolation. This document uses the UDP source port of the GTP-U bearer to carry the mapping when the TN slice provider is separated by an attachment circuit from the networks hosting the 5G functions (for example, functions distributed across data centers). The mapping is supported transparently as a user device moves across 5G attachment points and session anchors.
Specifies the Agent Identity Protocol (AIP) for verifiable, delegable identity in AI agent systems. AIP introduces Invocation-Bound Capability Tokens (IBCTs) that bind identity, authorization, scope constraints, and provenance into a single cryptographic artifact. Two modes are defined: a compact JWT mode with Ed25519 signatures for single-hop interactions and a chained Biscuit-token mode with append-only blocks and Datalog policy evaluation for multi-hop delegation. Bindings are given for the Model Context Protocol (MCP), Agent-to-Agent (A2A), and generic HTTP APIs. This revision adds a normative verification algorithm, a canonical policy encoding for chained mode, composition with workload identity systems such as SPIFFE, and a mapping against cross-organization delegation requirements.
Some networks use BGP as their only routing protocol, yet operators still want the detailed topology view normally available from link-state protocols. This document defines extensions to the BGP Link-State (BGP-LS) address family and the procedures for advertising topology information in a BGP-only network.
Defines HUMIA, 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 describing conditions for public-content access, permitted AI usage purposes, attribution requirements, and optional usage reporting. HUMIA does not replace the Robots Exclusion Protocol, authentication, authorization, licensing, or access control; it is an additional cooperation layer. The specification also introduces an experimental discovery record in robots.txt directing HUMIA-aware agents to the policy's canonical location.
By its name, this individual draft appears to address execution finality in the context of AI system interoperability, probably describing how the outcome of an executed action is made final and consistently interpreted across interoperating AI agents or services. The official abstract page was not reachable on this run, so this summary is approximate and specific mechanisms, data formats, and guarantees are not stated here; it will be grounded from the document's abstract on the next run.
By its name, this individual draft probably defines an audit-trail mechanism for AI agents, likely covering how agent actions are recorded, structured, and later verified for accountability. The official abstract page returned a 404 on this run, so this description is approximate and does not assert specific record formats, signing schemes, or procedures; it will be grounded from the document's abstract on the next run.
Describes an architecture for AI-driven network operations that combines a Network Digital Twin (NDT) with Agentic AI. An NDT provides a network emulation tool for scenario planning, impact analysis, and change management, while Agentic AI enables dynamic goal-driven execution, adaptive behavior, and closed-loop autonomy. Together with network management they let organizations assess and refine optimization strategies in a risk-free environment. The document shows how these components work together and provides a cookbook of existing technologies to realize intent-based network management.
Describes the use of the Bidirectional Forwarding Detection (BFD) protocol over multihop paths, including unidirectional links. This document obsoletes RFC 5883.
Specifies a procedure for distributing BGP Link-State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems. It introduces a new NLRI type for Inter-AS Links and three new TLVs for the BGP-LS Inter-AS Link descriptor, enabling SDN controllers to retrieve topology information across multiple AS domains. These extensions let operators collect inter-domain interconnect information and automatically compute the end-to-end network topology using information provided by BGP-LS.
Describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. This document obsoletes RFC 5882.
Network platforms use telemetry such as YANG-Push to continuously stream counters and state information; this document defines metadata ensuring the collected data can be interpreted correctly. It specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest), defined at the network level (e.g., network controllers) to encompass several platforms. The manifest must be streamed and stored alongside the data so it remains fully exploitable by data scientists and tools. It also augments the YANG-Push model to include the actual collection period when it differs from the configured one.
By its name, this AIPREF working group draft probably defines how AI-usage preferences (the vocabulary developed in the companion draft-ietf-aipref-vocab) are attached to or associated with digital assets, likely covering discovery and binding mechanisms for those preferences. The official abstract page returned a 404 on this run, so this summary is approximate and does not state the specific attachment methods; it will be grounded from the document's abstract on the next run.
Defines a vocabulary for expressing preferences about how digital assets are used by automated processing systems. The vocabulary allows declaring restrictions or permissions for the use of digital assets by such systems.
HTTP/3 clients commonly coalesce an existing QUIC connection for requests to a second origin when the TLS certificate is also valid for it, even though the two origins may route to 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 reach an unintended backend, potentially enabling cross-tenant data leakage, authentication bypass, and response-queue interference analogous to request smuggling. It defines the mechanism, the attacker model, distinctions from related QUIC exposures, and normative operational guidance.
HTTP/3 clients commonly coalesce an existing QUIC connection for requests to a second origin when the TLS certificate is also valid for it, even though the two origins may route to 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 reach an unintended backend, potentially enabling cross-tenant data leakage, authentication bypass, and response-queue interference analogous to request smuggling. It defines the mechanism, the attacker model, distinctions from related QUIC exposures, and normative operational guidance.
Describes procedures for performance measurement in SRv6 networks using the Simple Two-Way Active Measurement Protocol (STAMP) from RFC 8762, with the optional extensions of RFC 8972 and augmentations of RFC 9503. Segment Routing steers packets via source routing and applies to both MPLS and IPv6 data planes; here the procedures cover links and SRv6 paths (segment lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths) as well as Layer-3 and Layer-2 services carried over those SRv6 paths.
Describes procedures for performance measurement in SR-MPLS networks using the Simple Two-Way Active Measurement Protocol (STAMP) from RFC 8762, with the optional extensions of RFC 8972 and augmentations of RFC 9503. The procedures cover SR-MPLS paths (segment lists of SR-MPLS Policies, SR-MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm paths) as well as Layer-3 and Layer-2 services carried over those SR-MPLS paths.
States that the Automatic Extended Route Optimization (AERO) and Overlay Multilink Network (OMNI) Interface functional specifications have reached a maturity ready for advancement in the RFC publication process. Updates to the base specifications are documented in this first amendment, with any additional future amendments as necessary.
Defines a base profile of S/MIME for use with the US Commercial National Security Algorithm (CNSA) 2.0 Suite, a US Government advisory outlining quantum-resistant cryptographic algorithm policy for national security applications. The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME, and is also appropriate for other US Government systems processing high-value information. The memo is not an IETF standard and has not been shown to have IETF consensus; it is published for use by developers and operators of such deployments.
Describes a protocol for identifying automated traffic using HTTP Message Signatures, allowing automated HTTP clients to cryptographically sign outbound requests so servers can 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.
By its name, this NMOP working group draft probably defines a YANG data model for network incident management, likely covering how incidents are represented, reported, and tracked for network operations and management automation. The official abstract page returned a 404 on this run, so this summary is approximate and does not state the model's specific structure or operations; it will be grounded from the document's abstract on the next run.
DNS Service Discovery lets hosts discover and advertise services on an IP network via Multicast DNS (mDNS) or DNS, with advertising via the 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.
Describes how to proxy Ethernet frames in HTTP. Similar to IP proxying in HTTP but operating at Layer 2 instead of Layer 3, it defines a protocol that lets an HTTP client create a tunnel to exchange Layer-2 Ethernet frames through an HTTP server that has an attached physical or virtual Ethernet segment.
An intentionally incomplete design note defining 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.
Network platforms use telemetry such as YANG-Push to continuously stream counters and state information; this document defines metadata ensuring the collected data can be interpreted correctly. It specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest), defined at the network level (e.g., network controllers) to encompass several platforms. The manifest must be streamed and stored alongside the data so it remains fully exploitable by data scientists and tools. It also augments the YANG-Push model to include the actual collection period when it differs from the configured one.
Segment Routing (SR) is a source-routing paradigm in which the ingress node explicitly indicates the forwarding path, and 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.
HTTP/3 clients commonly coalesce an existing QUIC connection for requests to a second origin when the TLS certificate is also valid for it, even though the two origins may route to 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 reach an unintended backend, potentially enabling cross-tenant data leakage, authentication bypass, and response-queue interference analogous to request smuggling. It defines the mechanism, the attacker model, distinctions from related QUIC exposures, and normative operational guidance.
Specifies an RTP payload format for a video signal encoded with JPEG XS (ISO/IEC 21122), a low-latency, low-complexity video coding system whose use keeps encoding-decoding latency to a fraction of a video frame. It is a necessary revision of RFC 9134 to support new features of the third edition of JPEG XS, most notably provisions for the TDC coding mode. It obsoletes RFC 9134 while keeping existing compliant implementations valid, and it consolidates the errata of RFC 9134 with clarifications for implementers and users.
Audit receipts for automated data access attest to what a gateway recorded but leave two questions open: what was changed in the data before disclosure, and whether a set of receipts is complete against the source's own accounting. This document defines two evidence structures: Transformation Evidence, a per-disclosure statement of which classes of values were transformed and how (carrying counts and class names but never values); and Coverage Reconciliation, a procedure and result comparing a source's activity counters against a receipt set over a time window. The reconciliation result distinguishes matched, unreceipted, unobserved, excluded, and indeterminate cases rather than a bare pass. Both are designed to be registered as Signed Statements on a SCITT Transparency Service.
Compositing the post-quantum ML-DSA signature with traditional signature algorithms protects against potential breaks or critical bugs in ML-DSA or its implementation. This document specifies how such a composite signature can be formed using ML-DSA together with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide authentication in TLS 1.3, including use in certificates.
MPLS Network Action (MNA) indicates actions for Label Switched Paths and/or MPLS packets and transfers the data needed for those actions. This document defines MNA encodings for MPLS performance measurement with the alternate-marking method, performing flow-based packet loss, delay, and jitter measurements on MPLS live traffic.
Describes applying the mechanism for discovering In-situ OAM (IOAM) capabilities from RFC 9359 ("Echo Request/Reply for Enabled In Situ OAM Capabilities") in IPv6 networks. IPv6 Node IOAM Query functionality uses ICMPv6 Query messages, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and decapsulating node.
Specifies a mechanism to improve network path distribution and host receive-queue load distribution for IPsec traffic using ESP in UDP encapsulation. Using the per-resource Child SA mechanism of RFC 9611, peers negotiate multiple Child SAs each bound to a distinct UDP source port. The resulting source-port entropy lets network devices spread per-resource traffic across equal-cost multipaths (ECMP) and lets the host NIC steer each flow to a distinct receive queue via receive-side scaling (RSS), supporting efficient per-CPU IPsec processing. It specifies the IKEv2 negotiation, NAT-traversal behavior, and operational requirements.
For the IPv6 transition, IPv6-only is the final stage where only IPv6 is used for transport while global reachability is maintained for both IPv6 and IPv4 services. This document introduces a framework for a multi-domain IPv6-only underlay network from the network provider's perspective, proposing stateless address mapping as the basis for carrying IPv4 service data in a multi-domain IPv6-only environment (IPv4-as-a-Service). It describes the stateless IPv4/IPv6 mapping methodology, device behaviors, options for IPv6 mapping-prefix allocation, and security considerations, aiming to leverage or remain compatible with existing IPv6-only technologies rather than replace them.