AI in the IETF & IRTF
Current work, and what's next…
A field guide to the AI work across the IETF and IRTF — some of it already chartered, some proposed, and some that still needs exploring.
Dhruv Dhody · Connections 2026 · a pre-IETF 126 forum
1
THE LAY OF THE LAND
Four ways AI shows up in IETF/IRTF
01
Networking 4 AI
Evolve the network to carry AI workloads — training and inference.
02
AI 4 Networking
Use AI to run and operate networks better.
03
AI on the Internet
Let AI systems — increasingly, agents — operate across the net.
04
AI 4 Standards
Point the tools back at ourselves to speed up the work.
2
BUCKET 01 · NETWORKING 4 AI
Building the pipes for training & inference
Model training
Massive cross-node (east-west) traffic. Wants high throughput and low latency.
Inference at scale
Serving results and APIs to users. Wants low latency and efficient connections.
WHERE THE WORK HAPPENS
Traffic engineering, congestion & DC fabrics
TEAS · CCWG · TSVWG · RTGWG · RIFT · LSVR
Fast reaction to faults & congestion (new WG)
FANN — Fast Network Notifications
Energy efficiency in the data center
GREEN
Low-latency transport, DC to edge
QUIC · MASQUE
3
BUCKET 01 · NETWORKING 4 AI
…and the security & privacy side
The use cases pulling on it: authenticating AI APIs, privacy-preserving AI, federated ML, and security frameworks for agentic AI.
WIMSE
Machine-to-machine identity & auth — datacenter, AI APIs, and agents.
OHAI
Better end-user privacy for HTTP services (oblivious HTTP).
PPM
Privacy-preserving aggregation primitives.
These are the pieces the agent conversation later leans on — identity and delegated auth keep coming back.
4
BUCKET 02 · AI 4 NETWORKING
Using AI to run the network
NMRG
IRTF · RESEARCH
NMOP
IETF · ENGINEERING
NMRG explores whether and how; NMOP standardizes the telemetry and data the AI needs to act on.
5
BUCKET 03 · AI ON THE INTERNET
The web-facing pieces — already chartered
AIPref
Building blocks for expressing preferences about how content is collected and processed for AI — training, deployment, use. The consent / opt-out vocabulary layer.
WebBotAuth
Cryptographic identity for bots. As non-browser traffic grows, User-Agent and IP heuristics stop working — how does a site tell a legit agent from an abusive crawler?
Same building-block pattern the agent work is reaching for — and these are already Working Groups.
6
BUCKET 04 · AI 4 STANDARDS
Pointing the tools at ourselves
Where it helps
Where it gets uncomfortable
RASPRG studies how the standard-setting process itself works — so this is the IETF experimenting on its own machinery.
7
BUCKET 03, FOR REAL NOW
The agent-protocol soup
The past year threw off a pile of overlapping ways to wire agents together — MCP for agent-to-tool, A2A for agent-to-agent — first from vendors, now housed under the Linux Foundation.
Widely adopted ≠ an interoperable Internet standard. De-facto open source and IETF rough consensus are different things.
The IETF's question isn't “build the agent stack.”
It's: which pieces genuinely need interoperable standards — and which are already covered?
IETF 126 puts exactly that on the table — three BoFs!
8
IETF 126 · 20–24 JULY
Three AI BoFs
Tue 21
DAWN
Discovery of Agents, Workloads & Named entities
WG-forming
Wed 22
DMSC
Dynamic Multi-agent Secured Collaboration
non-WG-forming
Thu 23
acp
Agent Communication Protocols (agentproto)
WG-forming
9
ACP · THU 23 JUL · WG-FORMING · AGENTPROTO
acp — Agent Communication Protocols
The problem
MCP, A2A and friends grew up outside the IETF — no agreed layering, identity model, or security baseline across vendors.
What the BoF wants to do
Goal
Define protocol building blocks so agents & tools from different vendors interoperate.
In scope
Agent-to-agent, agent-to-tool, and human-to-agent communication.
Building on
MCP & A2A (Linux Foundation) — layering underneath, not replacing them.
Charter framing is explicit: building blocks, not a monolith.
10
ACP · AGENT COMMUNICATION PROTOCOLS (2/2)
What it would actually produce
DELIVERABLES
Session Protocol
Standards-track — long/short-lived, reliable, real-time + non-real-time, over QUIC / WebTransport / MoQ.
Framework
The architectural map of the building blocks and how they compose.
Use-cases + gaps
Informational — what existing protocols do and don't cover.
The hard parts it names
Agent identity distinct from the user (scoped, revocable, delegated authz) · long-lived, low-latency multimodal sessions. Out of scope: discovery (that's DAWN), agent reasoning, and UX.
11
DAWN · TUE 21 JUL · WG-FORMING · DAWN@IETF.ORG
DAWN — Discovery of Agents, Workloads & Named entities
One question: “find me an entity to talk to” — an agent, a workload, a service.
THE PROBLEM
Distributed components with no pre-configured location, reachability, or capability relationship still have to find each other before anything can happen.
PRINCIPAL USE CASES
AI agents are the key driving use case — but the WG deliberately keeps the discovery mechanism generic and reusable.
12
DAWN · DISCOVERY OF AGENTS, WORKLOADS & NAMED ENTITIES (2/2)
Scope discipline, and where it fits
Must convey
Entity type, capabilities, supported protocols, security, and any attestation evidence.
Base
DNS as the likely starting point; build on existing IETF protocols, stay modular.
Reusable
Kept general on purpose — beyond agents, to workloads and services.
Explicitly OUT of scope
Registration · discovery-of-discovery-servers · bulk capability transfer · all communication after the initial discovery.
13
DMSC · WED 22 JUL · NON-WG-FORMING · DMSC@IETF.ORG
DMSC — Dynamic Multi-agent Secured Collaboration
Origin: driven largely by telco / 6G use cases (3GPP TR 22.870) and operator + vendor proponents.
The proposal: an AI Agent Gateway — a network-resident anchor for multi-agent collaboration.
WHAT THE GATEWAY WOULD DO
14
DMSC · DYNAMIC MULTI-AGENT SECURED COLLABORATION (2/2)
The questions the BoF is really asking
Its own self-positioning:
acp = transport between agents · DAWN = DNS-based discovery, no gateway · DMSC = gateway-centric control-plane + ops.
Non-WG-forming — it's gauging whether there's a real IETF interoperability problem here at all.
15
THE INTERESTING PART
How the three fit together
acp + DAWN stay out of each other's way
acp says “discovery is out.” DAWN says “comms after discovery is out.” The building-block discipline, right there on the page.
DMSC is the architectural one
A gateway model that pulls collaboration into the network — and even its agenda opens with “are gateways necessary?”
THE LIVE TENSION
Agents on the open Internet (endpoint-to-endpoint) vs. agents inside enterprise / operator domains (gateway-mediated).
Does a gateway model generalize to the Internet — or is it a telco / enterprise architecture? That's the open question.
16
THREADS ACROSS ALL THREE
The pieces nobody fully owns yet
Identity
Agent identity, distinct from the user
Authorization
Scoped, revocable, delegated
Discovery
DAWN's remit — but everyone needs it
Auditing
Provable record of what an agent did
Observability
Seeing multi-agent flows in motion
Trust boundaries
Open Internet vs. enterprise domains
Each is a candidate building block on its own. Auditing especially is up for grabs.
17
THE THROUGH-LINE
The IETF works best in Lego, not monoliths
At our best
when a problem breaks into reusable building blocks that compose — identity, discovery, authorization, preferences.
What we can’t do..
bless one big, tightly-coupled, bespoke AI agent architecture.
The agent BoFs are the ecosystem searching for the right seams. That's a feature, not a bug.
18
IF YOU REMEMBER THREE THINGS
Takeaways & where to look
1
AI touches all four buckets
…but agents are the contested edge — that's where to spend attention.
2
Watch the building blocks
Track which get chartered — not which architecture “wins.”
3
Follow along before 20–24 July
agent2agent@ietf.org · dawn@ietf.org · dmsc@ietf.org — and drop into the BoFs.
Thanks — questions, arguments, and corrections all welcome.
19