Minutes IETF126: dmsc: Wed 07:00
minutes-126-dmsc-202607220700-00

Meeting Minutes Dynamic Multi-agent Secured Collaboration (dmsc) WG
Date and time 2026-07-22 07:00
Title Minutes IETF126: dmsc: Wed 07:00
State Active
Other versions markdown
Last updated 2026-07-27

minutes-126-dmsc-202607220700-00

DMSC BoF

Wednesday, July 22, 2026
Grand Park Hall 3

Note Takers: Please leave your names here: Linda Dunbar

Chair’s Introduction, 10 min

Purpose of the BoF, non-WG-forming status, working definition of AI
Agent Gateway, non-goals, and overlap guardrails with AGENTPROTO, DAWN,
OAuth, WIMSE, DNSOP, A2A/MCP, etc.

[Joe C] what is AI agent GW? what functions are needed? which venues
can do the work? if there is anything missing that are critical.

Part 1: Problem Statement and Deployment Scenarios, 30 min
Presentations plus clarifying questions

Goal: establish where a gateway is necessary, where it is convenient,
and what an Agent Gateway is and is not.

1-1 AI Agent Use Cases, Requirements and Communication Framework
Considerations of 6G in 3GPP. 10 minutes
Presenter: Shuang Liang (ZTE) / Menghan Yu (China Telecom) [ONSITE]
Related Drafts:

[Joe C] hold the questions to the end.
[Daniel Gillmor]it looks like this is trying to give IETF a deadline
of about 1 year to have a stable WG draft. But this isn't a WG-forming
BoF. Is this timeline plausible?
[Carolina Caeiro] Did anyone define "AI Agent Gateway-mediated
collaboration" yet?
[AiJun W] That is the expectation from 3GPP
[Orie Steele] it might be helpful to provide examples of other NF
activities that exist today, pre-agent.
[Brian Carpenter & Daniel Gillmor] The question should be: why do the
operators want to do this for you? W hy would I choose my network
operator to negotiate on my behalf for any service, let alone an
AI-specific one?

1-2 Problem Statement and Requirements for Dynamic Multi-agent Secured
Collaboration (DMSC). 10 minutes
Presenter: Enge Song (Alibaba) [REMOTE]
Related Draft:
https://datatracker.ietf.org/doc/html/draft-song-dmsc-problem-statement

[Dhruv Dhody] I wish there was more of what needs to be standardized
for interoperation here
[Brian Carpenter] Re his [Enge] talk: in the late 1980s we built
email gateways and file transfer gateways because of diverse protocols.
They were nightmares. These would be worse, much worse.
[Philipp Tiesel] It's funny to see how different the ideas what an
agent gateway ist… based on my dayjob, I would have assumed it's a proxy
that helps with authentication and authorization, does some rate
limiting and emits billing information…
[Antoine Fressancourt] You also have a routing to LLM provider aspect,
as in VLLM's semantic router

1-3 Deployment Scenarios and Gap Analysis for AI Agent Gateway. 10
minutes
Presenter: Linda Dunbar / Bing Liu (Huawei) [ONSITE]
Related Drafts:

[Roberta Robert] About the usecases: why are we considering using
agents for contexts where ethical/fault tolerant fluxes are in play? We
still can't guarantee the behaviour expected from them, there's issues
in sensor swarms... why are we doing this, again?
[Linda Dunbar] Intent is only on the authorized (tested) agents, not
all agents.

[Marie-Jose Montpetit] There is a risk that the agent gateway becomes
a bottleneck and more importantly prevents autonomous (multi)agent
operations where agents are combined based on what functionality is
needed.
[Artur Hecker] some would call it a "feature" or "security function"
\:-)
[Linda Dunbar]there could be many Gateways. Multiple agents anchored
to a gw
[Hesham Moussa] @Linda, is the assumption that the 'many' gateways
will be synced up so each has some sort of a global view?
[Linda Dunbar] I believe the scope is NOT wide internet. Also GW Sync
is one of the functions that need interoperability
[Antoine Fressancourt] I get the bottleneck aspect of intermediation
gateways, here it shows as a logical infrastructure, I am quite sure we
can have distributed versions of the logic element. The question IMHO is
whether there is a role and protocol work needed for this logical
gateway in the IETF
[Bing Liu] For scalable and trusted Agent interconnection, there would
be bottleneck without gateways, e.g. group communication, multicast
streaming etc.
[Antoine Fressancourt]Bearing in mind that proxies are commonly
deployed, especially in corporate environments, without clear standards

[Linda Dunbar] Very good point, Agent GW is similar to API GW.
[Brian Carpenter] Antoine, you can only distribute if the gateway
action is stateless
[Antoine Fressancourt] @Brian I disagree, you can distribute with
session stickiness to an instance (e.g. CATS work)

[Bing Liu]@hesham Zoom/Wechat or any group communication system would
need a central point, maybe not called GW. For Agents across
platform/orgs, there needs to be a third-party central point, which
could be a GW of a carrier.

[Mike Blanche] is it a requirement that your gateway is run by your
telco/carrier?
[Hesham Moussa] I agree, I just don't see why would agents which live
on application layer will want to be anchored on GW of a carrier

[Linda Dunbar] GW is not necessarily owned by carriers. For the
UnionPay use case, the GW belongs to each Bank that exposes its agents
to other organizations.

[George Fletcher] It seems like delegation and authorization are going
to be very complex if the gateway is doing lots of transformations.
[Antoine Fressancourt] @George cross domain authentication /
delegation would actually be easier with gateways sitting at domain
borders and adapting token semantics

[Sam Betts]In LF Agntcy project we've been working on a protocol and
implementation called SLIM which is a decentralised group messaging
system based on MLS purpose built for Agents. We can carry semantic
protocols like A2A over the top, or simply direct messaging with group
broadcast or point to point requests.
[Bing Liu]@Sam Hi Sam, the SLIM is an inspiring solution, who do you
envision operating and maintaining the SLIM Node?

[Lionel Morand] We could discuss the need for GW. But... there are
there. Please refer to the benchmark provided by the agentgateway LF
project. Now, we should concentrate on the main question: is there
anything to be standardized by IETF on this area?

[Linda Dunbar] good question! that is the goal of this BoF

[Antoine Fressancourt]@George As lionel mentionned, gateways will be
there doing this thing in the shadows, so having protocol adaptations to
address some proxy needs can go with the ability to control how proxy
behave, and see what proxies are doing.

[Antoine Fressancourt]I would rather have open standard mechanisms in
the open than DPI based proprietary stuff I can't transparently observe.

**[Charles Eckel] One of the goals is to better understand for the
stated use cases and requirements whether an agent gw is merely a
convenient implementation option or an actual requirement.
**

[Artur Hecker] Charles: I agree. The thing seem to become an
architectural entity, we can then see from the IETF perspective, whether
it should have standard protocols, e.g., for sync, for control, for
discovery (cf. DAWN), for registration, for search, for
negotiations/consensus, etc.

[Antoine Fressancourt]My answer would lean towards "yes", but I think
it was clear ;-)

[Hesham Moussa]Agree with Charles... implementation trick to perhaps
address potential scalability issues?

[Linda D]Agreed. The key is to distinguish functions that can be
implemented directly by agents or applications from those that require a
gateway to enforce shared policy, trust, security, or interoperability
across domains.
[Luigi Iannone] I wonder whether the name "gateway" is the most
appropriate as it seems a bit misleading....Or reducing the
scope..**

[Tommy Jensen] Notably, enterprises already deploy such "AI Gateway"
services today, as the market is creating proprietary solutions to that,
tldr using TLS termination.
[Antoine Fressancourt] @Tommy indeed, so is it a desirable situation,
or do we think a standard would improve the situation?

[Antoine Fressancourt] I would rather have open standard mechanisms in
the open than DPI based proprietary stuff I can't transparently observe

[Antoine Fressancourt] I would think that standardization maybe more
desirable for users than for potential gateway providers

Part 1 Clarifying questions

Part 2: AI Agent Gateway Architectural and Functional Implications, 30
min
Presentations plus clarifying question

Goal: identify gateway functions implied by Part 1, without selecting a
specific architecture or protocol solution.

2-1 Required Functions of an AI Agent Gateway 15 minutes
Presenter: Chenguang Du (Tsinghua) [ONSITE]
Related Drafts:

2-2 Security and Trust Requirements for Gateway-Mediated Collaboration.
15 minutes
Presenter: Chao Shang (Huawei) [ONSITE]

Part 2 Clarifying questions

[Cullen Jennings]So with HTTP Rest style API, lots of vendors wrote
HTTP API gateways that provided high level functions that are similar in
scope of what they do to the things talked about here. Interesting to
look at what standardization they ended up needing.
[Artur Hecker]well, SOCKS was standardized :-)

[Linda Dunbar]That is a useful analogy: not every AI Agent Gateway
function needs standardization. Standards are mainly needed for
cross-vendor or cross-domain interoperability, such as identity,
authorization context, provenance, and policy exchange.

[Jari Arkko] In this discussion I think it might be useful to
distinguish several different functions, clearly discovery is part it.
Closely related to that is policy, as you can't randomly discover things
without also knowing who is allowed to do what. Then there's the concept
of connection routing which can be either direct or via some kind of
on-path entity. Finally there's observability which is not linked only
to on-path observation but also things that we discussed in AUDIT, e.g.,
in-band communication of traces.

Part 3: DMSC Landscape and Landing Zones, 20 min
Presentations plus clarifying questions

Goal: map the functions from Part 2 to existing or potential venues.

3-1 Introduce the necessary protocol extensions and relationship to
existing agent ecosystem 10 minutes
Presenter: Enrique Somoza [ONSITE]
Related Drafts:

3-2 Future DMSC Works when compared with the industry practices (for
example, Agency). 10 minutes
Presenter: Aijun Wang (China Telecom) [ONSITE]
Related Drafts:

[Sam Betts] In LF Agntcy project we've been working on a protocol and
implementation called SLIM which is a decentralised group messaging
system based on MLS purpose built for Agents.
We can carry semantic protocols like A2A over the top, or simply direct
messaging with group broadcast or point to point requests.
[Bing Liu] @Sam Hi Sam, the SLIM is an inspiring solution, who do you
envision operating and maintaining the SLIM Node?

[Roberta Robert] I am really enjoying this session, I think this has
been well scoped, and the proposal about working towards collaboration
with different agencies to bring a standard to this gateway part is
really interesting to maintain an agnostic approach, not dependable on
proprietary approaches.

[Daniel Huang] is the protocol between the GWs? or between GW and
agents?
[Aijun]

Tommy Jensen that makes me wonder how dawn and dmsc overlap (is
discovery solely a gateway problem if the client only worries about
finding/configuring a gateway?)

Part 4: Community Interest and Next Steps, 30 min
Chair-facilitated discussion

Questions:

  • Which gateway functions require standardization?
  • Which functions are deployment-specific?
  • Which work is unique to DMSC, and which belongs elsewhere?
  • What is missing from the problem framing? From the functions?
  • Who is willing to work on DMSC functions? Which parts are most
    urgent/compelling?
  • What are the appropriate next steps: continue on list, refine
    problem statement, send requirements to other WGs, focused side
    meeting, future WG-forming BoF, no DMSC-specific work at this time,
    or some combination?

Polling questions:

  • “Do you believe there is enough clarity on requirements to start
    standardization work?”
  • “Are you willing to actively contribute to that work?”

Discussion at the mic and online:

Andreas Fleming

  • Gateways will likely exist, but it is still unclear what exactly
    they will do.
  • If gateways merely act as middleware or man-in-the-middle functions,
    standardization may not be appropriate.
  • Standardization becomes interesting only when gateways participate
    in a collaborative interaction with AI agents.
  • Existing technologies such as API gateways and firewalls provide
    precedents showing that not every gateway function requires
    standards.
  • The key question is whether specific interfaces or protocols are
    needed between agents and gateways.
    Position: Focus on agent-gateway collaboration, not gateway
    implementation.

Roman Danyliw

  • The discussion mixes multiple environments: Public Internet,
    enterprises, operators, and network domains.
  • The level of abstraction is confusing.
  • A clearer mapping between use cases and deployment domains is
    needed.
  • Some use cases appear enterprise-focused while others target the
    public Internet.
  • Better problem framing is required before standardization decisions
    can be made.
    Position: Clarify scope and deployment context.

Antoine Fressancourt

  • Gateways will exist regardless of standardization efforts.
  • Standardizing gateway behavior may improve outcomes.
  • Standards can increase transparency, reduce proprietary mechanisms,
    and improve user control.
  • Users should be able to control how AI traffic crosses domains.
  • SIP proxy experience demonstrates that protocol adaptations for
    intermediaries can be beneficial.
    Position: Gateway behavior standardization could improve
    transparency.

Philip Tiesel

  • Use cases remain highly diverse.
  • Gateway functions themselves may not need standardization.
  • Control and management aspects probably do.
  • Additional considerations include billing, rate limiting, and
    administration.
  • More work is needed to understand which interfaces are actually
    required.
    Position: Explore management and control interfaces.

Arnaud Taddei

  • Current use cases are incomplete and not representative.
  • Important work already exists elsewhere and should be incorporated.
  • Trustworthiness and safety concerns are insufficiently covered.
  • Questions remain around multi-agent behavior, safety versus
    resiliency tradeoffs, control of autonomous agents, and
    infrastructure impacts of agent ecosystems.
  • More foundational understanding is required before even considering
    a working group.
    Position: The work is premature and missing critical
    requirements.

Nicholas Jones (online)

  • Gateways appear to have two distinct sides: external agent-facing
    interactions and internal infrastructure-facing interactions.
  • Discovery, capabilities, and protocols belong on the external side.
  • Resource assignment and infrastructure control belong on the
    internal side.
  • Gateway specifications must define limits and responsibilities.
  • Very application-specific rules should not leak into gateway
    protocols.
    Position: A gateway has both external and internal dimensions.

Colin James

  • Most successful protocols eventually introduce architectural
    gateway-like functions.
  • Many gateway deployments already exist.
  • The underlying AI-agent protocols are still immature.
  • Until those protocols become clearer, gateway requirements remain
    unclear.
  • Gateways risk becoming the "least common denominator."
  • Standardizing too early may constrain future functionality.
  • Gateway-like products already exist, such as LM Proxy.
    Position: It is too early because the underlying protocols are
    not settled.

Jari Arkko

  • Several independent problems are being combined: agent
    communication, discovery, authentication, authorization, policy, and
    inter-agent connectivity.
  • Policy and discovery appear increasingly linked.
  • Not all gateway-related functions need gateway standards.
  • Some functions may be addressed through discovery mechanisms,
    endpoint implementations, or separate protocol work.
  • The problem should be decomposed into manageable pieces.
    Position: Separate gateway concerns from other protocol work.

Peter Liu

  • Discovery, authorization, auditing, context handling, and related
    capabilities are valid requirements.
  • These may be product/system requirements rather than
    protocol-standardization requirements.
  • The key unanswered question is what protocol problem is unique to
    this effort and belongs in the IETF.
    Position: Distinguish product requirements from protocol
    requirements.

Thomas McCarthy Howe

  • End-to-end architecture and user-centric Internet design are
    important IETF principles.
  • The discussion is still immature.
  • Rushing toward architectural changes may lead to designs that are
    later regretted.
  • Historical experience with gateways should inform future work.
    Position: Protect Internet architectural principles.

Arashmid Akhavain

  • Gateways will probably become necessary.
  • Discovery, registration, security, and communications should each
    mature independently.
  • Only after these functions mature should they be assembled into a
    gateway framework.
  • Work should be distributed across existing working groups rather
    than creating a gateway-specific effort immediately.
    Position: Standardize functions first, gateway later.

Frank Brockners

  • Gateways act as mediators between different systems.
  • Architecture work in organizations such as 3GPP often succeeds by
    focusing on operations first.
  • The topic should be approached from management, operations, and
    administration perspectives rather than trying to define all
    technical functions upfront.
    Position: Start from operations and management.

George Letcher

  • Delegation, authorization, and related mechanisms are prerequisite
    issues.
  • Gateways cannot compensate for missing foundational capabilities.
  • Premature gateway standardization risks solving the wrong problem.
    Position: Solve foundational problems first.

Bing Liu

  • Supports the view that direct agent-gateway collaboration may
    require standardization.
  • If agents collaborate directly with gateways, semantics must be
    standardized.
  • Multiple gateways operating across domains could require
    gateway-to-gateway standards.

  • Inter-domain interaction may be a future driver of standardization.

    Position: Agent-gateway semantics may require standardization.

Charles Eckel (as responsible AD)

  • The discussion successfully focused on problem statements and
    requirements rather than solutions.
  • Existing IETF efforts related to discovery and AgentProto should be
    leveraged.
  • Continued collaboration is encouraged.
  • Many requirements may ultimately be addressed within ongoing IETF
    work rather than through a standalone effort.
    Position: Continue refinement and coordination.

** Chairs' notes **
[Laurent's notes]: pattern: where and how to drawn the lines from what
should remain non-standardized, from what should be standardized (based
on several comment raised in the BoF). Point to be taken by proponents
to bring clarity on the problem space and scope definition

[Joe C]Looks like requirement needs more clarification. There are more
people willing to work on this. There could be multiple ways to go
forwards.

[Charles E] One goal is to talk about the problem statement and the
requirements and focus on that instead of, the multitude of potential
solutions. And I think we did a great job of that.