Standards Weekly · 2026-08-30

Window: 2026-08-23 ~ 2026-08-30 (last 7 days)
Sources: IETF datatracker, RFC Editor, IEEE SA, W3C, OASIS, 3GPP, ITU-T, CCSA, ETSI, etc.
Methodology: draft counts are based on last-modified time and include revisions; page-scraped items are marked as needing verification.

1. Overview

Metric	Count
IETF draft movements in window	352
of which WG drafts	147
of which individual drafts	205
Newly published RFCs	20
Agent-topic hits	138
Pending manual verification	1

The first three are full-window counts (overall IETF output); “agent-topic hits” is the keyword-filtered subset. Do not divide one by the other.

2. Updates by SDO

SDO	Items
IETF	107
IEEE	6
W3C	5
OASIS	4
CNCF	4
GSMA	3
APNIC	3
RIPE	3
3GPP	3

3. Keyword Hit Distribution

Keyword	Hits
agent	37
agents	18
capability	8
delegation	8
mcp	8
discovery	7
agentic	7
attestation	5
a2a	4
intent	4
gateway	3
autonomous agent	2
multi-agent	2
agentic ai	2
tool use	2

4. IETF Working Group Activity (all drafts in window)

Working Group	Draft updates
netconf	8
idr	8
teas	7
pce	7
intarea	7
opsawg	7
mpls	6
netmod	5
regext	4
spring	4
v6ops	4
lamps	4
ippm	3
pim	3
mlcodec	3

Reflects actual weekly output intensity of each IETF WG, regardless of agent topics.

5. Working Groups with Most Agent-Related Hits

Working Group	Hit items
intarea	1

6. Agent-Related IETF Drafts

• Contestability Bindings for Authorized Agent Actions
  • Draft: draft-pinto-agent-authz-contestability | WG: individual | Updated: 2026-08-29 | Hits: agent
  • datatracker ↗
  • Abstract: 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 digest 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.
• 6G-Era Privacy-Preserving, Anti-Harassment and Spam-Resistant Communication for Map-Based Business Discovery and AI-Native Telecommunication Using Query-Scoped Communication Handles
  • Draft: draft-das-6g-query-scoped-communication-handles | WG: individual | Updated: 2026-08-29 | Hits: agent、gateway、capability、discovery
  • datatracker ↗
  • Abstract: 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. 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.
• Transitive Attestation for Sovereign Workloads: A WIMSE Profile
  • Draft: draft-mw-wimse-transitive-attestation | WG: individual | Updated: 2026-08-29 | Hits: agent、agents、attestation
  • datatracker ↗
  • Abstract: This document defines a WIMSE Profile for Transitive Attestation within the Workload Identity in Multi-Service Environments (WIMSE) framework. It addresses the critical problem of Identity Portability, where software credentials (e.g., bearer tokens or keys) can be misappropriated and used from unauthorized environments—a risk amplified by the emergence of autonomous AI Agents that may move across jurisdictions or be hijacked via prompt injection attacks. By providing a standardized Identity Conveyance mechanism, this profile cryptographically binds software workloads to their local execution environment (“Proof of Residency”) through a transitive chain of trust. This chain consumes Evidence from the underlying platform—supporting both high-assurance RATS-based profiles (e.g., [[!I-D.lkspa-wimse-verifiable-geo-fence]]) for residency verification and standard Workload Identity Agents for basic co-location proofs—to ensure that an identity is only valid when used from a verified, integral, or geographically compliant host. The integrity and hardware-rooted security of the Workload Identity Agent itself is considered out-of-scope for this document and is addressed in the Verifiable Geofencing profile [[!I-D.lkspa- wimse-verifiable-geo-fence]].
• Execution Context Tokens for Distributed Agentic Workflows
  • Draft: draft-nennemann-wimse-ect | WG: individual | Updated: 2026-08-29 | Hits: agentic
  • datatracker ↗
  • Abstract: This document defines Execution Context Tokens (ECTs), a JWT-based extension to the WIMSE architecture that records task execution across distributed agentic workflows. Each ECT is a signed record of a single task, linked to predecessor tasks through a directed acyclic graph (DAG). ECTs reuse the WIMSE signing model and are transported in a new Execution-Context HTTP header field alongside existing WIMSE identity headers.
• Contextual Agent Authorization Mesh (CAAM)
  • Draft: draft-barney-caam | WG: individual | Updated: 2026-08-29 | Hits: agent、a2a、discovery、intent、delegation、attestation
  • datatracker ↗
  • Abstract: This document specifies the Contextual Agent Authorization Mesh (CAAM), an authorization profile composable with the Agent Registration and Discovery Protocol (ARDP) I-D.pioli-agent-discovery and other discovery mechanisms. CAAM defines the Post-Discovery Authorization Handshake: the runtime authorization layer that governs agent behavior after an agent has been discovered through ARDP but before it is permitted to execute tool calls or delegate authority. CAAM provides a sidecar-based authorization mediator for enforcing Relationship-Based Access Control (ReBAC), purpose-bound delegation, and cryptographically verifiable intent propagation in Human-to-Agent (H2A) and Agent-to-Agent (A2A) flows. It bridges identity provenance frameworks — the Interoperability Profiling for Secure Identity in the Enterprise (IPSIE) IPSIE and the Secure Production Identity Framework for Everyone (SPIFFE) SPIFFE — with the ARDP control plane, leveraging OpenID XAA for coarse-grained delegation, a Knowledge Graph for real-time relationship inference, and the Remote ATtestation procedureS (RATS) architecture RFC9334 for cryptographically verifiable attestation of agent execution environments. The Session Context Object (SCO) defined herein is encoded as a JSON Web Token (JWT) RFC7519 or a CBOR Web Token (CWT) RFC8392, and carries a new “ctx” (Contextual Assertion) claim that binds the agent’s delegated authority to a specific purpose, session, and trust chain.
• Verifiable Agent Conversation Records
  • Draft: draft-birkholz-verifiable-agent-conversations | WG: individual | Updated: 2026-08-29 | Hits: agent、agents、autonomous agent
  • datatracker ↗
  • Abstract: 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.
• SAIP: Signed Agent Identity Protocol
  • Draft: draft-jovancevic-saip | WG: individual | Updated: 2026-08-29 | Hits: agent、agents、discovery、delegation、attestation
  • datatracker ↗
  • Abstract: 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.
• Verifiable Identity Claims and Delegation Model (VICDM)
  • Draft: draft-jovancevic-vicdm | WG: individual | Updated: 2026-08-29 | Hits: agent、delegation
  • datatracker ↗
  • Abstract: 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].
• Verifiable Data Access Contract (VDAC)
  • Draft: draft-jovancevic-vdac | WG: individual | Updated: 2026-08-29 | Hits: agent、delegation
  • datatracker ↗
  • Abstract: This document specifies the Verifiable Data Access Contract (VDAC), a protocol for cryptographically verifiable bilateral agreement between a content publisher and an automated agent regarding the terms of programmatic data access. VDAC defines the mechanism by which a site issues an access offer, an agent accepts that offer, both parties sign the resulting contract, and per-request references bind individual interactions to agreed terms. VDAC is the protocol-layer realization of the bilateral commitment principle introduced in Section 6.6 of the Verifiable Identity Claims and Delegation Model [VICDM] and operates as a companion specification to the Signed Agent Identity Protocol [SAIP]. This document defines mechanism, not content: VDAC verifies the existence and integrity of an agreement; the substance of what is agreed remains entirely between the contracting parties. VDAC also defines an append-only contract history. Changes to the recorded state of a Contract are recorded as signed change records and associated immutable snapshots; the original Contract Document is never modified.
• An Agent Action Capsule Profile for SCITT
  • Draft: draft-mih-scitt-agent-action-capsule | WG: individual | Updated: 2026-08-29 | Hits: agent
  • datatracker ↗
  • Abstract: 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.
• Architectural Requirements for Supporting AI Agents on the Internet
  • Draft: draft-daniel-ai-agent-internet-architecture | WG: individual | Updated: 2026-08-29 | Hits: agent、agents、capability、discovery、intent、delegation
  • datatracker ↗
  • Abstract: 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.
• Agent-to-Agent Trust, Identity, and Verifiable Provenance
  • Draft: draft-tonyai-a2a-trust | WG: individual | Updated: 2026-08-28 | Hits: agent、agents、multi-agent、a2a
  • datatracker ↗
  • Abstract: 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.
• Cedulon: An Audit Layer for Agent-to-Agent Commerce
  • Draft: draft-dogru-cedulon | WG: individual | Updated: 2026-08-28 | Hits: agent
  • datatracker ↗
  • Abstract: This document defines the Cedulon Protocol, an audit layer for agent- to-agent commerce. Payment rails such as HTTP 402 flows (x402) and mandate protocols (AP2) already move value, and a mandate protocol can already refuse a spend before it happens and return signed receipts. What they do not, by themselves, give a party that is neither payer nor rail operator is a retrievable record of that decision and a signed spend receipt that reconciles against an authenticated extract of the rail. Cedulon specifies a Trade Manifest (signed offer before payment), a Policy Decision Point with default deny, a Spend Receipt (COSE/CWT claim set after a gated payment), epoch checkpoints, and rail-extract reconciliation. The reconciliation shows that no settlement on the extract lacks a receipt and no settled receipt is absent from the extract. That result is unconditional only when the verifier pins the rail key out of band and states the period under audit; otherwise the document requires it to be reported as conditional. Checkpoints carry the suppression guarantee, so the document profiles the checkpoint as a Signed Statement, gives the verification algorithm a step that consumes the witness receipts returned for checkpoints, names what a witness holding a checkpoint the presented chain omits reports, brings equivocation within reach by comparing recorded copies against the presented chain, and states how checkpoint totals may be withheld without withholding the fact that they were. No signed object is attested by a key it carries itself, a signature checked against such a key where no key is held establishes internal consistency and attests nothing, and a presented Trade Manifest must be bound both to the receipts that name it and to the terms those receipts claim. The document also names a threat no adversary causes, a settlement recorded on a rail with no receipt behind it, and defines a Dispute Evidence Bundle (evidence, not an award) and optional SCITT anchoring. The encodings earlier revisions called canonical are defined, and the exact input to every hash-valued field is stated, so that an independent verifier can be written from the text alone. The account and the rail under audit are part of the declared scope on the terms the period already had, no settlement finding is read out of an extract the pinned rail key refused, and the witness receipt has a stated wire form and a registered media type. This revision widens one requirement: a report names the account, rail and window it was computed over in every structure an implementation returns for that audit, not only in the printed report and the finding object, so that no returned result can be read as a statement about settlement paths it never looked at. Cedulon is not a competitor to x402 or AP2; it sits above them.
• Multi-Source Corroboration for AI Agent Discovery
  • Draft: draft-chandra-agent-registry-corroboration | WG: individual | Updated: 2026-08-28 | Hits: agent、agents、catalog、discovery
  • datatracker ↗
  • Abstract: 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.
• tool_use Is Not invoke(): Binding Execution-Finality to Claude, ChatGPT, and MCP
  • Draft: draft-das-agentic-tool-binding | WG: individual | Updated: 2026-08-28 | Hits: agent、agentic、mcp、capability
  • datatracker ↗
  • Abstract: 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. If the block is treated as a capability, prompt-injected mail, a poisoned retrieval, or a stolen enterprise seat becomes an external act with a 200 from the tool. 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. The implementation target is a middleware function that a host loop can call without changing the model vendor. tool_use is not invoke().
• Out-of-Path Measurement Methodology for Agent-Initiated Payment Rails
  • Draft: draft-blake-bmwg-agent-payment-measurement | WG: individual | Updated: 2026-08-28 | Hits: agent
  • datatracker ↗
  • Abstract: 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.
• Network Digital Twin and Agentic AI based Architecture for AI-driven Network Operations
  • Draft: draft-wmz-nmrg-agent-ndt-arch | WG: individual | Updated: 2026-08-28 | Hits: agent、agentic、agentic ai、intent
  • datatracker ↗
  • Abstract: 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.
• Agent Registration and Discovery Protocol (ARDP)
  • Draft: draft-pioli-agent-discovery | WG: individual | Updated: 2026-08-28 | Hits: agent、agents、mcp、a2a、capability、discovery
  • datatracker ↗
  • Abstract: This document specifies the Agent Registration and Discovery Protocol (ARDP), a lightweight protocol for registering, discovering, and reaching autonomous software agents in distributed and federated environments. ARDP provides stable agent identities, dynamic endpoint resolution, capability advertisement (including protocol selection among MCP, A2A, HTTP, and gRPC), minimal presence signaling, and a security-first discovery control plane. ARDP is transport-agnostic and complementary to existing agent interaction protocols.
• A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments
  • Draft: draft-das-payment-execution-finality | WG: individual | Updated: 2026-08-28 | Hits: agent、agentic
  • datatracker ↗
  • Abstract: 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.
• The Missing Execution-Finality Protocol Layer of the Internet
  • Draft: draft-das-execution-finality-protocol-layer | WG: individual | Updated: 2026-08-28 | Hits: agent、agents
  • datatracker ↗
  • Abstract: Internet protocols provide mature mechanisms for transporting, encrypting, authenticating, authorizing access to, delegating, and recording digital information. These mechanisms remain essential. A separate question becomes increasingly important as AI agents, autonomous services, programmable networks, cloud workloads, payment systems, and cyber-physical systems generate consequential operations at machine speed:
• Access Is Not Egress: Precision-Bounded Location Release
  • Draft: draft-das-precision-bounded-egress | WG: individual | Updated: 2026-08-28 | Hits: agent
  • datatracker ↗
  • Abstract: 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 on top of execution finality. 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 sink independently verifies scoped non-bearer authority against the actual outbound payload immediately before release. 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.
• Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch
  • Draft: draft-das-agentic-execution-finality | WG: individual | Updated: 2026-08-28 | Hits: agent、agentic、multi-agent、mcp、tool use、delegation
  • datatracker ↗
  • Abstract: 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 Compromised AI Server Must Not Become a Map of the Enterprise: Non-Joinable Vaults and Output-Release Finality
  • Draft: draft-das-enterprise-ai-output-finality | WG: individual | Updated: 2026-08-28 | Hits: agent、mcp
  • datatracker ↗
  • Abstract: Past cyber theft stole files. Present theft steals live sessions and SaaS tokens. The next theft does not need a dump. A frontier enterprise assistant that can see mail, tickets, code, finance, and memory can join those fragments into a meaning that was never stored as one record, then act. That is enterprise-future mapping: reconstruction of strategy, relationships, and probable next moves, followed by send, write, or tool invoke [DAS-ISOLATION]. IAM, DLP, clean rooms, TEEs, and output filters still answer who may touch a store. They do not answer whether separately lawful fragments may be joined into a new protected meaning, or whether that meaning may leave through Claude, ChatGPT Enterprise, a computer-use agent, or an MCP tool. This profile keeps identity, content, and association under independently controlled vaults, joins them only under a session- bound Reconstruction Authorization Object, seals the Candidate Output, commits a receipt before release authority exists, and completes send, render, store, or invoke only at an Output Release Boundary. Compromise of the model host is not reconstruction. Reconstruction is not release.
• A Setpoint Write Is Not Actuation: Finality for ICS, Grid, and Robot Command
  • Draft: draft-das-ot-actuation-finality | WG: individual | Updated: 2026-08-28 | Hits: agent、gateway
  • datatracker ↗
  • Abstract: 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.
• Stopping AI Hallucinations and Unsafe Acts from Becoming Real-World Consequences (DAS Protocols)
  • Draft: draft-das-protocols-candidate-act-finality | WG: individual | Updated: 2026-08-28 | Hits: agentic、capability
  • datatracker ↗
  • Abstract: 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.
• Execution Finality for Agentic AI: Stopping Unauthorized Tool Calls, Memory Writes, and Real-World Consequences Before They Happen (DAS — Decoupled Authorisation System)
  • Draft: draft-agentic-ai-tool-execution-finality | WG: individual | Updated: 2026-08-28 | Hits: agentic、mcp、tool use、agentic ai
  • datatracker ↗
  • Abstract: 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.
• DHCP Explicit Rate Signaling
  • Draft: draft-ietf-intarea-dhcp-rate-signaling | WG: intarea | Updated: 2026-08-27 | Hits: agent、agents
  • datatracker ↗
  • Abstract: 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.
• An External Verifier Contract for Agent Authorization Decisions
  • Draft: draft-kondoju-evc | WG: individual | Updated: 2026-08-27 | Hits: agent、delegation
  • datatracker ↗
  • Abstract: 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.
• BGP Failure Propagation (BGP-FP) for Enhancing Control-Plane Convergence
  • Draft: draft-li-idr-bgp-failure-propagation-convergence | WG: individual | Updated: 2026-08-27 | Hits: agent、agents、intent
  • datatracker ↗
  • Abstract: 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.
• Agent Trust Enforcement for Autonomous AI Systems
  • Draft: draft-sharif-agent-trust-enforcement | WG: individual | Updated: 2026-08-27 | Hits: agent、agents、llm
  • datatracker ↗
  • Abstract: 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.
• Agent Identity Framework: Trust and Identity for Autonomous AI Agents
  • Draft: draft-sharif-agent-identity-framework | WG: individual | Updated: 2026-08-27 | Hits: agent、agents、autonomous agent、attestation
  • datatracker ↗
  • Abstract: 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.
• Trust Scoring and Identity Verification for Autonomous AI Agent Payment Transactions
  • Draft: draft-sharif-agent-payment-trust | WG: individual | Updated: 2026-08-27 | Hits: agent、agents、mcp、capability
  • datatracker ↗
  • Abstract: 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.
• Cryptographic Attestation for AI Model Lifecycle: From Training Data to Inference Output
  • Draft: draft-sharif-ai-model-lifecycle-attestation | WG: individual | Updated: 2026-08-27 | Hits: agent、mcp、discovery、attestation
  • datatracker ↗
  • Abstract: 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.
• ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server Communication
  • Draft: draft-sharif-attp-agent-trust-transport | WG: individual | Updated: 2026-08-27 | Hits: agent、agents
  • datatracker ↗
  • Abstract: This document specifies ATTP (Agent Trust Transport Protocol), a synchronous request-response protocol for communication between autonomous AI agents and web API servers. ATTP operates as an application-layer protocol over HTTP, adding mandatory cryptographic identity verification, per-message signing, trust-gated access control, and tamper-evident audit trail generation to every agent-server interaction. ATTP defines five protocol-layer headers for requests (X-Agent-Trust, X-Agent-Signature, X-Agent-Nonce, X-Agent-Timestamp, X-ATTP-Version) and three for responses (X-Server-Signature, X-Server-Nonce, X-Server-Timestamp) that carry an Agent Passport (JWT-based identity credential), ECDSA P-256 digital signatures, cryptographic nonces, and timestamps. Server middleware verifies all cryptographic properties before application code executes. ATTP has no insecure mode. Every request MUST carry a valid Agent Passport. Every request body MUST be signed. Every response body MUST be signed. Every interaction MUST be recorded in a hash-chained audit trail. The protocol defines a URL scheme (attp://) and is fully backward-compatible with existing HTTP infrastructure. ATTP is the synchronous counterpart to the Agent Transport Protocol (ATP). ATP handles asynchronous store-and-forward agent delivery; ATTP handles real-time request-response API communication. Both share the same identity model, trust framework, and cryptographic primitives.
• ATTP for Industrial Control Systems: Cryptographic Agent Authentication in SCADA and IoT Environments
  • Draft: draft-sharif-attp-industrial-control-systems | WG: individual | Updated: 2026-08-27 | Hits: agent、gateway
  • datatracker ↗
  • Abstract: 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.
• OpenID Connect Agent Identity Claims for Autonomous AI Agents
  • Draft: draft-sharif-openid-agent-identity | WG: individual | Updated: 2026-08-27 | Hits: agent、agents
  • datatracker ↗
  • Abstract: This specification defines a profile of OpenID Connect Core 1.0 that enables Identity Providers (IdPs) to issue identity tokens for autonomous software agents. It introduces a set of standard claims for representing agent identity, ownership, trust posture, authorised capabilities, and compliance screening status within OpenID Connect ID Tokens. The profile is designed to operate within existing OpenID Connect infrastructure without requiring modifications to the core protocol. It defines how Relying Parties (RPs) validate agent tokens and enforce graduated access controls based on agent trust levels and sanctions screening results.
• Agent Public Key Infrastructure (APKI): Certificate-Based Identity and Trust for Autonomous AI Agents
  • Draft: draft-sharif-apki-agent-pki | WG: individual | Updated: 2026-08-27 | Hits: agent、agents、capability、delegation
  • datatracker ↗
  • Abstract: Autonomous artificial intelligence (AI) agents are increasingly performing actions on the Internet that require verifiable identity: financial transactions, regulated data access, tool invocations, and inter-agent coordination. Traditional Public Key Infrastructure (PKI) based on X.509 certificates was designed for human-operated clients and long-lived servers. It lacks primitives for graduated trust scoring, capability constraints, delegation chains, model provenance, and the ephemeral lifecycles characteristic of AI agents. This document defines Agent Public Key Infrastructure (APKI), a certificate-based identity and trust system for autonomous AI agents. APKI extends X.509v3 with five agent-specific extensions, defines the agent:// URI scheme for agent identification, specifies Agent Transparency Logs modelled on Certificate Transparency (RFC 9162), and provides mechanisms for cross-organizational trust federation. APKI is designed to be compatible with existing PKI deployments, SPIFFE workload identity, and the IETF WIMSE working group’s specifications.
• Agent Transport Protocol: Asynchronous Store-and-Forward Messaging for Autonomous AI Agents
  • Draft: draft-sharif-agent-transport-protocol | WG: individual | Updated: 2026-08-27 | Hits: agent、agents、mcp、a2a、capability
  • datatracker ↗
  • Abstract: 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.
• Agent Event Behaviour Analysis (AEBA): A Framework for Behavioural Security Monitoring of Autonomous AI Agents
  • Draft: draft-sharif-aeba | WG: individual | Updated: 2026-08-27 | Hits: agent、agents
  • datatracker ↗
  • Abstract: 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.
• Notice of Discontinuation: Attested Agent Payment
  • Draft: draft-hawkins-scitt-attested-agent-payment | WG: individual | Updated: 2026-08-27 | Hits: agent
  • datatracker ↗
  • Abstract: 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.
• A YANG Network Data Model for Inventory Topology Mapping
  • Draft: draft-ietf-ivy-network-inventory-topology | WG: ivy | Updated: 2026-08-29 | Hits: —
  • datatracker ↗
  • Abstract: This document defines 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.
• A YANG Data Model for Passive Network Inventory
  • Draft: draft-ygb-ivy-passive-network-inventory | WG: ivy | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: This document presents a YANG data model for tracking and managing passive network inventory. The model augments the base network inventory model.
• A YANG Network Data Model of Network Inventory Software Extensions
  • Draft: draft-ietf-ivy-network-inventory-software | WG: ivy | Updated: 2026-07-06 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• A YANG Data Model for Network Inventory Location
  • Draft: draft-ietf-ivy-network-inventory-location | WG: ivy | Updated: 2026-07-06 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• A YANG Module for Entitlement Inventory
  • Draft: draft-ietf-ivy-entitlement-inventory | WG: ivy | Updated: 2026-06-25 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network
  • Draft: draft-ietf-rtgwg-atn-bgp | WG: rtgwg | Updated: 2026-08-25 | Hits: —
  • datatracker ↗
  • Abstract: 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 replace 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.
• Multi-segment SD-WAN via Cloud Backbone
  • Draft: draft-ietf-rtgwg-multisegment-sdwan | WG: rtgwg | Updated: 2026-08-24 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• BGP Prefix Independent Convergence
  • Draft: draft-ietf-rtgwg-bgp-pic | WG: rtgwg | Updated: 2026-08-19 | Hits: —
  • datatracker ↗
  • Abstract: In a network comprising thousands of BGP peers exchanging millions of routes, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to Equal Cost Multi-Path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup.
• A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)
  • Draft: draft-ietf-rtgwg-vrrp-rfc8347bis | WG: rtgwg | Updated: 2026-08-13 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Fast failure detection in VRRP with Point to Point BFD
  • Draft: draft-ietf-rtgwg-vrrp-bfd-p2p | WG: rtgwg | Updated: 2026-08-11 | Hits: —
  • datatracker ↗
  • Abstract: 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).
• Advertisement of Remote Interface Identifiers for Layer 2 Bundle Members
  • Draft: draft-ietf-lsr-l2-bundle-member-remote-id | WG: lsr | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Advertising Unreachable Links in OSPF
  • Draft: draft-ietf-lsr-ospf-ls-link-infinity | WG: lsr | Updated: 2026-08-24 | Hits: —
  • datatracker ↗
  • Abstract: 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).
• An Algorithm for Computing Dynamic Flooding Topologies
  • Draft: draft-ietf-lsr-dynamic-flooding-algorithm | WG: lsr | Updated: 2026-08-24 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• A YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm
  • Draft: draft-ietf-lsr-isis-flex-algo-yang | WG: lsr | Updated: 2026-08-19 | Hits: —
  • datatracker ↗
  • Abstract: This document defines a YANG data model to support IS-IS Application- Specific Link Attributes and Flexible Algorithm.
• A YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm
  • Draft: draft-ietf-lsr-ospf-flex-algo-yang | WG: lsr | Updated: 2026-08-19 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• The IPv6 Loopback Address Prefix
  • Draft: draft-kumari-ipv6-loopback | WG: 6man | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: { 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.
• Architecture and Framework for IPv6 over Non-Broadcast Access
  • Draft: draft-ietf-6man-ipv6-over-wireless | WG: 6man | Updated: 2026-08-23 | Hits: —
  • datatracker ↗
  • Abstract: This document presents an architecture and framework for IPv6 access networks that decouples the network-layer concepts of Links, Interface, and Subnets from the link-layer concepts of links, ports, and broadcast domains, and limits the reliance on link-layer broadcasts. This architecture is suitable for IPv6 over any network, including non-broadcast networks, which is typically the case for intangible media such as wireless and virtual networks such as overlays. A study of the issues with IPv6 ND over intangible media is presented, and a framework to solve those issues within the new architecture is proposed.
• YANG Data Model for IPv6 Neighbor Discovery
  • Draft: draft-ietf-6man-ipv6-neighbor-discovery-yang | WG: 6man | Updated: 2026-08-20 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• IPv6 Query for Enabled In-situ OAM Capabilities
  • Draft: draft-ietf-6man-icmpv6-ioam-conf-state | WG: 6man | Updated: 2026-08-18 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Clarifying SRv6 SID List Processing
  • Draft: draft-ietf-6man-sidlist-clarification | WG: 6man | Updated: 2026-08-13 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Distribute SRv6 Locator by DHCP
  • Draft: draft-ietf-spring-dhc-distribute-srv6-locator-dhcp | WG: spring | Updated: 2026-08-28 | Hits: —
  • datatracker ↗
  • Abstract: In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and segment identifiers (SIDs) 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 Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
• SRv6 for Redundancy Protection
  • Draft: draft-ietf-spring-sr-redundancy-protection | WG: spring | Updated: 2026-08-28 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Introducing Resource Awareness to SR Segments
  • Draft: draft-ietf-spring-resource-aware-segments | WG: spring | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: 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).
• SR Policy Group
  • Draft: draft-ietf-spring-sr-policy-group | WG: spring | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over IPv6 (SRv6) Data Plane
  • Draft: draft-ietf-spring-stamp-srpm-srv6 | WG: spring | Updated: 2026-08-18 | Hits: —
  • datatracker ↗
  • Abstract: 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 defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedures are used for links and SRv6 paths (including Segment Lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SRv6 paths.
• Associating AI Usage Preferences with Content in HTTP
  • Draft: draft-ietf-aipref-attach | WG: aipref | Updated: 2026-08-19 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• A Vocabulary For Expressing AI Usage Preferences
  • Draft: draft-ietf-aipref-vocab | WG: aipref | Updated: 2026-08-19 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Export of QUIC Information in IP Flow Information Export (IPFIX)
  • Draft: draft-lin-opsawg-ipfix-quic-header | WG: opsawg | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests
  • Draft: draft-ietf-opsawg-scheduling-oam-tests | WG: opsawg | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: This document defines two YANG data models to support on-demand 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.
• IP Flow Information Export (IPFIX) Alternate-Marking Information Elements
  • Draft: draft-ietf-opsawg-ipfix-alt-mark | WG: opsawg | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: This document specifies the IP Flow Information Export (IPFIX) Information Elements (IEs) to export Alternate Marking measurement data.
• Export of ECN Information in IPFIX
  • Draft: draft-song-opsawg-ipfix-ecn | WG: opsawg | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• YANG deVELpment PrOCEss and maintenance (VELOCE)
  • Draft: draft-ietf-opsawg-veloce-yang | WG: opsawg | Updated: 2026-08-25 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Subscription to Notifications in a Distributed Architecture
  • Draft: draft-ietf-netconf-distributed-notif | WG: netconf | Updated: 2026-08-29 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• YANG Notification Transport Capabilities
  • Draft: draft-ietf-netconf-yp-transport-capabilities | WG: netconf | Updated: 2026-08-29 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• RESTCONF Extension to Support Trace Context Headers
  • Draft: draft-ietf-netconf-restconf-trace-ctx-headers | WG: netconf | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: This document defines an extension to the RESTCONF protocol in order to support Trace Context propagation as defined by the W3C.
• NETCONF Extension to support Trace Context propagation
  • Draft: draft-ietf-netconf-trace-ctx-extension | WG: netconf | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification.
• Augmented-by Addition to the YANG Library
  • Draft: draft-ietf-netconf-yang-library-augmentedby | WG: netconf | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: “YANG Library” specifies the YANG module “ietf-yang-library” that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. This document augments the “ietf-yang-library” to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server’s YANG library. This document updates RFC 8525, as the lists in Section 2 is modified to also include augmented-by list.
• SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS
  • Draft: draft-ietf-idr-bgp-ls-sr-policy-path-segment | WG: idr | Updated: 2026-08-28 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• BGP-LS Extensions for Inter-AS Topology Retrieval
  • Draft: draft-ietf-idr-bgpls-inter-as-topology-ext | WG: idr | Updated: 2026-08-28 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• BGP Route Reflector with Next Hop Self
  • Draft: draft-ietf-idr-bgp-fwd-rr | WG: idr | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: The procedures in BGP Route Reflection (RR) spec RFC4456 primarily deal with scenarios where the RR is reflecting BGP routes with next hop unchanged. In some deployments like Inter-AS Option C (Section 10, RFC4364), the ABRs may perform RR functionality with nexthop set to self. If adequate precautions are not taken, the RFC4456 procedures can result in traffic forwarding loop in such deployments. This document illustrates one such looping scenario, and specifies approaches to minimize possiblity of traffic forwarding loop in such deployments. An example with Inter-AS Option C (Section 10, RFC4364) deployment is used, where RR with next hop self is used at redundant ABRs when they re-advertise BGP transport family routes between multiple IGP domains.
• VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4
  • Draft: draft-ietf-idr-vpn-prefix-orf | WG: idr | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Traffic Steering using BGP FlowSpec with SR Policy
  • Draft: draft-ietf-idr-ts-flowspec-srv6-policy | WG: idr | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: 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 normative protocol mechanisms for combining FlowSpec NLRIs with specific BGP Extended Communities for transport policy steering in SR-MPLS and SRv6 networks (Mode 1), and optionally with the BGP Prefix-SID Attribute when egress service action execution is required in SRv6 networks (Mode 2).
• EVPN multi-homing support for L3 services
  • Draft: draft-ietf-bess-evpn-l3mh-proto | WG: bess | Updated: 2026-08-27 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Interconnecting EVPN and IPVPN Domains
  • Draft: draft-ietf-bess-evpn-ipvpn-interworking | WG: bess | Updated: 2026-08-26 | Hits: —
  • datatracker ↗
  • Abstract: Ethernet Virtual Private Network (EVPN) provides a unified BGP control plane for both intra- and inter-subnet forwarding within tenant networks. When a tenant network spans multiple domains, including any combination of EVPN and IPVPN domains, it becomes necessary to define the interworking mechanisms among these BGP domains (EVPN and IPVPN) to ensure seamless end-to-end tenant connectivity. This document defines these interworking procedures. In addition, this document defines a new BGP Path Attribute, referred to as D-PATH (Domain PATH), which provides loop prevention for gateway nodes by protecting against control plane loops. The introduction of D-PATH modifies the BGP best path selection process for Multiprotocol BGP inter-subnet forwarding routes of SAFI 128 (IPVPN) and SAFI 70 (EVPN).
• EVPN Network Layer Fault Management
  • Draft: draft-ietf-bess-evpn-bfd | WG: bess | Updated: 2026-08-17 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• BGP Usage for SD-WAN Overlay Networks
  • Draft: draft-ietf-bess-bgp-sdwan-usage | WG: bess | Updated: 2026-08-13 | Hits: —
  • datatracker ↗
  • Abstract: 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.
• Multicast and Ethernet VPN with Segment Routing P2MP and Ingress Replication

  • Draft: draft-ietf-bess-mvpn-evpn-sr-p2mp | WG: bess | Updated: 2026-08-13 | Hits: —

  • datatracker ↗

  • Abstract: A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs in a Segment Routing domain.

7. Newly Published RFCs

• RFC 10037: Registration Data Access Protocol (RDAP) Extension for DNS Time-to-Live (TTL) Values（2026-08-28）
  • rfc-editor ↗
  • Abstract: This document specifies an extension to the Registration Data Access Protocol (RDAP), which allows the Time-to-Live (TTL) values for relevant DNS record types to be included in RDAP responses.
• RFC 10038: Distributing the Segment Routing over IPv6 (SRv6) Locator Using DHCPv6（2026-08-28）
  • rfc-editor ↗
  • Abstract: In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and segment identifiers (SIDs) 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 the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
• RFC 10034: RTP Payload Format for Visual Volumetric Video-Based Coding (V3C)（2026-08-28）
  • rfc-editor ↗
  • Abstract: A visual volumetric video-based coding (V3C) ISO/IEC 23090-5 bitstream is composed of V3C units that contain V3C atlas sub-bitstreams, V3C video sub-bitstreams, and a V3C parameter set. This document describes an RTP payload format for V3C atlas sub-bitstreams. The RTP payload format for V3C video sub-bitstreams is defined by relevant IETF RFCs for the applicable video codec. The V3C RTP payload format allows for the packetization of one or more V3C atlas Network Abstraction Layer (NAL) units in an RTP packet payload as well as the fragmentation of a V3C atlas NAL unit into multiple RTP packets. The document also describes the mechanisms for grouping RTP streams of V3C component sub-bitstreams, providing a complete solution for streaming V3C-encoded content.
• RFC 10035: YANG Library: Addition of the augmented-by List（2026-08-27）
  • rfc-editor ↗
  • Abstract: “YANG Library” (RFC 8525) specifies the “ietf-yang-library” YANG module that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. This document augments the “ietf-yang-library” module to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules by querying the network management server’s YANG library. This document updates RFC 8525 to also include the augmented-by list.
• RFC 10017: OAuth 2.0 for Browser-Based Applications（2026-08-21）
  • rfc-editor ↗
  • Abstract: This specification details the threats, attack consequences, security considerations, and best practices that must be taken into account when developing browser-based applications that use OAuth 2.0.
• RFC 10036: Incremental Forwarding of HTTP Messages（2026-08-21）
  • rfc-editor ↗
  • Abstract: This document specifies the “Incremental” HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally.
• RFC 10030: Network Time Protocol (NTP) over the Precision Time Protocol (PTP)（2026-08-14）
  • rfc-editor ↗
  • Abstract: This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) that encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers (NICs) that can timestamp only PTP messages and delay corrections in PTP transparent clocks.
• RFC 10031: Media Access Control (MAC) Addresses in X.509 Certificates（2026-08-14）
  • rfc-editor ↗
  • Abstract: This document defines a new GeneralName.otherName for inclusion in the X.509 Subject Alternative Name (SAN) and Issuer Alternative Name (IAN) extensions to carry an IEEE Media Access Control (MAC) address. The new name form makes it possible to bind a Layer 2 interface identifier to a public key certificate. Additionally, this document defines how constraints on this name form can be encoded and processed in the X.509 Name Constraints extension (NCE).
• RFC 9971: Multiple Loss Ratio Search（2026-08-14）
  • rfc-editor ↗
  • Abstract: This document describes an alternative to throughput in “Benchmarking Methodology for Network Interconnect Devices” (RFC 2544) by defining a new methodology called Multiple Loss Ratio Search (MLRsearch). MLRsearch aims to minimize Search Duration, support multiple loss ratio goals, and improve result repeatability and comparability. MLRsearch is motivated by the pressing need to address the challenges of evaluating and testing the various data plane solutions, especially in software-based networking systems based on Commercial Off-the-Shelf (COTS) CPU hardware vs. purpose-built Application-Specific Integrated Circuit (ASIC) / Network Processing Unit (NPU) / Field-Programmable Gate Array (FPGA) hardware.
• RFC 10028: Updates to Dynamic IPv6 Multicast Address Group IDs（2026-08-13）
  • rfc-editor ↗
  • Abstract: This document describes limitations of the existing range of dynamic IPv6 multicast addresses specified in “Allocation Guidelines for IPv6 Multicast Addresses” (RFC 3307). It updates RFC 3307 by replacing these allocations with a new IANA registry in the “IPv6 Multicast Address Space” registry group. The document also defines initial contents of the new registry: a reduced allocation for the Multicast Address Dynamic Client Allocation Protocol (MADCAP) (RFC 2730), a range for Source-Specific Multicast (SSM), a Private Use range, a range for Experimental Use, and Solicited-Node multicast addresses (which were not previously noted in RFC 3307).
• RFC 10018: Multicast and Ethernet VPN with Segment Routing Point-to-Multipoint (P2MP) and Ingress Replication（2026-08-13）
  • rfc-editor ↗
  • Abstract: A Point-to-Multipoint (P2MP) tree in a Segment Routing (SR) domain carries traffic from a Root to a set of Leaves. This document specifies extensions to BGP encodings and procedures for P2MP trees and Ingress Replication used in BGP/MPLS IP VPNs and Ethernet VPNs (EVPNs) in an SR domain. This document updates RFCs 6514 and 7988.
• RFC 10027: Best Current Practice for Security of Cross-Device Flows（2026-08-11）
  • rfc-editor ↗
  • Abstract: This document describes threats against cross-device flows along with practical mitigations, protocol selection guidance, and a summary of formal analysis results identified as relevant to the security of cross-device flows. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts, and engineers implementing cross-device flows.
• RFC 10006: Automatic SIP Trunking and Peering（2026-08-11）
  • rfc-editor ↗
  • Abstract: This document specifies a framework that enables enterprise telephony Session Initiation Protocol (SIP) networks to solicit and obtain a capability set document from a SIP service provider. The capability set document encodes a set of characteristics that enable easy peering between enterprise and service provider SIP networks.
• RFC 10001: Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments（2026-08-11）
  • rfc-editor ↗
  • Abstract: This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901.
• RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3（2026-08-10）
  • rfc-editor ↗
  • Abstract: This document defines three hybrid key agreement mechanisms for TLS 1.3 — X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 — that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange.
• RFC 10029: DNS Multiple QTYPEs（2026-07-31）
  • rfc-editor ↗
  • Abstract: This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the Question section of a DNS QUERY (OpCode=0).
• RFC 10022: IMAP UIDBATCHES Extension（2026-07-31）
  • rfc-editor ↗
  • Abstract: The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve Unique Identifier (UID) ranges that partition a mailbox’s messages into equally sized batches. This enables clients to perform operations such as FETCH, SEARCH, and STORE on specific message batches, providing better control over resource usage and response sizes. The extension is particularly useful with the UIDONLY mode where sequence numbers are unavailable.
• RFC 10019: Zeroconf Multicast Address Allocation Problem Statement and Requirements（2026-07-31）
  • rfc-editor ↗
  • Abstract: This document surveys current problems with existing protocols for automatically assigning multicast IP addresses in zero-configuration (zeroconf) networking environments. It addresses key challenges, such as link-layer address collisions, hardware limitations, multicast snooping inefficiencies, and the need to avoid manual configuration. Based on these challenges, it derives requirements for a lightweight, decentralized solution for dynamically allocating unique multicast group addresses without central coordination. The document presents explicit requirements covering discovery, allocation, conflict detection and resolution, and lease management. It also evaluates considerations specific to IPv6 and IPv4 multicast address ranges, and identifies approaches that are unsuited for zeroconf deployment. This foundation serves as a reference for developing future solutions for multicast address allocation that operate autonomously within local networks.
• RFC 10023: The “_for-sale” Underscored and Globally Scoped DNS Node Name（2026-07-31）
  • rfc-editor ↗
  • Abstract: This document defines an operational convention that uses the reserved underscored DNS leaf node name “_for-sale” to indicate the parent domain name is available for purchase. The convention can be deployed without disrupting existing operations, and it may be applied even when the domain name is still actively in use.
• RFC 10013: Entity Attestation Token (EAT) Measured Component（2026-07-31）

  • rfc-editor ↗

  • Abstract: The term “measured component” refers to an object within the attester’s target environment whose state can be sampled and typically digested using a cryptographic hash function. Examples of measured components include firmware stored in flash memory, software loaded into memory at start time, data stored in a file system, or values in a CPU register. This document provides the information model for the measured component and two associated data models. This separation is intentional: The JSON and Concise Binary Object Representation (CBOR) serializations, coupled with the media types and associated Constrained Application Protocol (CoAP) Content-Formats, enable the immediate use of the semantics within the Entity Attestation Token (EAT) framework. Meanwhile, the information model can be reused in future specifications to provide additional serializations, for example, using ASN.1.

8. SDO Updates by Organization (excl. IETF)

3GPP（3） · IEEE（6） · W3C（5） · OASIS（4） · CNCF（4） · GSMA（3） · APNIC（3） · RIPE（3）

3GPP(3 items)

• Magic in the air as RAN celebrate（2026-08-28）
  • 原文 ↗
• RAN5 Leadership Election（2026-08-26）
  • 原文 ↗
• 2025 Excellence rewarded at Working Groups（— | needs verification）
  • 原文 ↗

IEEE(6 items)

• Building Consumer Trust in AI-Driven Products（2026-08-28）
  • 原文 ↗
• What Is Remote Patient Monitoring and How Is It Used for Telehealth?（2026-08-26）
  • 原文 ↗
• How Does Telehealth Leverage Connected Medical Devices?（2026-08-24）
  • 原文 ↗
• What Are Autonomous Intelligent Systems (AIS)?（2026-08-21）
  • 原文 ↗
• Medical Devices & FDA Requirements: What It Means to Stay Ahead of Cyberattacks（2026-08-19）
  • 原文 ↗
• What Kinds of Content Require Online Age Verification?（2026-08-17）
  • 原文 ↗

W3C(5 items)

• Making digital identity work across the Web: GDC 2026（2026-08-24）
  • 原文 ↗
• WOFF 1.0: a milestone on W3C’s journey of fonts on the web（2026-07-28）
  • 原文 ↗
• Simplified task force enrollment and participant management（2026-07-24）
  • 原文 ↗
• Threat modeling age-based content restrictions: what we learned at EIC 2026（2026-07-20）
  • 原文 ↗
• CSS animations, human rights, and big accessibility at the AB Web Meetup（2026-07-15）
  • 原文 ↗

OASIS(4 items)

• Invitation to comment on OData Version 4.02: Protocol, CSDL JSON, CSDL XML, and JSON Format – ends 27 September 2026（2026-08-28）
  • 原文 ↗
• OASIS Approves Universal Business Language V2.5 Standard for Global Business Transactions（2026-08-26）
  • 原文 ↗
• Invitation to comment on Akoma Ntoso v2.0 Part 2 (AKN 3.1) before call for consent as OASIS Standard（2026-07-16）
  • 原文 ↗
• Invitation to comment on KMIP Usage Guide v3.0 – ends 15 August 2026（2026-07-16）
  • 原文 ↗

CNCF(4 items)

• Scale before the spike: Predictive autoscaling for GPU workloads on Kubernetes（2026-08-28）
  • 原文 ↗
• Your Kubernetes platform is ready for containers. Is it ready for AI?（2026-08-28）
  • 原文 ↗
• Building an AI factory on Kubernetes（2026-08-27）
  • 原文 ↗
• Governance guidance for CNCF projects: Choosing the right structure for your project’s size and stage（2026-08-26）
  • 原文 ↗

GSMA(3 items)

• GSMA MWC26 Doha to co-locate alongside the ITU Plenipotentiary Conference in November 2026（2026-08-27）
  • 原文 ↗
• 80% of Malawians Remain Offline Despite Coverage – New GSMA Report Highlights Path to Inclusive Digital Access and MWK 1.1 Trillion Growth（2026-08-20）
  • 原文 ↗
• GSMA Industry Services Launches Circularity Services to Help Operators Reduce E-Waste and Unlock Value（2026-08-12）
  • 原文 ↗

APNIC(3 items)

• The day after the zero-days（2026-08-28）
  • 原文 ↗
• The lingering legacy of ‘reserved’ ports（2026-08-27）
  • 原文 ↗
• Online voting for NRO NC election 2026 opens today（2026-08-27）
  • 原文 ↗

RIPE(3 items)

• DNS Abuse and Criminal Infrastructure: Beyond Definitions and Blocklists（2026-08-24）
  • 原文 ↗
• Deploying IPv6-first EKS on AWS: What Still Doesn’t Work, and What It Saves（2026-08-14）
  • 原文 ↗
• Multiple LIR Accounts: Looking Back and Thinking Ahead（2026-08-12）
  • 原文 ↗

CCSA, ITU and ETSI are not auto-fetched yet (source limitations); manually curated items will appear here grouped by organization.