The 126th meeting of the Internet Engineering Task Force — the volunteer-driven body whose output shapes every protocol the modern internet runs on — opened Saturday in Vienna and runs through July 24. The Hackathon and Code Sprint are underway this weekend. Full working group sessions begin Monday and continue through Friday afternoon. For engineers who architect multi-agent systems, the most consequential two hours of the week happen Thursday morning.

That is when a Birds-of-a-Feather session called agentproto convenes to address a problem that has been building for the past eighteen months: five competing AI agent protocols — Anthropic's Model Context Protocol, Google's Agent2Agent, the Agent Communication Protocol, the Agent Network Protocol, and Cisco's Agntcy Framework — have each staked out overlapping territory without any of them clearing the one bar that makes a protocol truly interoperable across organizational boundaries. That bar is an IETF RFC.

The agentproto session is not a product announcement or a panel discussion. It is the formal mechanism by which the IETF decides whether to charter a Working Group. If it does, the resulting standard — likely an RFC two to three years out — would establish the protocol baseline that every vendor shipping inter-domain AI agent infrastructure would eventually need to implement. If the session reveals too much disagreement to proceed, the community returns to the mailing list and the current landscape of competing proprietary-ish standards continues. The IETF has published a full overview of the five scheduled BoFs.

This is the decision the Vint Cerf warning pointed toward. Six days before IETF 126 opened, TechTimes published Cerf's retirement argument: that AI agent systems running at machine speed cannot tolerate the semantic ambiguity of natural-language inter-agent communication, and that the industry will be forced — as it was in 1974 — toward formal, unambiguous protocols.

What the IETF Is, and Why Its Output Lasts

The IETF has been producing open internet standards since 1986. It operates without formal membership requirements — any engineer can participate — and it makes decisions through "rough consensus and running code," not by vote. Its output, published as Request for Comments (RFC) documents, is freely available and forms the basis for TLS (which secures browser connections), DNS (which translates domain names into addresses), QUIC (the transport layer underlying most of HTTP/3), and BGP (the routing protocol connecting the global network of autonomous systems).

The IETF process is slow by commercial standards, intentionally. A proposal typically moves from a Birds-of-a-Feather session to a Working Group charter, through multiple Internet-Draft revisions, through IETF-wide last call and Area Director review, to publication as an RFC. The typical timeline from a BoF to a published Internet Standard runs two to four years. That deliberateness is also what makes an IETF RFC uniquely durable: once a protocol is an RFC, it becomes the baseline every implementation must match for genuine interoperability.

The meeting in Vienna is hosted at the Hilton Vienna Park. Approximately 1,000 engineers are in attendance in person, with additional remote participation available for all sessions. A plenary is scheduled for Wednesday, July 22. Session recordings will be posted to the IETF's YouTube channel; agendas, drafts, and materials are available on the IETF Datatracker.

Five BoFs: Why Three Are About AI

Of the five Birds-of-a-Feather sessions scheduled at IETF 126, three concern AI agent communication — an unusual concentration that reflects how rapidly the problem has moved from a vendor concern to an internet-infrastructure concern.

PTTH — Reversing the HTTP Client-Server Model (Monday, July 20)

The first BoF of the week revisits a concept that received its inaugural hearing at IETF 123. PTTH proponents return with a proposed Working Group charter. The goal is a standardized, secure method for swapping the HTTP server and client roles — useful when a server is intended to be accessed by only a small number of pre-approved clients that the server can reach directly, and is not publicly accessible. Currently, several proprietary and vendor-specific solutions handle this use case separately; PTTH would replace them with a single interoperable standard.

DAWN — Decentralized Agent and Workload Discovery (Tuesday, July 21)

DAWN is seeking Working Group status to define requirements and protocol solutions for an automated, decentralized, interoperable discovery mechanism — one that can operate at the scale of distributed processing environments where components arrive without pre-configured knowledge of each other. AI agent-to-agent communication is an explicit part of DAWN's scope.

The discovery gap DAWN targets is the same one that produced DNS-AID, an open standard the Linux Foundation accepted in May 2026. DNS-AID lets AI agents publish their endpoints and capabilities as standard DNS records, enabling discovery without a centralized registry. DAWN would define the broader requirements framework; DNS-AID represents one candidate solution within that space.

CURRENT — Post-Quantum Key Management for Network Transport (Tuesday, July 21)

CURRENT aims to charter a Working Group to define a two-party security protocol using Messaging Layer Security (MLS) for key management. MLS, already an IETF standard (RFC 9420), provides forward secrecy, post-compromise security, and asynchronous key ratcheting — and it already supports post-quantum cryptography alongside traditional algorithms. CURRENT would bring MLS's key-management capabilities down into the network transport layer, where they can protect protocols that rely on classical public-key cryptography (RSA, elliptic-curve) against the eventual arrival of quantum computing capable of breaking those schemes. The formal verification work that was applied to MLS's design gives CURRENT a stronger starting point than most new protocol proposals.

DMSC — AI Agent Gateway Model (Wednesday, July 22)

DMSC is explicitly non-Working-Group-forming — it is a diagnostic session. The goal is to map the terrain for AI agent gateway-mediated collaboration: capability exposure, request forwarding, coordination, synchronization, policy control, observability, and secure inter-agent communication. DMSC will profile existing and evolving mechanisms defined elsewhere, identify what is missing, and determine whether a formal gateway model definition would provide material benefit. Its output will likely feed into agentproto's Working Group charter discussions.

Agentproto: What Is Actually Being Decided Thursday

The agentproto BoF, scheduled for Thursday July 23 at 09:00 Central European Summer Time (03:00 ET), is where the structural question becomes explicit.

The past eighteen months produced a rush of competing, overlapping protocols for connecting AI agents to tools and to each other: Anthropic's Model Context Protocol, Google's Agent2Agent, the Agent Communication Protocol, the Agent Network Protocol, and Cisco's Agntcy Framework, among others. Each addresses different layers of the problem. MCP — donated by Anthropic to the Linux Foundation's Agentic AI Foundation in December 2025 — had reached 97 million monthly SDK downloads by early 2026, and was adopted by every major AI provider. A2A, donated by Google to the Linux Foundation in June 2025, had 150 organizational supporters by April 2026, including AWS, Cisco, IBM, Microsoft, Salesforce, SAP, and ServiceNow.

None of that market momentum resolves the inter-domain interoperability problem. MCP standardizes how a single agent connects to external tools and data — the client-server layer. A2A standardizes how agents discover each other's capabilities and delegate tasks — the peer-to-peer layer. What neither protocol currently addresses is the full set of requirements the Rosenberg-Jennings framework identifies for agent communication at internet scale: cross-domain identity federation, multi-hop lifecycle management, user confirmation before irreversible API actions, and protocol-level attribution for security incidents.

The agentproto BoF builds on a well-attended IETF 124 side meeting and on that framework document, authored by Jonathan Rosenberg of Five9 and Cullen Jennings of Cisco. Rosenberg is also the lead author of RFC 3261, the Session Initiation Protocol — the standard that governs real-time communications across the internet today. His involvement signals that the agentproto work is being approached with the same scope and seriousness as the protocols that underpin voice and video communication.

The Rosenberg-Jennings Internet-Draft explicitly frames AI agent protocols as a potential new layer sitting above HTTP, SIP, and RTP in the internet stack — the same position in the architecture that those application-layer protocols occupy above IP, TCP, UDP, and QUIC. If the IETF charters a Working Group on that basis, it is asserting that AI agent communication is an internet-layer problem — not a product-layer problem — and the resulting RFC would carry the same implementation authority as any other foundational internet standard.

Why Prompt Injection Is the Security Test Agentproto Must Pass

The security implications of an unresolved protocol landscape are among the most concrete technical arguments for standardization. The Rosenberg-Jennings framework dedicates a section to prompt injection attacks in the multi-agent context, and the problem it describes is structurally different from single-agent prompt injection.

In a multi-agent system, a malicious user interacting with Agent A can craft input specifically designed to propagate through Agent A to Agent Z — a second agent that Agent A invokes. Because Agent A relays content from the user to Agent Z as part of normal operation, the injection can bypass the defenses of the first agent entirely and exploit the trust relationship between agents. The Rosenberg-Jennings document describes this as introducing a "new threat vector" distinct from direct injection, and explicitly states that prompt injection attacks are "notoriously difficult to prevent". The protocol-level response is not prevention but attribution: the standard must introduce mechanisms for diagnosis, logging, and traceability so that when an incident occurs, security teams can reconstruct what happened and which agent was responsible.

OWASP has ranked prompt injection as the top security risk among its Top 10 threats for LLM-based applications. Documented real-world incidents include injections through public Slack channels leaking private channel content, injections through GitHub issues extracting developer credentials, and injections via web pages redirecting user data to attacker-controlled servers. None of these incidents involved inter-domain agent cascades; the agentproto work is addressing a threat vector that current defenses were not designed for.

Whether Thursday's session produces a Working Group charter — or surfaces disagreements sufficient to send the work back to the mailing list — will be visible in real time. The mailing list archive (agent2agent list at mailarchive.ietf.org) has been active for months. The session materials will be posted to the IETF Datatracker before the session.

Rest of the Week: BGP Security, DNS, and PQC

Beyond the BoFs, the established Working Groups advancing existing standards work span the full IETF agenda.

Routing Security (SIDROPS/RPKI). The SIDR Operations Working Group develops guidance for deploying Secure Inter-Domain Routing technology — the Resource Public Key Infrastructure (RPKI), BGP origin validation, and BGPsec — while maintaining routing stability during the transition to fully RPKI-aware networks. One active draft addresses a subtle but consequential problem: annotating BGP routes with RPKI-derived validation states in transitive path attributes causes global flooding of BGP UPDATE messages whenever Route Origin Authorizations are issued or revoked. The recommendation is to avoid carrying those validation states in transitive attributes — a change to standard routing practice with potential stability implications for operators who have already implemented such tagging.

DNS Operations (DNSOP). The DNS Operations Working Group develops guidelines for DNS software operation, service administration, and zone management. Active items this cycle include post-quantum algorithm selection for DNSSEC, where engineers are weighing signature-size tradeoffs against security conservatism in a post-NIST-standardization environment. NIST finalized its first post-quantum cryptography standards in August 2024.

Security Area Advisory Group (SAAG). The Security Area open meeting is a cross-cutting forum for security and privacy concerns across all IETF working areas. SAAG sessions typically surface issues that do not fit neatly into any single working group's charter; given the volume of AI-adjacent security work in progress, this year's session is expected to be particularly active.

What the Vienna Meeting Actually Decides

IETF meetings produce documents, not products. The working group sessions in Vienna will advance drafts, close issues, and identify gaps. The BoFs will reveal whether there is community consensus and organizational energy sufficient to charter new working groups. What gets chartered in Vienna — and what does not — shapes what the RFC pipeline looks like in 2027 and 2028.

The velocity of AI agent deployment has outrun the standards community's ability to produce RFCs on the same schedule. The agentproto BoF is the formal acknowledgment of that gap. Companies building multi-agent platforms, API providers, and enterprise software vendors will read Thursday's session outcome as a signal: either the IETF will standardize agent-to-agent communication in a way that overrides vendor choices, or the market-dominant protocols (MCP, A2A) will establish their current architectures as the baseline by default.

Vint Cerf's argument — that TCP/IP succeeded not because it was technically superior to its competitors, but because it was open, free, and required running implementations — applies directly here. The IETF was designed to be the body that makes that call. Whether it does so for AI agent protocols, or defers to protocols already deployed at 97 million downloads per month, is the question Vienna is answering this week.

Session materials and recordings from IETF 126 will be posted to the IETF Datatracker and the IETF YouTube channel as sessions conclude. IETF 127 is scheduled for November 14–20, 2026, in San Francisco, hosted at the Hilton Union Square.

Frequently Asked Questions

What is a Birds-of-a-Feather session at an IETF meeting, and what does "working-group-forming" mean?

A Birds-of-a-Feather session is an initial, community-wide discussion about a topic that may be ready for new IETF work. Some BoFs are working-group-forming: they arrive with a draft charter and aim to confirm that there is sufficient consensus and scope to spin up a new Working Group. Others are non-working-group-forming — designed to map a problem space and identify gaps before committing to a charter. For agentproto and DAWN, the goal is to form working groups. For DMSC, the goal is diagnostic. When a Working Group is chartered, it produces Internet-Drafts that eventually become RFCs — the binding technical specifications that every implementation of a given protocol must satisfy.

How does prompt injection change when AI agents communicate with each other, and why does it matter for the agentproto standard?

In a single-agent system, prompt injection means a user crafts malicious input to override that agent's instructions. In a multi-agent system, the attack can cascade: a user injects into Agent A, which relays the content to Agent B as part of normal operation, and Agent B — which trusts Agent A — executes the malicious instruction. The injected command travels through the trust relationship between agents, bypassing the first agent's defenses entirely. OWASP lists prompt injection as the top threat to LLM-based applications, and documented real-world incidents already show injection via public channels, documents, and web pages. The agentproto work addresses this at the protocol layer by requiring that any agent-to-agent communication standard include mechanisms for logging, attribution, and incident reconstruction — not just application-level detection, which is insufficient for cross-domain attacks.

What is the technical difference between MCP and A2A, and what would an IETF standard add that they do not cover?

MCP (Model Context Protocol) is a client-server protocol: an AI agent reaches out to a tool, database, or API and requests data or actions. A2A (Agent2Agent Protocol) is a peer-to-peer protocol: two agents discover each other's capabilities via Agent Cards (JSON documents at well-known URLs), then coordinate tasks using HTTP, Server-Sent Events, and JSON-RPC. MCP had 97 million monthly SDK downloads by early 2026; A2A had 150 organizational supporters. What neither currently specifies is: cross-domain identity federation (how one organization's agent proves to another's that it is authorized to act on a user's behalf), multi-hop lifecycle management (what happens to an agent chain when one node in the chain fails), user confirmation requirements before irreversible API calls, and protocol-level security attribution for prompt injection incidents. These are the gaps the Rosenberg-Jennings framework document identified as requiring IETF-level standardization.

What is post-quantum cryptography and why is the CURRENT BoF addressing it at the network transport layer?

Post-quantum cryptography refers to encryption and signature algorithms designed to remain secure against attacks from quantum computers. Current internet security — TLS, HTTPS, QUIC, DNS-over-TLS — relies heavily on RSA and elliptic-curve schemes that would be vulnerable to Shor's algorithm on a sufficiently powerful quantum computer. NIST finalized its first post-quantum standards in August 2024. The CURRENT BoF targets network transport specifically because the threat is not purely future-dated: "harvest now, decrypt later" attacks allow an adversary to intercept encrypted traffic today and decrypt it once quantum computing matures. CURRENT would use Messaging Layer Security (RFC 9420) — which already supports post-quantum algorithms alongside classical ones, and has been formally verified — to define a rekeying mechanism robust against both classical and quantum adversaries at the transport layer, below the application protocols that depend on it.