**Session Date/Time:** 22 Jul 2026 07:00

[00:00:10] **Unknown**: Good luck.

[00:00:14] **Joe Clark**: Good morning everyone. We are going to begin. Welcome to the DMSC BOF. That is Dynamic Multi Agent Secured Collaboration. I am one of your co chairs, Joe Clark. This is my partner in crime, Laurent Chavaglia. And thank you for jumping on the AI train first thing in the morning with us. This is despite not being a working group or even a working group forming BoF. This is a meeting covered by the IETF note well. We want you to read this. Hopefully, you've seen it before. I'm going to let you scan the QR code if you need more information. And I'm going to just pause for a minute so you have a chance to digest this slide. I want to remind everyone, treat each other with respect. Let's focus on the work. We are also using MeetEcho here or MeetEcho. That is not just for the many remote participants we have but also for us in the room so that we can all participate in the same way. This means that if you are here, hopefully you have started either the MeetEcho Lite tool on your phone or the full tool. If you started the full tool, make sure that you mute your speakers or turn off audio and you mute those. If you do wish to come to the mic either remotely or here in the room, please use the join the queue button in the MeetEcho tool and then you can come to the mic. If it was anything like the dawn boff yesterday, there were quite a few people interested in making or asking questions or making points. So that we ask that you pay attention to where you are in the queue so that you're ready to go, when your time, is called or when you're It's your turn to talk. This is our agenda for today. We're going to have this administrivia introduction which we're doing. We'll talk about the purpose and scope of this particular BOF. We will hold off on the terminology. Our part one is going to get into use cases and a problem statement and a gap analysis. Then we'll look and specifically what this notion of an AI agent gateway is and what it is not. We do however have a slide for that to ground the discussion later on. Part two will go into the functions of an AI agent gateway. So in order to address the use cases that we're going to hear about, what must this AI agent gateway have? And then we're going to talk about where the work could be done. What work is needed for standardization? Where that standardization could potentially happen? And where there is gaps in the work that's currently being done or that could be done, that might be DMSC specific. We're going to round things out with an open discussion. So during parts one, two and three, the presentation parts, we ask that you only come forward with clarifying questions. Something that didn't make sense, what do you mean by this, this. And you ask those questions then and hold off on your discussion points, hold off on on more substantive points until the part four. And finally, Laurent and I will go over the the next steps at the end of this BOF. Unlike if you did attend dawn yesterday, this BOF is a non working group forming BOF. That means the intent We are not going to be chartering a working group. We are not selecting any solution. We are not looking at any architecture. We're going to focus instead on the problem space. We are going to make the case, our our proponents and our participants who have been working inside meetings and on the DMSC mailing list are going to make the case for this AI agent gateway. What it is, add clarity to that and why this is important and what, use cases it fills, what gaps it fills. We are not trying to replace other existing work in terms of things like agent proto, ACP or the Dawn Discovery or Auth or Whimsy, A to A, Model Context Protocol, so on and so forth. In fact, some of the work, some of the needs, the functions that may come out of this could potentially inform those other venues where that other work is happening. Instead, what we are doing is we're asking whether or not this AI agent gateway, this mediated collaboration proposes a distinct internet interoperability problem and something that requires standardization and that interoperability in order to solve. That's the kind of clarity that we are looking for today from our presenters and from the discussion in the room and online. What we would like to get at the end of this is some clear input on whether this problem space is real. Whether we have a clarity around the use cases, whether the scope for the the that problem space and the work required is well defined enough. And whether what work is right for the IETF. Is there If there is that work that requires the interoperability, what work is right for the IETF to do? And maybe even bucketized work that might need to happen in other STOs or say an open source. And what discussion? What what clarity on some of where the next step should take us? Because again, this is non working group forming. So we have some, questions at the end. Could this, end up in other discussion? Could this end up in another BoF? Could this end up in other side meetings? What could those next, the outcomes of this be? And we ask that as you listen to these presentations and you think about what you're hearing and you think about what DMSC and this AI agent gateway could be, think about these questions. And hopefully, as you're as you're hearing from the the presenters, as you're hearing from the discussion, you're able to answer these questions. You're able to understand what functions require standardization. On the other hand, which ones could just be deployment specific. What work might be useful to take from this and put into other venues happening here in the IETF. Or what work is is very unique and does solve a problem and does require standardization. That could be unique to DMSC. If there is something that's missing. So obviously, as I mentioned clarifying questions. If something is unclear, ask. But at the end, if there is something that's clearly missing, bring that forward. What functions weren't discussed that are that are very critical, that haven't been raised as part of the presentations you heard. And if there is work that comes out of this, who amongst you is willing to work on that? Invest the time, maybe invest the money and certainly the effort to address this work and do it in the DMSC problem space. And if there is work to be done, which is the most urgent? Which needs to happen first? Which should be prioritized? These are the questions again that we hope you have in mind as you go through the presentations today. Laurent, what did I miss? What did I mess up?

[00:08:15] **Laurent Chavaglia**: Everything was on spot. Maybe just one kind of request. We are going to take notes, but if we can have additional note takers, this is always good to capture what's being discussed and raised by the audience. So, we have the notepad. And if you're willing to serve, please enter your name and take notes. Thank you.

[00:08:37] **Joe Clark**: Thank you very much. All right. We have our first presentation. Charlene? Okay. Cool. You can.

[00:09:05] **Sean (ZTE)**: That's okay. Hello, everyone. This is Sean from ZTE. Thanks for chairs to organize this BoF to discuss what agent AI gateway play a important role in agent multi agent collaboration case. I'm also a delegate from 3GPP. So today, I want to share with you the latest six g progress on multi agent collaboration. And I also want to explain from 3GPP prospect the functionality of AI agent gateway. So please go to the next slide. That's the first slide. That is the overview of city study timeline. In each quarter, three GPP hold a plenary meeting. And between two plenary meeting, there's one or two group meeting to do some detail works. So this timeline is divided by quarter. SA1 responsible service requirement design has completed the study on user cases and the requirement. I can see I I can see here because I can't see it so clear. So sorry for that. So I see the big screen. Sorry for that. SA1 responsible service requirement design. Yes. Okay. That's okay.

[00:10:42] **Joe Clark**: I just wanna make sure

[00:10:44] **Sean (ZTE)**: Okay. Thank you. So you can hear me clear? Yes. Thank you for you waiting for me to see the big screen. I think SA1 is responsible service requirement design, and it has complete the study on user cases and the requirement. It has started a standardization work in February this year. There's a lot of requirement related with AI agent has been addressed in the internal version of our specification defining SA1. SA2 response for architecture and the procedure design is starting the overall of our six g architecture, including the functionality of the functionality related with AI agent. There's more than 100 solution were proposed, and most of them have been merged into TR 21.906. The deadline of the new solution is in August to this this year. And after that point, we will refine the existing solution, and we evaluate make some evaluation. And the the final decision will be in the February next year. At that point, SA2 will decide whether there's agent based interface. If the answer is yes, SA2 may be or would likely to reference IETF protocol. CT responsible protocol implementation design has approved a study item of AI protocol. After the SA2 make final decision, CT will further study the candidate protocol and also makes some evaluation. I think maybe the study is CT group will come back to IETF with some enhancement on IETF agent protocol. The study will finalize in q three twenty twenty seven. So we look forward stable working group draft for candidate protocol evaluation at that time.

[00:13:04] **Joe Clark**: Sean, you you you're only on slide three, and so if you could Okay. Keep going. Thank you.

[00:13:11] **Sean (ZTE)**: Yes. Maybe it's just a little better. Thank you a lot. This slide is about a definition of AI agent defining 3GPP exactly SA1. In 3GPP, AI agent is not defined as a piece of software or application, is defined as automated intelligent entity. Also, the collaboration between the AI agent is emphasized. This definition, we can say that is intentionally broad to cover diverse agent. This agent listed below has been mentioned during SA1 study phase. That's the overall of the agent user cases in SA1 study phase. 62 AI user cases has been listed have been listed. About 25 are related with AI agent. More than 80% AI agent related user cases involve across domain agent communication. So we divide such collaboration between UE, network, and application layer into three part. One is the collaboration between UE and the network. The next one is the collaboration between the network to the between the network and the application layer or service layer. And the last one is collaboration inter network. The requirement derived from the user cases are listed here. You can see that there's significant overlap between the IETF and 3GPP on the hot topic of agent. So in the next slide, I want to share with you the user cases for AI agent communication involved with 6G. And I also want to explain the dependency on IETF protocol from through GPP prospect. Now let's look at the left side of the slide, the UE side. Where agent residing on UE side want to communicate with application agent directly. The mobile operator network acts as an underlying network. That means the 6G network will provide reliable transmission and guarantee the QoS. In this case, 3GPP focus on the information exposure exposed from the application layer to the 6G network, then the 6G network can address the QoS parameter for different kind of AI traffic. When the agent residing on UE side communicate with the agent sorry for that. For the communication between the agent residing on UE side and the agent residing on the service layer, I think, in fact, 3GPP does not really care the communication protocol, but for consistency consideration, we also prefer IETF protocol. When the agent residing on the UE side communicate with the agent in the core network, that means the UE has to use the resource of the 6G network. So the necessary access control management should be performed such as ID allocation, authentication, authorization, registration, discovery, and something like that. Also, one-to-one and one-to-N communication are under discussing. But for the message exchange exchange between the UE and the 6G network, we can reuse the traditional communication framework such as NAS connection or transported as user data. That is some solution in TR 23.700-61. Some company proposed to use a common agent communication protocol. So I indicate the dependency on the IETF protocol here is the potential dependency. Now let's look at the right side. We usually consider the Internet application Internet based application as services. So we call this part service layer or service network in 3GPP. In this case, when some services want to retrieve or write information from network or invoke AI capability as a tool from the 6G network, that means the 6G network exposed its AI capability to external agent or tool. And also, this this communication mode because we really call exposure. And when the agent residing in the mobile network, it receives some request from UE, but it found that we can't satisfy the requirement from UE, it will invoke some agent or tool in the service network. We usually call this invocation. For both cases, I mean, exposure and the invocation, we always think we prefer referencing IETF protocol to integrate into agent ecosystem. Now let's go back to the heart part of this picture. Let's talk about inter-collaboration in 6G network. When the agent residing in 6G network, it received a request from UE and from the third part trusted third party. It analyzed the intent, decoded the message, and then collaborate with other agent residing in the 6G network to complete a whole plan or several tasks. Sure.

[00:19:51] **Laurent Chavaglia**: Please. I mean, you're already over time. So if you could just maybe take one minute just to conclude on your presentation, please.

[00:19:59] **Sean (ZTE)**: Okay. So I just want to clarify in this part, the collaboration inter 60 network, we should prefer use our ITF protocol to reduce the protocol translation. Sorry for that. The next place is the architectural environment, and they're discussing in SA two. The different is that the agent consider as new NF in six c network in the left finger and in the right figure. All lot of functionality related with AI agent is separated into a separate AI domain. The concept of domain is similar as that we called MS domain. I think that's the similar thing. Now let's summarize my presentation. I think from search GPP respect, we think the AI agent is a collection of functionality as listed below, And the functionality provided by the agent gateway may be distributed across different network function in six g network. That's all. Thank you. Thank thank you.

[00:21:12] **Joe Clark**: We'll hold the clarifying questions to the end of the section. So thank you, Sean. We'll move to the next presentation in part one. This is a remote presentation. Anga, are you online? Right. Okay.

[00:21:33] **Bing**: Yes.

[00:21:35] **Joe Clark**: I'm passing you slide control, and we're running a little bit behind. So if you could try to keep your time, that would be much appreciated. Thank you.

[00:21:42] **Amber Sung**: Okay. Thank you. Hello, everyone. My name is Amber Sung. I'm a PM at Alibaba Cloud. Today, I want to talk about a problem that's emerging in LLM inference infrastructure. So that's typically how agent workloads are breaking our traditional per-request forwarding model and why the industry's response is creating a fragmentation problem that only a common layer can solve. This is not a proposal for a new system. This is an observation about where we are today, what the open source community is doing about it, and why those efforts point to the need for AI gateway. Let's start with the problem. Okay. Let's start with the core problem. Inference gateways are not necessarily stateless. They can track k v state, but multiple gateway instance may not share the state or share state via expensive database. Each instance asks one local question. Which GPU has spare capacity now? It forwards the request and doesn't know the correlation between different requests. That worked for independent requests, but an agent task triggers five to eight sequential calls sharing the same system prompt and KV prefix. Without shared task attribution, step one lands on GPU three, step three lands on GPU 1, and the system prompt is recomputed. This triggers prefix cache misses, priority inversion between foreground and batch work, and the premature KV eviction during tool gaps. The root cause is not missing state. It is missing shared correlation awareness. Okay. Go to the next page. Okay. The industry's first response is identity. Add fields that tell the cache layer who owns the request. Mooncake proposed a 12-field agent hints object including workflow ID, step ID, tool name, and so on. The cache scheduler consumes this for DAG tracking and cache eviction, but it only works inside its pool. SGLang proposed the exact same 12 fields. LangGraph has thread ID, parent agent name, but they stay in orchestration and rarely reach inference. OpenTelemetry GenAI has conversation ID and agent attributes, but they are development-level and intended for tracing, not scheduling. The second response addresses SLA, cache lifecycle, and traffic detection. NVIDIA Megatron has priority, strict priority, OSL, and speculative prefill under agent hints. At the route, the routers use priority for the queue ordering and OSL for worker selection constraints. Envoy and the gateway API inference extension uses SLOs, X-Envoy-Expected-LLM-Latency and endpoint picker predicts latency and sheds request with HTTP 429 when SLO cannot be met. For cache lifecycle, Sothek cache control marks prefix, not per request only. SGLang tags Radix nodes with session ID for batch release. It gives gateway a content type anchor. KV-Cache-Flow prefetch the next step's KV. vLLM provides priority scheduling and KV offloading, but leaves policy to the caller. This table post the landscape in one view. 11 products across five layers, Heavy storage, router, gateway, engine, load API, protocol, research, and orchestration. One cake handles identity within its pool. Dynamo handles priority within its router. As a job handles session within its Redis tree, and Sothek handles control boundaries within its API. It will handles traffic at MMD in first SLO. We provide some mechanism prem parameters. The key pattern is not what any single projector does. It is that each source one slice inside one engine with its own naming. None handles a single agent task that spans GPU inference and sandbox execution. Okay. The page six. Okay. Let's make fragmentation concrete. Mooncake and Megatron both use a field called agent hints, same name, different semantics. Mooncake's contains workflow ID, step ID, cache TTL, and reuse hint. It answers who are you and how long should I keep you. Megatron's contains priority, strict priority, and OSL. It contains what treatment do we want, same name, different consumers. SGLang copies Mooncake's 12 fields and aligns with IETF. LangGraph uses thread ID and parent agent name requiring manual injection. OTel GenAI use conversation ID and development-level attributes that may change. There are four products, four naming converse conventions, and zero interoperability. Why can't these projects converge? There are four reasons. First, different layers need different consumers. Identity feeds k b storage, SLA feeds the router, and the cache hints feeds the engine. A flight protocol cannot solve all three without mediation. Second, front end and back end feels diverge. Orchestrate orchestrators known workflow structure. Engine known Third, compact competing standard bodies, ATF, hotel GII, gateway, open headers, each with its own governance. Fourth, maturity asymmetry. Encefka is a production. Mooncake is a proposal. KVflow is a paper. You cannot freeze a spike where inputs are still evolving. All four reason point to the same conclusion. You'll need a layer above these projects that medias between them. Now the strongest argument for gateway, SLA arbitration. Identity fields are objective facts. Faking workflow ID only hurts your own cache hitting rate, So the cache layer can trust them. But priority and as our subjective demands. If clients set their own priority, every class marks itself highest and the field becomes meaningless. If each backend decides alone, priority five means high in one backend and medium in another. We need a neutral layer with global visibility. It computes effective priority as a function of request priority, tenant quota, and cluster capacity. Evidence supports this. vLLM leaves policy to the caller, it requests platform admission. Megatron is only consistent because it owns the router and Mooncake's priority stays inside its own pool. So what is actually missing? Not capability, but composition. Every engine engine we looked at is a vertical silo. Front end contract, contract, back end state, and the policy are glued together. You cannot drop one cake's identity model into Dynamo's router because the contract and consumers are bundled. A gateway decouples three things. The front end contract exposed to agent frameworks, the back end state inside each engine, and the cross cutting policy applied to all. That decoupling lets you upgrade LangGraph without touching vLLM, or swap SGLang without rewriting agent, naming translation, arbitration, and workflow tracking are declared once in the gateway and enforced everywhere. This is why the assembly layer naturally belongs there. To conclude, we need a gateway, not another engine or framework. We need a neutral cross-backend layer that unifies naming, translates protocols, arbitrates priority, and tracks workflow across GPU and sandbox. These pieces already exist. What is missing is assembly layer. This mirrors the shift from layer four to layer seven load balancing. Layer four when the requests were independent, but content-aware routing needs layer seven. Agent workloads make requests correlated. Correlated requests need a state-aware gateway. Thank you.

[00:30:44] **Joe Clark**: Thank you, Nge. Again, we'll hold the clarifying questions to the last presentation in part one, and that is Linda.

[00:31:06] **Linda Dunbar**: Wow. That's a really good presentation. I'm very impressed. So from there, you can the last presentation, we can see that a mediation layer for gateways needed. And and the first one has a very big picture from 3GPP. And here, I'm gonna dive you to dive into a more detailed example in enterprise world, why we need a gateway, what are the gateway functions, and when do we need it. So here's example of a specific project we've been working on. This particular example is the UnionPay that's in China. They basically need to deal with many, many different banks and for purposes of auditing, for purpose of other purposes as well. Here, just show the example of auditing. So each bank has many agents. They may have twenty, thirty agents. And for UnionPay, they may authorize UnionPay to use maybe 10 or 20 of them. And for different organization, they may authorize for using another 20 agents. So different bank have different interfaces. They may have different API calls, and we and they keep coming up with new parameters. And so with a direct, like, a a to a protocol, it doesn't have the policy on who can authorize to use those space specific agents. So this example is really to show that when we have one to many relationship and there is place needed, like, anchor to do the policy control, exposure, like who is authorized to use which agent. And for different organization, they may use different things. So in this particular example, for this UnionPay example, the a two a protocol is not enough because it doesn't have the mediation layer. It doesn't have the control policies exposure, and it doesn't have the auditing trail. And so with this, the main takeaway from this use case is that a need and managed control point for onboarding selective of the agent functions and do the mediation and do the audit trail before many, many organizations can interoperate. Second use case is to see that it's a telecom operator's network. And for the like, earlier in the first slide, they talk about all in general 5G, 6G, big framework. Here, I'm just showing one example. You may have a drone agent. You may have civilians agents. You may have other type of agent, which is mobile, and they may be anchored to different base stations. And then that's on the mobility side. And on the back end, you may have different data centers, and they may have different controls. So in this case I have to say this voice. It's so smart. Cannot see it either. So you need anchor point to control the the onboarding and capability discovery and mobility track tracking. So this is example is really to show that in this kind of agent to agent communication, you need an anchor point to manage mobility and managing the handoff. And so that's the main takeaway from this example to show that for agent to agent communication, you need an anchor point. So well, this has lots of words. This is just to show that in this multi vendor environment, what are the functions needed by the anchor point, the gateway, and also location control. Like, certain locations, you cannot allow those drone to fly. Like, for example, you have set of drones. They can they are only allowed to fly between 5AM to 8AM, and that kind of control policy has to be controlled by the the gateway. And you need onboarding policy, like when the drone anchor to a particular cell tower, you need some policy to anchor it on and be able to advertise its capability to the back end. So this use case is just show that it's more than just communication. You need the policies, you need a common mobility aware functionalities, and you need action level authorization to allow those camera or drone to be in action. Okay. So those two use cases, just a example to show where the gateway function where the gateway is needed. Gateway is definitely not needed for a simple one agent to talk to another agent. For those two use cases to demonstrate what are the needed functions. So for one so for the UnionPay one, you need a cross organization trust binding because for bank a to access bank b, you need a common trust anchor, and you need a policy controlled capability exposure. And you also need audit for whatever transaction goes through, you need audit. And the takeaway from the telecom five g, six g environment, you need network based mobility, and you need the physical action authorization. And you need to be able to do group and basic media coordination. And you need to coordinate cross domain. Let hand off. Okay. So so what is agent gateway? Okay. What it is, what it's not. I don't have to repeat reading them. You can look through them. The slides are on the on the it's uploaded. So because my time is getting off. So from this and we'll show what are the functions needed by the agent gateway and also shows what agent gateway is not because not everything under the universe. And when it's needed, it shows that in the for the simple case, you don't need it. When you have multiple organizations talking to multiple organization, like many to many relationship, you need an anchor point to do the policy control. Okay. So from those kind of functions, we derive five components, those functions that need interoperability. And here are the list of them. As Joe mentioned in the beginning of this is this is really to identify from those two examples, use cases, what are the functionalities? What are the functions that need to be taking interoperability work? So since my time is up, so I'm just finishing it. So the question at this, I guess, we have to discuss at end of this above about those three questions, whether those deployment scenarios are clear enough to evaluate gateway problems and functions. Are there any other deployment scenarios I have missed? And maybe there are more. Thank you.

[00:39:28] **Joe Clark**: Thanks, Linda. And stay around. Are there clarifying questions about part one, about the use cases, about what the AI agent gateway is and is not, and the gap analysis? We have a few minutes for clarifying questions on what we just heard. Everything clear? Okay. With that then, we will move on, since I don't see anyone in the queue to part two. Part two will will focus on the functions of an AI agent gateway.

[00:40:20] **Chen Guang**: Good morning, everyone. I'm Chen Guang. So the talk before my told us where an agent gateway we need and why. So my job is to introduce the required functions of an AI agent gateway. First of all first of all, I want to say that agent gateway maybe is a broader word in in the I I t f in some IDs and people's descriptions. And we think maybe they are they they can in different place, some in the edge edge and some in the on the on the cloud. And we think there are that there has multiple mode. The first one that agent gateway can be act as a proxy, and agent send a message, and the traffic, the message goes through the gateway and arrive the the another agent. And another mode is make the agent gateway act as a directory. So agent can ask the gateway or return some information and address, and the agent gateway a can send message to the agent b directory directory. So through the previous talk, can find people ask a lot for AI agent gateway. There are many requests for AI agent gateway. Here, I group them into four groups. The group one is the control pane. It covers the registration, discovery, information sync, and those functions are related to the gateway's own informations. The second part is the semantic mediation, and it covers the task dispatcher routine and agent selections. And those function makes the agent system more difficult from the traditional applications. And the third one is a runtime data pane, and it covers some protocol adaptation over variability and the management. And those function may be closest to the protocol like a two way and some LLM infrastructures. The last one is the trust and security, and the the this group who will introduce in the next talk, not this. So please note that they are just grouping, not architecture. We think maybe different group group have different stages of standardization. So for the group one, we think that there are four main functions, including the registration capability the capability directory, gateway to gateway sync, and some policies. It makes the agent can enjoy the gateway and share their information from one gateway to other gateway and make it can be discovery by some other users. Together, I think those are the four functions that can manage a phone book of agent word. I also found some draft drafts and the running code related to this group. There are drafts. They specify some registrars, and maybe they define a rule that full record inside the domain and a small digest across domains. And maybe another draft defines, for example, a YANG model, including the subject, the capability, and some states. I also found some open source projects, agent-like agent gateway in Linux Foundation, the Langgraph, and AMP. And those those projects are developed by different companies, but I found they they share the same functions. So I think in this group, the agent gateway mode is mainly like a directory, and the traffic may be not needed to go through the gateway. The second part is the semantic remediation. It includes the semantic routing, agent selections, and some context management. For some complex tasks, they need a lot of AI agents to work for this. So the gateway needs to carry the context information from one agent to another. And the and the gateway needed to fleece the candidate agent and check the constraints and pick a pair. Here, I list some drafts and running code. I think in this group, there are two mode. One is the proxy mode and another is the directory. Some inform some functions require the agent gateway understand understand the messages and do some intelligence functions. For for the for the group three, we list the three functions like the protocol adaptation policies, the infringements, and the the overbears ability and audit. They here, the gateway can translate the protocols as the agent and agent don't need to don't need multiple adopters. And in this group, think the gateway may act act as a proxy mostly. So here we released some running code and and and projects. They also made from many com companies and teams, and they share the same functions. It pointed that the those function are needed by the community today. But for the usage, I found that they may stay the inside of one lab one organization today. And the the cross domain case are still few. So maybe the inter operation requirements is not too high in current state. So move to the last part where I want to discuss the standardization. We're seeing different group has different stages of standardization. For the group one, the functions are ready to use some basic by the fund fundamental functions like registry identity. And there are many drafts and projects we think we we can start here. The second group is the semantic mediation. There are many functions related to some some algorithms, some AI models. So we need to leave this part from from the standardization and stay and we can by the way, can define some interface and some scammers. For the group three, we think we can reuse the existing protocols. And this group will maybe rely on some LLM providers, some LLM infrastructures, and different companies have different requirements and designs. And we think this part is is hard to standardize that today. That's that's all. Thank you for listening. Our

[00:51:38] **Joe Clark**: next functional part is on security, and then we will pause for clarifying questions on part two.

[00:51:53] **Chao Xiang**: Hello. This is Chow Shang from Huawei Technologies, and the topic is security and trust requirements for gateway mediated collaboration. So here you can see at this picture in this scenario, the left side is the server agent identities and user and other applications. All these applications and agents, they share the same gateway. So the all the traffic will go through the gateway, and the other side is service. And the service may include MCP server and other applications and other services. But in this scenario that the left side is they may belong to domain a, and the other side may belong to the domain b. So the point here is the interactions between the two domains be across the trust boundaries. Like we said, there is a gateway or there may be several multiple gateways. So here is the point that what I want to say is that the agents invoke services across cloud and other domains where a gateway or multiple gateways are often already on the path. But there are security gaps in the multi-agent interactions. The first is that the agent actions can outpace human oversight. Second, the identity delegation and purpose can be lost between domains. And third is that raw credentials can be exposed to the agent's runtime, which is what we don't want to happen. And fourth is that service selection and routing decisions are rarely governed consistently. So the issue here is not merely agent authentication. It is safe collaboration across trust boundaries. And in this picture, I want to share two main scenarios. The first one is that the cloud and CAPRs network in this network deployments, the gateway is already there because several you can see at the left picture that there are multiple agents running on the same user device. So at the network side, it really cannot just distinct distinguish which agent and who's it belong to. And these control points are where the cross domain traffic is admitted and governed, which is the switch or what we call a gateway. So the in the right side, it's a home network or edge network scenario. In this scenario, there is usually a router in each home family, like we run several devices and several agents in home, and in this home network, and all of devices within this home network, they share the same router. And these are natural control points, not extra architectural assumptions. So here is the point. Gateway mediation follows the deployment path that already exists. And but what a security gateway adds is three things. The first one is the selection and route. So the first function is to select approved agents and services and select permitted routes and constrain the destinations. So here is the thing that the app authorization and authentication usually happen at the application layer. But if we can solve this problem or if we can set an early boundary at net work layer, so we can we can stop the many attacks such as the port scanning, which is which is the rhythm that the OpenCLOF faced with the first attack. And the second function is protect the credentials, so to keep private barrier tokens and upstream credentials in our world. So in this way, the agent cannot touch the sensitive materials directly. So the gateway can put the put them together, which is the agent request and the credentials from WOT. So the gateway can put them together and send a way to the outer to the external services. And the third function is enforce and record to apply policy, rate limits, and schema checks and auditable decisions in the traffic path. So it also limits loops, isolates failures, translates protocols, and centralized policy without embedding secrets in every agent. And this is the required security requirements for a gateway mediated collaboration. The first is to recognize an active agent and is delegated task. So here is the point that the each domain has its own gateway, but it is the gateway's responsibility to identify the the agent within its own domain. So you have to recognize them to identify the identity of each agent to to enforce the policy, to enforce the access control policies. The second is to keep private credentials and token exchange out of agent runtimes. So here is that the gateway can keep the credentials like in a vault or in other entities to keep that away from the agent. So if there is a malicious agent within its domain, the malicious agent cannot touch the sensitive materials such as credentials, the API keys, and so on. The third function is to enforce policy before traffic reaches protected services. This is the access control or the early boundary I want to emphasize. So currently, most of the authorization happens at application layer. But if we can set an early boundary that we limited the network reachability at the network layer implemented by gateway, we can save a lot of these resources. Because in this way, not every application needed to adapt to the various agents' requirements and to set a unified to set a unique access control policies for every agent. This is the token isolation limits agent blast values. So you can see at this picture that several agents running on the same device or they share my same IP address. So a secure gateway could keep private upstream tokens outside agent runtimes, and to exchange only short-lived task-bound authorities. This is to say that it is possible that every agent has its own basic privileges, but every task, for the same agent, it may perform different tasks at different times, but each task requires different privileges. So a gateway can combine the basic rules of one agent and their every task to get the the gateway can extract the permissions, the task intent, the user intentions, and to find an interception between the basic rules and the tax intent based authorization scopes. So here is the point that the gateway validates the agent and task before using a private upstream token and bind use the agent purpose and destination. Okay. There here is our here is that the gateways are the practical control point. Like Linda said, that a gateway is already there, and it is usually act as a control point. So existing gateways can combine animation, policy enforcement, credential brokering, rate limiting, and audit at the boundary. And per agent identity and the task context survive aggregation. So one thing that we should consider is that what should we do in the ATF because there may be a lot of standards that are currently running to solve this problems that we proposed. For example, the identity, there are WIMSE and RATS to solve the identity problem. WIMSE solves the workload identity, and RATS solves the attestation. And the second is the scope. There are other groups like OAuth, and there are maybe many drafts to solve the authorization chain, like the transaction tokens and the exchange of the different tokens. And the third is how to preserve the accountability. That is, how do the two gateways collaborate with each other? How can we like, the one agent in one domain can be trusted by another agent in another domain? That is the main problem of the how to achieve a security a security collaboration between the gateways. So there are six points that we might be want to consider. The first is that the agent workload identity profile. Well, this might can be solved by the old implementation within one gateway, within one domain. The second is that gateway decision exchange. Well, this is the questions that maybe needed to be addressed between the collaboration of different domains of different gateways. And third is the task sub scoped authorization. Well, this is the how to how can we find the interception between of the basic rules and the intention based authorization scope. And the fourth is the trust evidence binding. Can existing methods bind evidence to the agent gateway and the surgeon? This is the question that we need to consider. And the fifth is the audit reception recepts. So this is the issue that how can we achieve that what agent in one domain can be trusted by another agent or another service in another domain. And the sixth is the server selection and routing metadata. So are interoperable service selection and route authorization body missing? So the new work should be considered only where our concrete interoperable protocol gap remains after reuse analysis. So here is the conclusion. An a secure gateway is the control point that makes multi agent collaboration deploy deployable and trustworthy. It rules approved interactions, keep private tokens out of agents, enforces list privilege, and records accountability. And the second is that a standards work should be reused first and coordinated first, validate remaining Internet protocol gaps with WMC or OAuth and RTUT before pro proposing new ITF work. That's it.

[01:04:44] **Laurent Chavaglia**: Thank you.

[01:04:45] **Joe Clark**: You. Clarifying questions on the functions of an AI agent gateway. No? No one in queue. Perfectly clear. Our third part aims to explore where the work that has been framed thus far could be done. What work requires that standardization, that interoperability? We have two presentations there, and then we will get to the open discussion. The chat has been very busy. And as Laurent pointed out, if people in the chat, during that open discussion can make your points, that would be fantastic. I believe our next presentation is you, Enrique.

[01:05:47] **Enrique**: Alright. Hey, guys. My name is Enrique. And on part two, we talk about all the requirements that we need for an AI agent to work. Now this session is going to be all about where those requirements belong before in the work that we already have going on. So think about these such as a mapping exercise rather than thinking about creating a new draft. We eventually will get there. But the idea is that we want to map and see what's already there, what we're missing, and how can we fill the gaps and where they fit between what's already done and what we discussed in the first and the second parts. All right. So starting here, one of the things that we see in previous conversations is the trust decisions get bundled into one trust decision when essentially there are three. We're looking at three different three different type of problems. The first one is the session level. So this is where we ask the question, can these two agents talk? There are a few things that we look in there. It sits at the protocol decision and looks into onboarding, discovery, routing, capabilities, postures, and so on. Now once we define that those agents can actually talk, then we go to the next question. Can they actually execute something? Now this is not a network decision anymore. It's on the protocol decision. And it's all about agent boundaries. How do we handle them? What are they allowed to do in different identities and admissions and executions that they have? Now the third part is the record level. So here is where we ask what they actually did. And, you know, for us, we're looking at a way to each agent, each organization to understand what was done rather than just confirm and validate and asking the other agent. So they should be able to know what happened. And again, this is not a one-sided thing. This is each organization should be able to understand what's going on there. Now the good news is that there is a lot of work going on in the ecosystem. So whatever way you see it, whatever way you read it, there's about two twenty five draft already across different categories. So looking at messaging, identity, discovery, naming, you can see all of them there. So the problem is not that there is not work going on. The big gap is that there's really nothing going on that's just based on the AI gateway itself. So this creates a lot of opportunities for us to be able to utilize what we have already but also create a new draft there. Now when we set the boundaries, we see and based on the three different steps, there's a lot easier to understand really what's missing at each boundary. So for example, the session boundary, we're missing framework built in. We're missing policy based access. We're missing network mobility. Then at the action boundary, we're missing, you know, some of the mediation handoff. As well as the record, we're looking at the observability that allows different agents to understand what was done and how it was done and be able to audit that. All right. So once we map these to three different trust models, it's a lot easier to understand really what needs to be a standard or not. There's obviously things that we have to standardize such as, you know, being able to understand and verify how domains they get checked, how do they work because obviously we need to understand how they talk to each other. The other one is that we need to understand what's the intent of each agent and the authority and what type of stuff they are allowed to do. So those things that, you know, they actually have to become a standard so that it can work across multiple organizations. Now there is already work that we can utilize. There is OAuth. There is WIMSE / SPIFFE. There is SCITT. There is COSE receipts. And, obviously, those, you know, we gotta take advantage of that and just reuse whatever is there. And then lastly, we leave deployment-specific stuff to each agent, each gateway, so how do they do audit, how do they authorize and track what's going on. The idea is that we want to understand really what's going on from end to end by creating new standards, but also utilizing the standards that are already in place. Now so this is an example of draft that exists at each boundary. This doesn't mean that these are accepted, that these are the ones that you have to use. These are just examples that we can see each of the three boundaries that we created. So the session boundary, we can see AGTP. At the action boundary we can see ATN, AML. At the record boundary there is the SCITT and the COSIC red seats as well as ATN session red seats. Again, this is just to show you that there is already work going on and the idea is that we want to map these to a place that we can use them. And not just that, but be able to understand where the gaps are and what's needed to be able to deliver the AI gateway. Then lastly, I know we're gonna be answering these questions very soon, but I'll leave you with these questions, and then we can go there.

[01:11:38] **Joe Clark**: Thank you, Enrique. Our final presentation, if I can do this, is from Aijun on

[01:11:50] **Laurent Chavaglia**: sorry about that.

[01:11:53] **Joe Clark**: On where this future work could happen and what is happening in the industry.

[01:12:02] **Nicholas / Aijun Wang**: Okay.

[01:12:05] **Aijun Wang / Daniel Huang**: Here, I want to make a pavement for the future DMSC work, considered after the use case material, industry practice, and capabilities. We plan the future work compared with the current industry practice. The first thing is industry practice from the Agent-as-a-Service project from the Linux Foundation. I think it is from Cisco. And, currently, the aim of the project is, I mean, ours. They they want to build the Internet of agent. Currently, provide the forming function from the project. The first day is agent direct service. They they build the direct service based on the capability agent capabilities. And the second is the Slim protocol. It is the exchange protocol between gateways and the traditional gateway and the SAP can run on top of it. And the third function is the observability of agent activities, and lastly, the identity consideration. This is the main content of the Cisco Agent-as-a-Service project. And the second, we see it from Google, they also propose some agent gateway functions. And here, you can see the main functions are also similar with Agent-as-a-Service. First, the agent registers to the gateway based on the attributes and the metadata. And the the second is the access control. And the third is the AI AI security. And I heard mister So has planned the requirement from a security consideration. And the last is the operator. And based on the AI in the gateway, it can provide the the following functions. For example, the centralized governance for, you know, interacts and the AIT AI security and comprehensible operability operability. So we consider the alignment with the industry for the DMSC experience also from four aspects. The first is the agent advertisement. You know, from the two industry projects, we can also build the infrastructure for the capability agent advertisement. And and for the they also and both consult consider the trust and identity and the also the the abilities. So here is the the the plan aim of the DMSE fault. You know, our aim is the one to connect the all kind of agent that are located in the cloud or in telecom or in other domains and why the AI is in the gateways. And we think the based on the function of the AI gateway, there are three main category of protocol at at the it can be explored in the DMS. First, they use the interaction protocol between agent and the agent gateways. The interaction is based on the intent. And the second is the signaling protocol between the gateways. And the third is the exchange protocol between gateway and external protocols. We think this kind of category protocol can be accomplished in future in DMSC. And we also can also consider further functions, for example, the OAM system for the configuration, governance, and observability over the AI agent activities. So here is just briefly starting the interaction protocol between AI agent and AI agent gateways. I explained that the interaction protocol is based on the intent. So the gateway should know the intent of the sender agent and route them to the suitable agent. And we want to define some gateway operations, for example, capability advertisement, and agent state, and the signaling among the agent gateways. So here here is some inspiration from all the in touch for the future DM is a protocol extension. The first is we want to do the standard work based on the capability-centric routing. We send the capability as the routing primitive, instead of the endpoint names. So we want to build the capability-oriented advertisement and also capability-based routing. And we want to build the infrastructure in the distributed mode, so we call it federated. The AI agent will register into the distributed gateways. So we will define the signaling protocol between the AI gateways. And we also consider the observability and the interoperability across different domains. So here just some summary for the why the AI gateway matters. So we it help in the imperial parent. We think the gateway provide one nature interoperability point between a eight year old agent exos exos ecosystem and the DMSMA standard agent gateway around the protocol instead of a radio redefine the agent framework. And so we think that the future protocol may focus on the onboarding to the gateway and the gateway signal signal signalized and trust the update and availability and operational management. So the the the the the final thing is we think the gateway and the it's just to understand now the protocol are the first step to build the capability based internal of agent. Okay.

[01:19:33] **Joe Clark**: So, we have a few minutes for clarifying questions on part three, on the mapping of existing work, on the venues it could be done. Daniel Huang, you're in the queue. Did you have a clarifying question?

[01:19:47] **Aijun Wang / Daniel Huang**: Yeah. Actually, you're talking about the agent gateway around the protocol. So I'm wondering if the is this protocol what will this protocol be coordinated with? Does the agent agent protocol or a stand alone protocol? Seems to just kind of, I mean, interconnection between the gateway as well as the gateway and the agents. So so what the relationship between the edge the gateway around protocol and the agent agent in protocol.

[01:20:26] **Laurent Chavaglia**: Yeah.

[01:20:34] **Aijun Wang / Daniel Huang**: Would you like to clarify more clearly for I

[01:20:37] **Nicholas / Aijun Wang**: Yeah.

[01:20:37] **Joe Clark**: The the the acoustics acoustics in this room are interesting. If you could just rephrase your question maybe a a a little bit. It's kinda hard to hear in here.

[01:20:47] **Amber Sung**: Okay. I'll

[01:20:48] **Aijun Wang / Daniel Huang**: I'll talk to you now.

[01:20:54] **Laurent Chavaglia**: Maybe if you could put it in the chat, we can take it in the last part if you wish. Thanks, Adrian. We are now going to lead on part four, which is the open discussion. We will be having set of leading questions for the audience. This is the time also where we welcome people to come to the mic and raise your observations. As mentioned, there have been a lot of very interesting points made on the chat. So, if you want to raise that, please do it in meeting. We can also give the opportunity to presenters or proponents to provide answers to those questions. Yeah. Joe, if you want to go over that.

[01:21:42] **Joe Clark**: Yeah. So, part of our job, Laurent and me, we have to, with Charles, I I guess I forgot to mention at the beginning, he is the responsible AD. It was mentioned a couple times in chat. We have to decide what the next steps are with this. We have to help answer some of the questions you see up there. Is there work to be done? Is there standardization work to be done? And if there is, does it happen here in the IETF? And if it happens here in the IETF, where does it happen in the IETF? Are there existing working groups? Are there working groups to be newly formed where this work could happen? Or is there net new work that could justify a new working group in the future? These are all questions to answer. We want and we need your input to do that. And as Laurent said, the chat has been robust. So we do hope that you help make our jobs a little bit easier and share your points. If you have just statements to make, fine, please do make them. If you have questions that the presenters or proponents can help answer, we hope you allow them to jump the queue so that they can answer those questions. And we have the remaining almost the remaining set of the time to for this open discussion. We will wrap things up with some talk of next steps and some words from Charles. So open discussion. Bring it.

[01:23:19] **Laurent Chavaglia**: Fleming.

[01:23:29] **Fleming Andreas**: Fleming, Andres. So I don't disagree that gateways are gonna be existing. I think it's an open question exactly what they're gonna be doing and how they're gonna be operating. Are they gonna be man in the middle kinds of functions? In which case, I don't think we wanna start standardizing that. Are they gonna be collaborative entities that the agents might, you know, work with, and therefore, have a certain function with an open interface that might be something that we do wanna work on. Overall, I would say, I mean, we can look at existing API gateways, firewalls, etcetera. They have a number of different functions. We don't try to standardize those, and I don't think we should do something like that here either. So for me, it comes down to, again, is there a collaborative effort between the agent and the gateway? And if so, are there certain interface and protocol requirements as a result of that? That might be something that we wanna work on.

[01:24:22] **Joe Clark**: Roman.

[01:24:24] **Roman Danyliw**: Good morning, Roman. Danilo speaking as as an individual. Thanks for all the presentations on the use cases and functions. To answer the question, what might help with the problem framing? I had a lot of confusion around when we talked about the use cases and the overlay of the functions, what's expected for the public Internet, what's expected inside kind of enterprise. When we talk about domains, we talk about operators. When we talk about the network, I found the level of abstraction kind of confusing, not exactly kind of understanding how how we're ring fencing this. And so I think that might be that might be helpful to kind of clarify and kind of crosswalk as we figure out, you know, with kind of precision what we're in fact kinda talking about because it seems like some of the functions were more enterprise focused. Some of them felt much more kinda focused for the public.

[01:25:14] **Joe Clark**: Do any of the proponents want to clarify that?

[01:25:21] **Aijun Wang / Daniel Huang**: Kindly, we just want to describe the necessary of the AI generated from a different different scenarios. I think in future, we can collab collab if if if if I'm collab them together to make them more more coherent. Okay.

[01:25:45] **Joe Clark / Laurent Chavaglia**: Antoine?

[01:25:46] **Antoine Fressancourt**: Hello. I'm here to echo some of the discussions on the chat. In the chat that was discussed that gateways are going to be there, whether we stand on the same whether we standardize them or not. And so the question is whether the situation would improve with the standards for the behavior of those gateways. So now that that is a debate on the chat. My personal opinion is that if you have a standard for the behavior of gateways, it will improve the situation because instead of having mechanisms that are proprietary and insufficiently transparent to users, you allow a much more controllable, transparent, and desirable deployment for users that will control how their AI traffic is steered, especially between domains, and how the protocol is adapted at the borders of domain to serve their purpose. And one examples of adaptations of protocols to cope with proxies, I can think of is a session initiation protocol where there is a bunch of errors to cope with operation of proxies on the past. And I think this kind of adaptation in the open was beneficial for the operation of voice over IP system in the wild.

[01:27:10] **Laurent Chavaglia**: Okay. Thanks, Antoine, for raising this aspect of the discussion. When we were also discussing with the proponents building up on the both, we were having a bit these questions about what will fall more into, IEC, deployment considerations or even implement considerations, deployability of the such gateways versus also the required standardization work. I I want you to say, for instance, on which are the behaviors of functionality that needs to come with some level of standardization. So if people wants to clarify also if they believe it falls more in one of the other bucket, that also can lead to understanding what the ITF could do.

[01:27:49] **Philipp Tiesel**: Philip? Philip Thiesl. Based on what we have seen yesterday in DAWN and today, despite this is not a working group forming BOF, I'm quite intrigued to see how clear the use cases still were and how diverse the use cases were. So I think it's definitely worse following the path more along. But we also see clearly that there's not too much standardization about what the gateway does, but probably how it is controlled, how it is administered and which kinds of aspects need communicating. So what I've not seen here is signals such a gateway would probably have is billing at rate limiting, which also would come into that consideration besides everything that was already mentioned. So I think it's worth going on and exploring which kind of interfaces such a gateway needs for the diverse use case we already mentioned and also sharpen the use cases We'll probably have some of the discussion about the use cases here, also sharpen the output of DOM.

[01:29:11] **Joe Clark**: Thank you. It's good feedback. Ah, no.

[01:29:21] **Arnaud Taddei**: Right. So Arnaud today, and I'm wondering where to start. Alright. So the the issue I think I have is that when I looked at all the presentations is is the myopic view on some use cases and the limits of what this is encompassing. What surprises me a lot is that most of these are coming from constituencies from one country. And what surprises me even more is that the people who are coming from those in their country don't seem to speak to their own teams in their own organizations because there are other venues where these problems are not only addressed but correspond to a very clear strategy for some of these constituencies and that are addressed elsewhere. So the issue I have again is that, like the previous speakers, I don't think the use cases are neither complete nor exhaustive nor even for some of them correct. And so when I see, for example, the definitions or what you try to put as specifications on the control plane of the gateway, I'm missing a lot of things. How are you going to manage the trustworthiness of your multi-agent AI, multi-objective AIs? What's going to happen when they are going to make the wrong choice of resiliency versus safety? You want to have a 6G network managing whatever, the data center fails, the agents that try to do something with it. But in some cases, if this network is dealing with a nuclear power station, I'm just making up an example, you don't want to make it resilient. You want to shut down everything. So how are you going to get your agents under control when you have no idea how do we decide? The problem is that you have people who are not here speaking about AI ecosystem that would show you that on massive tests, they realize that the agents have a side effect and a strong one from their behavior, multi agent behavior on the infrastructure. So I'm missing even some basic specifications in what should be the functions of a gateway or a control. So I'm not even answering the question, is a gateway good or not? But I'm saying that there are a lot of information missing, and this is done in other places. I'm going to say which ones. You know which ones. And I would recommend that this one is much deeper studied because at the moment, this is premature to have even a working group.

[01:31:56] **Joe Clark**: So, thank you, Arnaud. So, again, not working group forming, but if I summarize what I think I heard from you is there are still questions to be answered about the applicability or veracity of some of the use cases and definite more discussion needs to happen to hone or refine them, before any more substantive next steps could be taken.

[01:32:22] **Joe Clark / Laurent Chavaglia**: Yes. Okay.

[01:32:26] **Joe Clark**: Nicholas. Ah, online.

[01:32:30] **Frank / Nicholas**: Hello.

[01:32:31] **Nicholas / Aijun Wang**: Yes. I'm online. Nicholas, independent attendee. You know, just some observations from the the discussions, the presentations that were made. It it seems that the the gateway would have two different aspects to it. It seems there's definitely a context for the conversation between the agent and the gateway, which would involve various standards and layers and technologies. And then there would be a separate aspect for where the gateway faces inward towards the infrastructures and the service providers. So it's interesting that that seemed to come up or seemed to be a pattern inside the discussion. For example, there's talk about capability discovery like WIMSE and RATS and things like that on the output side. And then there was a a presentation about, you know, discovering, you know, assigning jobs to to resources and and and hardware on the internal side. So it seems like the specification would definitely end up having two aspects to it. And one final observation was there was a use case about drones being restricted to certain times of day. That seemed like a very functional and specific restriction, and I wondered if that probably did not belong explicitly did not belong in the gateways protocol. And therefore, the the gateway spec should definitely have limits on on what it can observe and what it can be part of. And then beyond that, it's not privy to those very specific, you know, functions and layers. And I think that should be a part of the the the standardization as well, where the where the where the responsibility ends. Thank you.

[01:34:18] **Joe Clark**: Thank you, Nicholas. I'll also remind people who have spoken. I think Linda's helping with notes. I think Laurent's been helping. If you wouldn't mind looking at what the notes page and making sure what you said was properly captured so we can go back to that, that would be very helpful. Cullen.

[01:34:37] **Cullen Jennings**: Cullen, James. So so I think that one of the I mean, I think nearly every successful protocol has had an architectural element eventually created for it that is like the like this type of gateway type thing. You see, for all the reasons needed in here, there there is a need you know, people will build and and and deploy these for a bunch of the use cases described. I don't that doesn't most of those are not standardized, by the way. Most of them work fine by just the underlying protocol that you were using to talk to them provided enough information that you didn't need to standardize beyond that protocol. And I think that that's one of the problems that's really difficult about thinking about this right now at this point in time is we don't actually we don't have much agreement on what the protocols are. You're gonna be running through this gateway. And that makes it really hard to figure out what's needed, what additional standardization work is needed to make the the gateways work well. So I think that that's one it oh, it's a it's a sort of timing issue thing. So I think as those protocols evolve more and we see more of them, it will refine to to various things. And I'm, you know, I mean, like, my group builds a prod like, we have a piece of software called LLMProxy, which is exactly one of these things you're talking about. I mean, people are already widely building these. But whether you what standardization we need, I think will be much easier to talk about as the actual protocols themselves evolve. I was also gonna make a completely separate comment, which is just these gateways are always limited by they're the least common denominator of what you can do on both sides of the gateway. And this is, you know, Iran's law of gateways is is simply that. And we need to think about that as well when we're trying to figure out what the use cases are, particularly where what we're talking on both sides is a little bit different. So I think that that's another area that would really help people think about in thinking about what needs to be standardized is how to make sure that Iran's law of gateways doesn't push you down to the minimum bar and that you can still do the functionality you need.

[01:36:33] **Amber Sung**: Thank you.

[01:36:35] **Joe Clark**: Thanks, Colin. Yari.

[01:36:37] **Unknown**: Yari, Ericsson. So plus one to Colin, first of all. But I came here to say that we should probably distinguish a couple of different things in in this discussion and try to understand the standardization impacts on on each of them. So, clearly, one needs protocols to talk to agents. That's largely being worked separately from this meeting, I think. And, of course, there's plenty already and might be more from the ITF. The same for authentication and authorization aspects. We also need discover defined agents, and we talked about that yesterday. One thing, though, that I learned today in this meeting was that there's a lot of policy issues around that. So and that they are kind of the discovery and policy are interlinked because you can't just, you know, return the best match, but consider if if this is allowed for this task and so on. So maybe that's a thing to take home for for the discovery part of discussions, make sure that policy can be included in that. We also need to connect the different agents together, and I've been mostly thinking about that in terms of direct connection, not through proxies. But it's, of course, true that there can be cases where where you you want to have a gateway. The question though for standardization is, you know, do we need to specify some of that, or is it enough that we just point to an endpoint that just happens to be the discovery agent or or a particular gateway, and it's not really visible on the protocol level that you're talking to a gateway. And also the same things that are true for firewalls apply to to these gateways that gateway is not the only place to execute policy or make sure the policy is is followed. You can also have code on the endpoints. Finally, there's elements of discussion of of the audit side meeting around, for instance, having inbound communication of some tracing data. And I think that's a separate thing that we should do separately. So maybe not all of this stuff needs to be done in one place. One option here is to grow the the discovery scope a little bit in in this this regard to be able to discover to to app apply policy and so on. So that would apply that would that would solve part of the problem. We could, of course, write documents that talk about how to put several things together, like the system thing or a document that says how to translate from protocol x to y. But that's that's how the issues that Colin pointed about. So thanks.

[01:39:11] **Joe Clark**: Hi, Sherry. Peter.

[01:39:15] **Joe Clark / Laurent Chavaglia**: Hi. This is Peter. This is a question mostly about technical requirements of a product versus protocol standardization requirements. For I think there are different components or different things that we have mentioned or I have here. It's about something like discovery, some like communication protocols, like authorization, context handling, like audits. So, yes, I think those are great product requirements. It's just I don't know if ITF does this kind of things Because all those kind of things when it comes down to protocols, it has distinct homes for them. So we might redirect says we should be doing this at there or doing this at there. Okay. That's perfectly fine. The question that I'm asking is what is unique protocol standardization work that should be happening here? Might be a open question. Thanks.

[01:40:07] **Joe Clark**: Yeah. That that is one of the questions we're getting to to Colin's point. Maybe things are very nascent in in the AI space. And I think I saw something in chat about even though they may be nascent, it doesn't mean that the work here can inform some of that work so that the use cases, even if they are, Peter, to your point, product requirements, can help make deployment of these gateways and satisfying these use cases possible in the future. Thomas, you're next.

[01:40:40] **Thomas McCarthy-Howe**: Thank you. Thomas, McCarthy Howe, Viconic. So, my comments are a little bit more of the upper level spiritual thing here. And what's really screaming out to me is there's some things here that you which are really long term important to the Internet and the IETF, things like the end to end principle and the fact that we work, you know, for the end user. And my my gut tells me this is way too early to be just to think about moving into this direction because there's so much which is left un understood. I'm not saying that gateways are bad, but I'm saying that gateways are bad. We all have our scars from it, and sometimes they're necessary. And without, I think, more maturity in the market, more maturity in the problems we're trying to solve, we're likely to come up with a design that we're gonna regret. So I think it's early for us.

[01:41:42] **Joe Clark**: Thank you. Rashmud.

[01:41:47] **Rashed / Rashmud**: Hi, Rashmud here. Plus one to Colin and Harry. Gateways, I'm not against them. I think gateways are going to be a necessity at one point. Whether they are necessity now, I heard a lot of different functions here that we are trying to put in a box called a gateway. First, those functions have to evolve beyond their existing state, for example, discovery. And then we will find out whether discovery requires a specific gateway type of format to actually continue. Registration is another function. Security I hear security. I hear communications. These are all good points, and we can put them in a gateway to focus the the the the cross domain interaction. However, these are different functions that they will be standardized in their own way, and then we will put them in a box called the gateway. So, I'm not sure how the best way is to divide this functionality into pieces and actually address them in a different working groups or existing working groups that, we can actually go forward with.

[01:43:06] **Joe Clark**: Thank you. Yeah. And and we're collecting all of this to understand what it is that we wanna tell Charles that we wanna say to the proponents as to where do what what is this next thing to happen? Where could some of this work to to help these organizations, to help these other groups like 3GPP to satisfy these requirements. So we do definitely appreciate the feedback. I'm sure the proponents do as well. Frank?

[01:43:38] **Frank / Nicholas**: Yeah. This is Frank. So what has I agree with everything that's been said. Like, so there's a bag of things here, there's another bag of things here. And you need a gateway or some sort to go and connect these two bags of things and do some whatever mediation translation. And we've seen that from an architecture perspective in many forums like 3GPP. And what has worked in the past is rather than focus on the bag of things and how to align these things, maybe we can start from how do you manage this thing. And we've built even, like, back in the days in diameter, we've built applications for how do you manage this thing without actually completely understanding what these individual functions are that we need to go and connect. So maybe we can approach it more from a how do you operate this entity perspective rather than what are these exact functions that you need to go and fit from an interoperability perspective.

[01:44:36] **Joe Clark**: Always like to hear things about operations. Thank you, Frank. Did you wanna the queue is, I think, empty at this point.

[01:44:47] **Laurent Chavaglia**: Yeah. We just had I mean, it was if I'm correct, George Fletcher was in the queue. So, I mean, you can still raise your comment if you want. Please rejoin, but then I would like to close the queue to raise the polling questions.

[01:45:05] **Joe Clark / Laurent Chavaglia**: So yeah.

[01:45:10] **Laurent Chavaglia**: No. No. We are not reopening the queue. I mean, just one more clarification.

[01:45:14] **George Fletcher**: Just me? Alright.

[01:45:15] **Laurent Chavaglia**: How much do we want to end up?

[01:45:17] **Rashed / Rashmud**: I don't need

[01:45:18] **George Fletcher**: to say

[01:45:18] **Laurent Chavaglia**: it. No. No. No. I mean, you are okay. So let's say. Alright. Can you Sorry. Give us a second. Okay.

[01:45:31] **George Fletcher**: Okay. So I was just gonna say to carry on what some other people said, I think there are other really important problems we gotta solve to make the AI stuff work, delegation, authorization, other kinds of things. And if those things don't get solved, the gateways aren't going to help. The so I'm a little bit worried about trying to tackle a protocol or some sort of standard for gateways before we've got other bits of the the overall solution space figured out?

[01:46:12] **Joe Clark**: Bing?

[01:46:17] **Bing**: If you're

[01:46:18] **Joe Clark**: talking, we can't hear you.

[01:46:21] **Bing**: Thanks for opening the queue again. And I want to echo to the first comment by Fleming. If we can agree that the agent needs some collaboration with the gateway, not only by some underlying proxy overlay, We will need some semantics to be to be standardized. For example, just like the router at of assessment or the DHCP, the the host. So in our case, it's a agent that to collaborate to interact with the network node. And furthermore, if it is in scale, if people can agree, there will be multiple gateway deployed in a single domain or cross domain need to be interconnected with each other, then there will be a standard that need between the gateways. Yeah. I I I think that's the two essential point. Yeah. Thanks.

[01:47:31] **Laurent Chavaglia**: Thank you, Bing. Okay. So we are closing the queue for questions now. We would like to poll the audience on a couple of questions to measure a bit the level of support on those on future steps. So I will run the questions, and so please use the Meteko application to enter your your poll.

[01:48:01] **Joe Clark**: Looks to be. It's always good to get hard data for our AD. So, do you believe there is enough clarity on requirements to start standardization work?

[01:49:02] **Laurent Chavaglia**: Yeah. So numbers are stabilizing. We will close the poll. Thanks for the inputs. Okay, let's close the question now. We have a second question coming. The second thing is, are you willing to actively contribute to the DMSC work? Okay. Now things seems to be stable in terms of input to these questions. We are going to close it. Thank you. Alright.

[01:50:38] **Joe Clark**: It's that time in our program where we get to the possible next steps. I found it interesting that there seems to be a need for, more clarity before standardization work begins. But there are quite a few, more than not, people willing to work on that. So that can help inform us about what comes next. And the things that could come next, and it doesn't need to just be one of these, we could continue the discussion on the mailing list or hold additional side meetings because I know logistically that side meetings are just fantastic, aren't they? We can refine the problem statement further and it sounds like maybe based on the polls in the room, that would that's what needs to happen. And we can pay attention to I know many of you were in Dawn yesterday. We can pay attention to what's happening there in groups like Agent Proto and other working groups that have formed to make sure that the needs for the gateway, the things that were brought up here and the the the discussion like Colin mentioned that things are still nascent, that these needs can be considered. There sounds like there is sufficient interest in in some level of work in this area of gateways whether or not that needs to be new work or can fold into others. These are the things that we're going to need to discuss. And this can all again, doesn't need to be just one of these things. We can work on multiple fronts. But we do have quite a bit of feedback in room. So we have the minutes. We have the chat transcripts. We have these two polling questions. We appreciate the feedback. And Charles, would you like to say anything to our audience as the responsible AD?

[01:52:25] **Charles Eckel**: Yeah. So Charles Eckle here. Yeah. I'd love to say something. First of all,

[01:52:30] **Laurent Chavaglia**: well, is it on?

[01:52:32] **Charles Eckel**: Yeah. Thanks to, you know, Joe, Laurent, really, proponents, everyone, because one of the big asks was to uplevel the conversation to talk about the problem statement and the requirements and focus on that instead of, you know, the multiple multitude of potential solutions. And I think we did a great job of that. And because of that, I viewed we had a lot of very constructive conversation with people understanding the requirements a bit better and and how they they potentially could be met. And so with that, I think we also saw some opportunities to have more discussion in some of the existing IETF work. I saw people talking about Dawn, and we addressed some of these things of single domain, cross domain there for discovery. And so that's fantastic as well. Ideally, a lot of the requirements we we would be able to address with other existing IETF work. And I think as Colin mentioned, that's a bit challenging because what this work is is is still evolving, including tomorrow in the agent proto buff. Right? So this was a great opportunity for people who perhaps had been talking past each other to to talk together. And I hope that the answer to that second question question, where you asked who's willing to, you know, continue this, that's really people being willing to continue to talk together. And, along that line, I I look forward to getting together with the the chairs, and hearing their thoughts on on next steps. So, thank you all.

[01:54:13] **Joe Clark**: Thank you, Charles. We will confer and we will make sure that our report, our results, our conclusions are shared with the DMSC list. Which, by the way, if you don't know, there is a mailing list, dmsc@ietf.org. If you're interested in being more a part of this conversation, please join that list.

[01:54:34] **Arnaud Taddei**: Laurent?

[01:54:36] **Laurent Chavaglia**: Thanks, Joe. Thanks, Charles, for preparation of this work. The proponent also, we had some very good interactions altogether. And also, a big thanks to the audience and the comments on the chat and on the mic. Mean, this is really what we needed to have. Now we have a bit of processing to try to capture this outcome, and then handing over back to the community. Thank you, everyone. Thank you.