Run date 2026-08-21 · Window: 2026-08-19 to 2026-08-21 (last 48 hours) · All groups (100% coverage)
No newly published RFCs in the window. The ietf-announce archive shows no RFC / BCP / STD announcements dated after 2026-08-14; there are no newly published RFCs within the last-48-hours window (2026-08-19 to 2026-08-21).
BGP Flow Specification (FlowSpec), defined in RFC 8955 and RFC 8956, distributes FlowSpec NLRI to clients to mitigate (distributed) denial-of-service attacks and to filter traffic in the context of a BGP/MPLS VPN service. More recently, traffic-steering applications in SR-MPLS and SRv6 contexts have also relied on FlowSpec. This document specifies how BGP FlowSpec can be used to steer matching packets into an SR Policy, extending FlowSpec's redirect capabilities to segment-routing forwarding paths.
By its name, this individual draft appears to define composite signatures for use in the Secure Shell (SSH) protocol maintenance work (sshm) — likely combining a post-quantum signature scheme with a traditional one so that SSH authentication stays secure if either component holds. The exact algorithms and wire formats are not confirmed here; this summary is approximate and will be grounded from the official abstract on the next run.
The short name (“mws”) does not clearly indicate the subject of this individual submission, so its topic cannot be reliably determined from the name alone. A precise description will be provided on the next run once the official abstract can be read.
Specifies the Extensible Authentication Protocol using Privacy Pass token (EAP-PPT) Version 1. The protocol carries a Privacy Pass token for client authentication within EAP as defined in RFC 3748. Privacy Pass (RFC 9576) is a privacy-preserving authentication mechanism used for authorization, letting a client authenticate without exposing correlatable identity information to the authenticator.
By its name, this individual draft probably concerns IETF decision-making — how the IETF reaches and records decisions (for example rough consensus, appeals, or related process). The specifics are not confirmed; this is an approximate summary pending the official abstract.
Describes a protocol by which on-path network elements can give endpoints their perspective on the maximum achievable throughput for QUIC flows. The signal lets endpoints adapt their sending behavior to network conditions without the network modifying or terminating the QUIC connection, supporting rate adaptation on congested or capacity-limited links.
Part of Fred Templin’s AERO/OMNI family of drafts in the 6man space. By its name it likely specifies extensions (“amen”) to the Asymmetric Extended Route Optimization (AERO) and Overlay Multilink Network Interface (OMNI) architectures for IPv6. Both revision -11 and -12 were announced on the same day. Approximate; to be grounded from the abstract on the next run.
By its name, a new individual draft on HTTP integrity for cached content — probably defining how the integrity of HTTP responses served from caches can be verified. Details are unconfirmed; approximate summary pending the official abstract.
By its name, a new individual draft on “coverage attestation” — probably a mechanism to attest, in a verifiable way, to some form of coverage (for example test, policy, or telemetry coverage). The subject is not confirmed; approximate summary pending the abstract.
A new individual DNS Operations (dnsop) draft. By its name it likely defines a “domain set” concept — a way to group or reference multiple DNS domains together for operational purposes. Approximate; the abstract will be read on the next run.
Describes SRv6 addressing for the NEXT-CSID (compressed SID) locator format. It introduces the 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. (Grounded in the abstract of the pre-adoption individual draft draft-horn-srv6ops-srv6addressing, the same work.)
Relates to SCITT (Supply Chain Integrity, Transparency and Trust). By its name it likely specifies how “disclosure evidence” is represented or conveyed within a SCITT transparency service. Approximate summary pending the official abstract.
Segment Routing is a source-routing paradigm in which the ingress node explicitly indicates the forwarding path for packets. 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 carry an identifier for a segment list, enabling individual segment lists to be referenced, correlated, and managed.
Part of the emerging “agentproto” (agent communication protocols) work. By its name it likely enumerates requirements for sessions established between AI agents. The specifics are unconfirmed; approximate summary pending the abstract.
The short name (“aadp”) is not self-explanatory, so the subject cannot be reliably determined from the name alone. Both the initial -00 (Aug 19) and revision -01 (Aug 20) were announced within the window. Approximate; to be grounded from the official abstract on the next run.
By its name, this individual draft defines a protocol (“tttps”) associated with “helm”. The subject cannot be reliably inferred from the name. Approximate; the official abstract is pending.
An OAuth-related individual draft. By its name it likely addresses attestation-based authorization for native applications — using client or device attestation to strengthen OAuth authorization flows on native apps. Approximate; the abstract will be read on the next run.
A new individual draft in the GROW/RPKI routing-security space. By its name it likely concerns the RPKI and “DOA” (possibly a delegation-of-authority or object-status mechanism) for routing operations. The subject is unconfirmed; approximate summary pending the abstract.
By its name, an individual draft about “contra tags.” The precise subject cannot be reliably determined from the name. Approximate; the official abstract is pending.
By its name this individual draft likely relates to MKA (the MACsec Key Agreement protocol); the “stems” component is unclear and may denote a specific extension to key-agreement handling. Approximate; the abstract will be read on the next run.
Presents a YANG module file-name convention. It extends the current revision-date-based file name with the YANG semantic-version extension, which allows an informative semantic version to be associated with a particular YANG module revision. The document updates RFC 6020, RFC 7950, and RFC 8407.
By its name, an individual draft proposing reforms to the IETF/RFC publication process — likely discussing changes to how documents are published or the workflow that produces RFCs. Approximate; specifics pending the official abstract.
A new DNS Operations individual draft on EDNS Client Subnet (ECS). By its name it likely proposes an opt-in model for ECS, letting clients or resolvers explicitly consent before subnet information is shared with authoritative servers, for privacy. Approximate; the abstract is pending.
By its name, this OPSAWG working-group draft likely defines IPFIX Information Elements to export Path Segment identifiers (as used with SR-MPLS/SRv6 path segments for measurement), letting exporters report the path segment associated with observed flows. Approximate; the official abstract will be grounded on the next run.
A new individual draft on scheduling workloads among AI agents. By its name it likely addresses how agent workloads are scheduled or distributed. The subject is unconfirmed; approximate summary pending the abstract.
A SIDROPS-area individual draft on post-quantum cryptography for the RPKI. By its name it likely discusses migrating RPKI signatures and objects to PQC algorithms. Approximate; the abstract is pending.
The short name (“aadp”) is not self-explanatory, so the subject cannot be reliably determined from the name alone. Both the initial -00 (Aug 19) and revision -01 (Aug 20) were announced within the window. Approximate; to be grounded from the official abstract on the next run.
The short name (“ccs”) does not clearly indicate the subject of this individual submission, so its topic cannot be reliably determined from the name alone. Approximate; the official abstract will be read on the next run.
A new individual Agent-to-Agent (A2A) draft. By its name it likely uses WebFinger to discover agent endpoints or metadata. Approximate; the abstract is pending.
A new individual Agent-to-Agent (A2A) draft. By its name it likely uses DNS-SD (DNS-Based Service Discovery) to discover agents or agent services. Approximate; the abstract is pending.
A new individual draft on identity certificates (“aic”). By its name it likely defines a certificate format or profile for an identity context. Approximate; the subject is unconfirmed pending the abstract.
5G network slicing multiplexes logical networks for multiple customers over shared infrastructure, and user data-plane packets over the RAN and 5G core often use IP transport across many segments. This document describes mapping 5G slices onto IP or Layer 2 transport-network slices when the transport provider is separated from where the 5G network functions run (for example, functions distributed across data centers), so the transport can deliver the requested bandwidth, latency and isolation. The mapping remains transparent as a user device moves across 5G attachment points and session anchors.
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 JWTs 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 given for MCP, A2A and generic HTTP APIs, motivated by a survey of roughly 2,000 MCP servers that all lacked authentication.
By its name, this IDR working-group draft likely defines BGP-LS (Link-State) extensions describing a “BGP-only fabric” — advertising the topology and link-state of a fabric that runs BGP as its sole routing protocol. Approximate; the official abstract will be grounded on the next run.
The name (“humia”) does not clearly indicate the subject of this new individual protocol draft, so its topic cannot be reliably determined from the name. Approximate; the abstract is pending.
A new individual draft touching AI interoperability and “execution finality.” By its name it likely concerns guaranteeing the finality of executed actions across interoperating AI systems. The subject is unconfirmed; approximate summary pending the abstract.
By its name, an individual draft defining an audit trail for AI agents — recording agent actions for accountability and traceability. Approximate; the official abstract is pending.
Associated with NMRG (the IRTF Network Management Research Group) topics, though submitted as an individual draft. By its name it likely proposes an architecture combining AI agents with a Network Digital Twin (NDT). Approximate; the abstract will be read on the next run.
By its name, this BFD working-group draft is a “-bis” revision of RFC 5883 (Bidirectional Forwarding Detection for Multihop Paths). It likely updates or replaces RFC 5883 with clarifications and corrections for running BFD over multihop paths. Approximate; the official abstract will be grounded on the next run.