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

[00:00:22] **Leslie Daigle**: Shall we?

[00:00:31] **Ori Steele**: You want me to get started?

[00:00:32] **Leslie Daigle**: Sure. Alright.

[00:00:35] **Ori Steele**: Welcome everyone. This is the agent communications protocols working group forming BOF. I'm Ori Steele.

[00:00:44] **Leslie Daigle**: Leslie Daigle.

[00:00:46] **Ori Steele**: And we're gonna get started. Please take your seats. If you are here for TLS, that is next door. This is the agent proto BOF. All right. The note well. By this point in the week, you have hopefully seen this several times. This is a reminder, by participating in the IETF, you agree to follow IETF processes and policies. Please make sure you're familiar with the note well before contributing. As a reminder for folks, this meeting is being recorded. If you're in on-site here, please use the on-site tool. If you're remote, please keep your audio and video off until you're welcome to speak. Do do you wanna see? Okay. Here's some administrivia. This is mostly for folks who are following online after the meeting. Just a reminder, please state your name and affiliation at the mic when you you come up to speak. Alright. Here's our agenda. Alright. I see Steven in the queue.

[00:02:14] **Stephen Farrell**: Hi, Ori.

[00:02:15] **Chairperson**: Go ahead, Farrell.

[00:02:16] **Stephen Farrell**: I I think twenty five minutes is as I said to you outside the door, I think twenty five minutes is way too short for discussion. Is it possible to make that longer? Because I think the discussion is what's needed.

[00:02:30] **Leslie Daigle**: So I I think that I think we're gonna play it by ear. I appreciate the input, but this is kind of a little late to be restructuring the agenda. So we'll we'll take that as a note, and we'll try to get through the front matter as quickly as possible. But

[00:02:44] **Stephen Farrell**: I think that's unfortunate. I mean, what I saw having been on the list for a few weeks is that there's there's a whole bunch of people who are proponents there who don't seem reflected in this agenda.

[00:02:53] **Leslie Daigle**: Yeah. There's even some AI bots on the list. Wouldn't

[00:02:57] **Stephen Farrell**: Wizard of Oz

[00:02:57] **Leslie Daigle**: multiple Yeah. So let's see how the discussion goes in the room and focus on the discussion in the room and see if that generates as much confusion as there has been perhaps on the list. And I'll note upfront that my takeaway from the list in the last few weeks has been it really would have been great to have a list dedicated to this discussion and not just all agent to agent protocol. So I hear you. We'll do what we can. Thanks.

[00:03:23] **Stephen Farrell**: I I I think that's unfortunate because, I mean, you know, the proponents here are gonna say, we won't

[00:03:28] **Leslie Daigle**: This isn't giving us more time to discuss later.

[00:03:33] **Stephen Farrell**: Seems seems our. Right?

[00:03:36] **Ori Steele**: Alright. You all can have by now, you've read the agenda, so I'm going to move us forward in the presentation. So just as a reminder, this is a working group forming, BoF. Our goal today is to make sure that you all have a sense as to the motivation for the charter text that we have, draft charter text. By the end of the discussion that we're gonna have here today, I hope the answers to these questions at the bottom of the slide are clear to you all, and it's our job to facilitate that conversation along with the proponents. So as we go through the rest of the agenda, I want you to keep these questions in mind. That's that's our whole goal here. Alright. By now, many of you will be aware there's a lot of interest in the AI topic at this IETF. There's been previous working group forming BAW for DAWN. There was a non working group BAW for DMSC. There's been lots of contribution to various ITF working groups around agent communication, agent authorization, different discussion side meetings. So I wanna draw your attention to these other venues for discussion. In in particular, this Linux Foundation one at the bottom, agent to agent and MCP are work items that are developed, you know, and collaborated on in the inside the Linux Foundation. This BOF here is not the place to discuss changes to those protocols. They're they're managed by the Linux Foundation, not us at the ITF. Alright. As we go through, you're gonna see charter text before the the sections discussing the proposed deliverables within the charter. So we're gonna flash charter text, and then we're gonna have proponents present some content around that session to give you all a sense of why why that text exists and and what the scoping around that text is supposed to be communicating. Alright. This is the introductory text for the charter. It's I'll give you a second to read it all.

[00:06:00] **Leslie Daigle**: I think we should have put the pointer earlier in the deck. In the slide deck, there is a pointer to the actual or on the materials page, there is a pointer to the actual full charter text, which you're welcome to go and peruse now. We're not going to go through it line by line. I did put a copy of it in slides so that if we need to refer to it, we can pull it up. But just for reference, it took nine slides at a readable type font size. So yeah, this is just for for context, and Ori's just gonna go through this super quick. Indeed.

[00:06:35] **Ori Steele**: I think the key takeaway here is there there needs to be something about interoperability for us to be focused on for this to be successful. All right. This first section of Charter text is focused on the motivation and requirements. The important part here is that the current proposed deliverable here is an informational document, and it's meant to, you know, motivate gap analysis and requirements that could be useful when considering the wider scope of the framework and the session components, which you're gonna see later on. And thanks to Suresh for putting a link to the charter into the chat for those following along. The next piece of deliverables within the charter is this session protocol. It's a standards track document, and this is, I think, the the meat of the work for discussion here today. The the scoping for this is it's important to understand it's covering sessions between humans and AI agents, AI agents and tools, and AI agents and other AI agents. The framework document is the last document that we're gonna or last proposed deliverable that we're gonna see discussed today. And the purpose of this framework document, it's a standards track currently in the charter proposed document. And it's meant to help us coordinate the work that might be done here in agent proto with the work that's happening in other working groups such as WIMSE and OAuth, other areas where there needs to be coordination, but the scope for this particular potential working group would not be taking on those items. So we needed some way to have that discussion in, you know, in documents proposed here and coordinate between working groups. Alright. And with that, I think I've sped us through the chairs matter front matter as quickly as I could, and we're on to the main agenda. So the first first up will be our motivations and requirements section.

[00:09:01] **Leslie Daigle**: While Laurent is coming up, if you have your backpack on your seat beside you, please put it on the floor. There are a few, and I mean a few empty seats for those in the back who are still standing. Yeah. There is space. And thank you so much to the people who are indicating where there is space beside them. I think I can.

[00:09:29] **Laurent Ciavaglia**: You can directly go to the next I'm happy to drive There are not many slides. Good morning, everyone. So let me start the motivation by giving yeah, a bit of an industry perspective. So what we're seeing right now is an evolution, a shift in

[00:09:47] **Leslie Daigle**: Close to the mic.

[00:09:48] **Arashmid Akhavan**: Close to the mic.

[00:09:54] **Laurent Ciavaglia**: So a shift in how agenting systems are being composed and deployed. And so in evolution beyond single application or closed agent environments towards network of agent and services that interacts at Internet scale. And this is important to the ATF because the moment those systems cross application boundaries, we start to face a number of key questions. How do system discover each other, establish trust, exchange data, and interact together in an interoperable way. So the second part is also that at the same time, we see multiple ecosystem efforts emerging. And this is good because it shows innovation. It shows momentum. But what we also are facing is a risk that we may end up with more fragmentation and also overlapping mechanism and little interoperability between autonomous sorry, agentic systems. Yeah. So the second part of the industry perspective is also more practical. Operators needs deployable and interoperable solutions and approaches, And they need these approaches to work across multiple use cases for different implementation, for different operational scenarios. And also, very importantly, they need those approaches to work across different boundaries. It can be administrative, trust boundaries. The implemental need is also very concrete because if we expect that we will have different agents, tools, services, platforms to interact together, then we need to provide implementers also clear expectation on what are the protocol capabilities that needs to be involved. Such functionality, it's not an exhaustive list, but they may cover things such as discovery, security, data exchange, lifecycle, session management, etcetera. So there are a lot of functionality that we can list into this protocol support. The important thing is here is that it's not that IETF must address all the facets of agent communication, but it is pointing the fact that when those systems interact over the Internet or cross enterprise boundaries, there is a clear need for protocol questions to be addressed. And this is the scope of what IETF can address. Now if I look into the standards perspective, a simple way to look at the current agentic systems is through this kind of diagram where we have a number of specific interaction types. To So go very quickly over that, the first one is the user to agent. Typically, a user will invoke an agent to delegate a task or define a few instructions. The second one is agent to tool. An agent can invoke a tool, an API, a data source, or an external capability to perform part of the task that he has been asked to to perform. And the last one is the agent to agent interactions where two agents will communicate with each other, again, to coordinate, to exchange informations, to convey results, or to delegate, again, subtask between each one. And as you know very well, there are some efforts today that tackle more the agent to tool interactions, and then the NCP, for instance. And there are other efforts that focus more on each agent to agent communications such as gateway. The important message also is that the simple, let's say, basic interactions are not enough to capture when you have those system that scales to multi domain or multi hop that cross different boundaries and that, let's say, become more distributed because this is creating actually more complex communication patterns. Typically, the agent systems today are going to consist of more than one agent, more than one user, more than one tool. And so these these these agents, I mean, eight autonomous agentic systems, they will need also to to work across different trust boundaries or or across different multiple domains and to maintain I mean, to be able to operate across those domain in a consistent way. So what we see is that as the the the simple use case actually scales to a more distributed and across multiple domains, this makes the protocol requirements more obvious and also candidate for ITF discussion. If we look a bit on the process, we would like to have also for use case interactions and protocol requirements. We are not approaching it from a single use case perspective. What you want to go is to look really across use cases in order to define a number of key interaction patterns that works across those different use cases and out of those behaviors to try to derive what actually the protocol needs to support. The point is that if we go for a single use case and define requirements from a single use case perspective, we risk to have requirements that are potentially too narrow or too tied up to a specific deployment. Whether if we look across the use cases, we identify those interaction behaviors that, let's say, inform us where specific protocol work needs to be achieved and also how this generalized. So this is why also we have this framework perspective. And I think okay. Also, the fact that if we go for this, let's say, more general interaction patterns, this makes the the approach more less deployment specific. And so if we it can cater for different operator and vendor combination or scenarios, and so to avoid to redesign the solution case by case. I will not go into details of this key interaction patterns. You can find it into the materials of the both. But the key message here is that through the different use cases that we have started to study so far, we see a number of repeating patterns. And this is for us indication of where the protocol work can happen. So the the pattern that you see on screen, they are in different order of complexity. You can as I was mentioning before on the expanding scope of interaction between agent agentic systems, you have patterns actually that builds on top of each other and that are repeating across agentic system deployment. So now to conclude this motivation part, I would say the the motivation we have seen comes from mainly three directions. We have a shift from a single agent or single autonomic systems, sorry, systems built on on a more single agent, single applications to something that cross becomes more multi agents and goes over multiple domains and become more distributed. And this creates actually a need for where this interoperability needs to come from, which leads us to the question of this both. So which aspects should agent photo focus on, and what should the IETF define? There are a number of proposals that you will see in the later part of this both around protocol framework, but also what kind of protocols, new protocols, or extensions profile of existing protocols, or a combination of those that the IETF should attack. And so I will hand over to the next presenters to give you a zoom into these other parts.

[00:17:27] **Leslie Daigle**: Yeah. I think if there are clarifying questions and clarifying questions only or not. Great. Thank you. Okay. Apparently, we have one. Please go ahead. Clarifying only.

[00:17:44] **Aijun Wang**: Yeah. Adrian from China Telecom. Before we dial into the what aspect should the this working go to, we should answer the question. What's the gap for the use case between your prop between the kind of solution and the the problem statement. You know? Currently, your use case and requirement is just some general use case and they not point out the what gap exist for the current industry implant implantations. The the the very easy question is, can the a two a protocol meet these requirement? If they can, I think we should find

[00:18:31] **Leslie Daigle**: the

[00:18:31] **Aijun Wang**: other opportunity for the standard?

[00:18:35] **Laurent Ciavaglia**: Yeah. I slightly disagree with your I mean, the expression of where we stand. If you look especially on the work done here and all the drafts, actually, we identify a number of key gaps that points to actual protocol requirements, common requirements, but also more functionality functionally oriented. So I will say we have started to do this work, and I I mean, I invite you to also maybe we can discuss and and see a bit more where we stand. But we're already taking steps in that direction to identify clearly the gaps.

[00:19:05] **Leslie Daigle**: Great. Thank you. Suresh.

[00:19:13] **Suresh Krishnan**: Thank you. Thanks, Laura. Hi. I'm here to talk about how the use case we are looking at have a need for multimodal communication. So we just take a few examples and go through it and and kind of follow-up into why we need something to tie these transport layer sessions together. So there's a couple of use cases we started looking at. So the Jonathan and and Colin started putting this lot of the stuff together to kind of collect a whole bunch of use cases where agent to agent protocol or a user agent to communication chain requires multiple modalities of communication. So, like, one example, like, that's pretty common already right now is, like, a customer support agent. You have a wise conversation with somebody, and they say, hey. Like, you know, can you share your screen? And you share your screen. And there's also some tool calls happening. Somebody could, like, do a debug log. Somebody could, like, you know, pull something off a back end database to get some things in. And also, like, something that's a little bit more futuristic. And and I was in India, like, recently, and there's, like, some kind of thing like this where you actually get on a call with a doctor to do things. And I think this is becoming, like, more and more common. It's not really real time at this point. Right? Like, you know, you still have, like, splotchy video and stuff and so on. But with agentic use cases, you still have the concept of, hey. You send a video of something to kind of people can see the symptoms. You can have, interactive voice chat with, like, the provider to actually say, like, hey. These are my symptoms. What do I think? And they kind of ask you questions and things like that. And they could say, hey. Like, can you send me your MRI from last week? Right? So there could be some kind of structured form data that's going in another channel. Like, not between you, but between probably other set of agents that are going through. And collaborative coding, like, you know, we've done programming, a lot of us, in the past, and there's, like, kind of collaborative coding between agents and also humans happening. So and also, like, I'll this is, a common overused example. I kinda wanna put it in there because it's kind of relevant here. So somebody wants to have a personal agent go and book a trip, a business trip for you or a leisure trip. I I actually met somebody here who was actually using an agent to plan a Europe trip just before coming here. They and, like yeah. So this kind of stuff also already happens. And the the key point I wanna emphasize here, not to go into the details, is that, like, there's multiple agents done. It's agents all the way down. Right? Like so there's, like, bunch of set of agents that are interacting here. And the the key thing we wanna accomplish here is that when there's multiple agents involved, how do we ensure that the communication between the agents are somehow tied together? Right? And I saw, like, Steven's comments on the chat about a session protocol. The ITF hasn't done one. Totally get rid of that. Right? Like, you know, we don't wanna become the OSI. But the idea is that that there's, like, multiple transport requirements that are happening here, and we somehow wanna tie them together because, like, you know, they they don't have a shared fit right now. Right? Like, it's possible that you could have, like, one HTTP three connection that could all have shared fits, but there's also some requirements on the other direction. So one of the things, if you look at it, is that the lot of things that are happening in this multimodal session between agents, there's, like, diverse latency and also reliability needs. So if we have, like, real time media, like, you know, sub, hundred millisecond kind of thing, you have, like, voice, video, and screen shares and stuff like that that which are, like, very tight latency requirements. And we have, like, some semi interactive text, which is, like, probably about a second or so. It things get pretty bad after that. And there's, like, a whole bunch of bulk data, whether it's just tool calls or, like, huge file transfers. And they're all, like, pretty different. So you don't wanna put them in, like, one transport connection, but you kinda wanna share them across. But you want them to be somehow bound together. Right? Like, so the idea would be that the different transport connections know that they are bound to one kind of thing. So whether you call it a session or not, we can discuss that. But the idea is to correlate these things so they can live together and die together. That's kind of the high level thinking. And following up on what Laurent said, why do we wanna do this? Right? Like, because, like, people are doing this today. So if you look at it, NCP has these things. Like, a two a has these things. So why are we doing it? I think that, philosophically,

[00:23:33] **Dan Romascanu**: the

[00:23:33] **Suresh Krishnan**: thing is like, hey. We have done this transport protocols. We know how to do this properly. And our goal is to provide, like, some kind of substrate that we build here saying, like, hey. This is how we tie the things together and with the hope that, like, people would reuse them instead of rolling their own. Because right now, if we don't do anything to kind of hold these together, people are gonna do their own thing, and we're gonna have whole bunch of fragmented agent framework slash ecosystems. Right? And that's kind of why we are going into this space. So to Steven's point again, don't read this as like we are trying to add a layer into the stack, but we are actually trying to tie the transport sessions together. Okay? So when you listen to Hisham's presentation, keep that in your mind. And I'm open to questions now if there's any clarifying questions.

[00:24:21] **Leslie Daigle**: Yeah. Clarifying questions only, and please use the queue if you're going to. Alright. One person coming up.

[00:24:36] **George Fletcher**: Yeah. George Fletcher, this doesn't feel like it's AI specific. You are very much talking about tying multiple, you know, disparate transport mechanisms together into some logical hole. Is that an intended goal? I mean, we called the the the BOF is focused on agent protocol. But

[00:24:58] **Leslie Daigle**: I think the point is that agents have requirements that we haven't seen from other use cases to date. Therefore, the time together becomes imperative.

[00:25:06] **George Fletcher**: The first use case about sharing stuff in a medical context or whatever feels like it exists today without an agent. So, anyway, it might just be something to consider if we go down this path of taking this be outside the context, making it broader than just agents.

[00:25:24] **Suresh Krishnan**: Thank you. Do you mind if I give a ten second answer?

[00:25:27] **Leslie Daigle**: Go ahead.

[00:25:28] **Suresh Krishnan**: Okay. So I think the point is, like, not to scope it just to agents, but not to spend time on taking requirements from other things right now. So that's kind of the scope. Right? Like, if it works perfectly well with other things, that's fine. But if somebody says, I have this traveling bot which does this thing on a desert and I wanna cover it, probably not there. Right? Like but I think, like, we're not trying to do anything to specifically disadvantage other uses of it. I heard another use case with, like, Gmail. Right? Like, which could do this. So, absolutely, yes. Thank you.

[00:25:59] **Leslie Daigle**: Okay. Thank you, Suresh.

[00:26:01] **Suresh Krishnan**: Yeah. Thanks. Three more minutes for Steven to discuss if he doesn't take my time away.

[00:26:05] **Stephen Farrell**: Just if you go back to the picture sorry. Sorry. Not the moment. The the moment that hops. Yeah. Yeah. That's fine. Is there an assumption that kinda authorization information might kind of accumulate along the path?

[00:26:20] **Suresh Krishnan**: That is okay. So I'm not gonna go into the OAuth stuff, but but yes. So there there's some kind of things that are kind of communicating from the agent and sometimes not. Yes.

[00:26:30] **Leslie Daigle**: Awesome. Thank you.

[00:26:38] **Chairperson**: Okay.

[00:26:44] **Hisham Al-Khasib**: Tall people first. So

[00:26:49] **Aijun Wang**: okay.

[00:26:56] **Hisham Al-Khasib**: Okay. So first of all, yeah, I think Suresh has pointed out the multimodality aspect of things. I'm I'm trying to look at a different aspect in here, which is the context and context management from a session point of view. This is just like some background. I think Motivision has covered it. So the participants are agents, humans, and tools, and multimodality is covered by Suresh. But one thing that we need to also look into is the nature of those interactions. And those interactions could be long lived or short lived. They are stateful, and they are chained. Probably, they're gonna happen in parallel and potentially simultaneously and across multiple domains. One more thing is the dynamics that we're dealing with because interactions, they happen, but they could be interrupted. They could be canceled. They could be paused or resumed. For example, I'm talking to an agent. I want you to help me with this, but hold on. I'm just gonna restart my phone, and I'll come back to you. So things evolve. And

[00:28:01] **Stephen Farrell**: there's also

[00:28:01] **Hisham Al-Khasib**: a networking aspect in here because those participants can join. They can leave. They act autonomously. They can influence the environment. In some scenarios, agents could fail. They could hallucinate and make mistakes. They can recover from those mistakes. They could be replaced with other agents, and they could evolve. They can learn new skills. And everything is actually running on top of multiple frameworks today. We have a to a. We have MCP, HTTP, etcetera. And things, as Suresh pointed out, are running on top of multiple transport layers. We have MOQ web transport. Okay? So context. Now when what happens is what gets this agentic network to run is a task. Once a task is submitted, we get those waves of interactions. But we're not handling one task at a time. We are probably going to be handling multiple tasks at a time. And each of those tasks is going to create waves of interactions. Those waves, they intersect, they overlap, they involve shared participants, which is something unique about this agentic network. So what binds everything together is to to stay sane and to be able to maneuver our our way through such a zoo is basically context. Context is what puts everything into perspective. It tells an agent which video belongs to which text. For example, I want you to process this video for me, but the video is still coming. Okay. Which video are pointing to? So context tells you which video belongs to which task. It tells a coordinator which subtask belongs to which parent task because tasks are chained. There's a front agent, but that breaks up this task and gives us subtasks, etcetera. So there is a lot of dynamics that could happen here, and context naturally happens in this particular type of network. And without proper context management and session management, things can break, and handling multiple tasks could be challenging. And that's why we think there is, again, I'm not gonna say a session layer, a protocol that lives and manages sessions and manages context is needed. This is a protocol that should impose order on an otherwise chaotic multimodal and multi agentic workflows. It anchors contexts and preserves continuity and prevents cross contamination between tasks. And the most important thing is it needs to be interoperable. So I'll go back to the figure that Suresh just shown a few minute minutes ago, and we ask ourselves, okay. Why do we need to standardize such protocol? Well, a two a is doing this, m two MCP is doing this. But the thing is, each one of those recognize the fact that we need to do context management and session handling. But each one is building its own way of handling such a thing. And for really to put everything together and make it interoperable, we need a standardized way to do so. So what do we expect expect from a session protocol? Session protocol can allow us to to build a resilient system against failures. Imagine an agent, a mid task, it just fails. Okay? And we want to spin another agent to replace it. This agent needs to pick up the pace. It just needs to know, okay. Where did I stop? What's happening now? So you need to bring it up to speed, basically. Such failures could happen, and this is where session is important. It's holding this context, and once you spin up a new agent, it's it's just, bring it up to speed. The other thing is have multi participants, and a lot of potential ways of interacting. Those could be hierarchical, you name it, chain parallel, etcetera. So there has to be a way to manage everything and put everything in place. We need some sort of isolation. There are two agents who are talking together on one side and two other agents are talking on another side. What's happening here should not be shared with those people, so each one should have a session somehow. And, of course, what Suresh has mentioned about multimodality, managing sessions can allow us actually do some spatial and temporal alignment. Say, this is related to that. We can handle interrupts. So if you come in and say, okay. I changed my mind. I don't want you to book this trip for me. How do I unwind everything? Do I ask for refund, or what do I do? Okay. So now okay. Hopefully, I'm motivated or made the case about why session and context are important in here. But the question is why ITF? We know that ITF has protocols, transport and application protocols. They cover some modes of managing sessions. For example, we have a form of failure recovery under QUIC. We have stream multiplexing under HTTP. We have priority handling under web transport, and we carry media over QUIC. However, none of them natively manage agents, context across turns, interrupts, and reconnects. They also don't handle coordination and multi entity interactions in an interoperable way, and that's particularly the gap. So what we need is a session protocol, not a layer again, that binds everything together. It needs to be agent tool and human aware. It needs to handle multimodality and stream coordination. It should provide means for managing context, recovering from system failures, and handling interrupts on barges. And we need to define proper bindings for this protocol to be able to work with the transport layers and put everything together as well as support the up and top layers like MCP a to a and make them interoperable together. And, of course, this needs to work across diverse domains and across multi hop connections. Yes. Thank you. That's all.

[00:34:25] **Leslie Daigle**: Thank you. Clarifying questions.

[00:34:27] **Hisham Al-Khasib**: Two questions already.

[00:34:34] **Ted Hardie**: Ted Hardy. No relevant affiliation. The way you've described this, I really appreciate your focus on context and the fact that you see this as a protocol potentially rather than a layer. What we've seen in the past in the ITF in this are essentially signaling protocols like SIP, which help you initiate a voice or video context, or WebRTC, which does something similar. In many of those cases, this is at the initiation of the context, and it does not necessarily continue throughout. There are cases where it does, but many in which it does not. Going back to your set of proposals, it looks to me like you are expecting this to be, again, something which is set up at the beginning to create the context but does not necessarily have an ongoing role in managing it. Is that correct, or do you see the necessity for this context initiation protocol to continue to be present throughout the interchange so that it can bring others in or take others out?

[00:35:39] **Hisham Al-Khasib**: The way I see it? Or I mean, the way you

[00:35:41] **Chairperson**: should be.

[00:35:42] **Speaker 12**: I'm asking you.

[00:35:42] **Hisham Al-Khasib**: Yeah. Okay. So I I think yes. So there is initiation, but there is also maintenance of this context and binding it to the transport layer because we need to understand something about what's going on on top to be able to support this interaction later on. So as I said, I still an agent that, okay. I need you to process this video for me, but this video is coming in in two minutes. But that same agent is actually receiving a video from someone else. How can it do this binding? How does it know those two belong together? That's one. Can we streamline both in a transport point of view such that both video and text arrive at the same time so the binding is actually preprocessed? So that's the way I see it. Now whether can we can we do this in ITF or not? That's the question we need to look in.

[00:36:33] **Ted Hardie**: Thank you. I'm about to drift into not clarifying, so I'm gonna go back.

[00:36:36] **Hisham Al-Khasib**: Oh, sorry. Proponents, if anyone wants to jump, sure.

[00:36:41] **Leslie Daigle**: No. I think I think we'll take that discussion to later and take one more question. Yeah.

[00:36:45] **Speaker 13**: Okay. Just to

[00:36:47] **Leslie Daigle**: And and please, when you get to the mic, please do state your name and affiliation because anybody listening to the recording afterwards doesn't see the queue, so they don't

[00:36:54] **Speaker 13**: know who's speaking. From China Mobile. Just a clarification on the JetTeam network. I don't know why which size it is. May a lot of people know think about to put the agent into the network device or controller. So I think it's done the mean this. So more clarification on it may help.

[00:37:18] **Hisham Al-Khasib**: Sure. Thank you.

[00:37:23] **Leslie Daigle**: Okay. Okay. Thank you.

[00:37:44] **Daping Liu**: Okay. So John will talk about the framework. I noticed that in the chat, people are asking why we need a framework. So to answer this question, I actually searched this tracker. I do see there are ITF RFC talking about solution architecture. For example, RFC eighty eight seventy one. If people have interest, you can look at that. So I think the question first is that why we need a framework. So I think it's made quite clear in the previous presentation that for this AI protocol potential working group, the focus first study available would be agent session legal protocol. So it addresses the urgent needs and gaps. For example, I think the previous presenter has talked about a multimodal session and context management, but also just some very specific scenario. For example, the user user scenario. I think my colleague could be comment that later if we have time. So those kind of things, of course, will be in the scope of this potential new working group. But another piece deliverable, if you look at the draft chatter, is a framework we want to do. So why we need this? Because there are so many different building blocks in ITF. So some will be done in this new working group and others could be not. For example, as earlier experts mentioned, to deal with the security, how to deal with identity. I think that things will have that building block will be provided by other working group. So we will make sure we will not duplicate any existing work ongoing in Visme, for example, and OAuth, but we want to reuse these building blocks and to let the developer to understand. Okay. So this is the ITF recommendation integration of those building blocks in your argentic scenario. So that is very important, I think, for the implementers and for us. We have the promise if ITF delivers some of those building blocks and the framework, they they would definitely implement in our scenarios. Secondly, we use this framework to identify further gaps. So in this case, you know, things are changing so fast. If you in the process of integrating those building blocks when we need to find something new, need need to be, for example, extensions of other building blocks, we can use this as a guidance and requirements to cooperate with other working group. So second question is that how what are the boundaries with other working groups? So I think that is quite important question. So we want to make it very clear in this framework. We in this potential new working group, also, we want to make it very clear. We don't touch any existing working group's boundary. For example, if we are talking about security, we will definitely cooperate with WIMSE and OAuth and use the existing protocol building blocks there or any further extensions delivered by their working groups. And for the transport, I think this is also applies. We do have a quick media overquick and the WebRTC and other existing building blocks as transport protocol. We will build our session management protocol on top of them. If if we do identify any any gaps, we can, you know, cooperate with those existing working groups to see what is the right solution, or we can just reuse existing mechanisms. So what what is the cooperative process we we imagine? Of course, this is not only decided by us, but we want to leave the decision by the corresponding working group to decide. For example, if we identify some gaps in our AI protocol working group, we want to share these requirements and raise this question in the corresponding working group, and they they will have the decision, see whether this is problem want to solve. If they do agree to solve this problem and have new deliverables, they can use their deliverables in our framework to integrate that in our framework as a as a whole solution in the agentic scenarios. Next, I want to tech talk about what is in the scope of this framework. So you can also check the draft or chatter in GitHub, and the the text is almost the same here. So, basically, one way this framework, we want to cover the important aspects of the agent application. If you if you want to build the agent application, typically, you'll need to address those kind of different building blocks. So as mentioned earlier, not necessarily those building blocks will be done in this potential new working group. We can definitely reuse existing mechanisms. So key building block here at least is, for example, how the agent collaborate with each other and how to support the multimodal transport and the different functional building blocks. And, also, the important thing is security, identity authorization, and especially in agent scenarios, multi hop and the chain delegation, so something like those are very important. And, of course, the protocol suite, how to use those building blocks to integrate them together as a whole solution. That is also very important. So we see this framework will happen in parallel with the protocol, you know, specification. So we don't want is a a blocking document. We want is a living document and working in parallel with protocol specification work. And what is not in the scope? So we want to make it out clear. Also, this text is from the drop to charter. We don't define that to do the definition for AI models, agent reasoning algorithms, and tool specific on the business logic, something like that. And and we don't want to standardize the agent behavior, decision making, or planning semantics. And the agent behavior security, we don't want to touch that. And, also, we don't want to design the human inter human user interface. So that is quite clear. Okay. I think that is my presentation. If there are any questions, we have two minutes and more.

[00:44:51] **Leslie Daigle**: Thank you. We have a few people in the queue for clarifying questions only, please. Manu? Manu Gupta? Going once, going twice. Alton now?

[00:45:15] **Alton Lo**: It's Alton and Cisco Meraki. Hi. So I I see this framework, and I see that the presentations before as well. But I'm not able to understand from all of this, is the framework which is supposed to live in the session layer, how closely is it related to the protocol? For example, is it part of a SIP protocol? Is it built on with using the SIP semantics? Or if in case it is HTTP, how is it part of HTTP? What is the con what is the scope of this context layer, session layer framework?

[00:45:49] **Daping Liu**: Okay. So I want to share my understanding. Maybe people in the room may have others. So I think the session management protocol will be built on top existing transportation protocol. For example, QUIC, Media Over QUIC, or web transfer web or WebRTC. But on top of that, we will we want to build session management protocol that address the gap of the identity use cases, maybe not only identity use cases as we just discussed earlier. For example, how to support multimodal if a user want to talk to an agent using voice or video. The some interesting scenario, for example, user. If you are a human user talking another human, it's easier to understand. Okay. So you want to interrupt me. I will listen. So that is easy. But how to make the agent understand? Okay. Stop. Deliver tokens because the user already interrupt you, and he want more context input. So then stop, deliver tokens, and receive those promote as a as a new contact and combine together. So for those kind of session management and there could be many other things. So but we want to reuse existing transport layer protocols, yeah, on top of them building this session management.

[00:47:29] **Leslie Daigle**: Can I no? No.

[00:47:30] **Alton Lo**: So this is not answering my question. So is this is this layer protocol agnostic or not? Let's just say

[00:47:39] **Daping Liu**: I I in my mind, that is a solution, I think. It's not supposed to discuss the detail here. But in my mind, I think we need some kind of bonding. For example, the session protocol, if we use MOQ, so how the priority management pops up in Canada, we can use. We we need some bonding layer, but is, in theory, is agnostic with transport.

[00:48:06] **Leslie Daigle**: Okay. I think we're gonna have to move on. Thank you. Okay.

[00:48:14] **Jonathan Rosenberg**: Steven Mee, Action State Group, had a clarifying question as it relates to the evidence in block four. Is the record that is captured there, does it include the declined or blocked or refused, or is it just completed actions?

[00:48:33] **Daping Liu**: Sorry. Which question? Which block you?

[00:48:37] **Jonathan Rosenberg**: The evidence layer.

[00:48:39] **Daping Liu**: Evidence layer. Okay. So yeah. So that is something I think maybe is not necessarily to do will be done in this new working group. That will be some mechanism, I think, related work discussing in other working groups. So we want to reuse if there has some outcome. Yeah.

[00:48:59] **Leslie Daigle**: Okay. Thanks. We are using the MeetAQ Co queue for this. So, yes, I think we are good to go. Thank you. So we are not quite at the working group forming discussion. We are at clarifying questions and follow ups. Let me unlock the queue. That would be helpful. So since we've done clarifying questions through the discussions, we have more time for the general discussion of the material. Ori, any context you want to add?

[00:49:44] **Ori Steele**: Alright. I think in support of focusing folks on the the charter text itself, if there are no clarifying questions for the existing elaboration, we can, you know, proceed to the discussion if that if that's what what folks would like to do. Alright.

[00:50:08] **Leslie Daigle**: Okay. So this is for discussion of the scope and charter. There is the point of the charter text if you missed it in the chat earlier. Open mic. But please use the queue. Ted.

[00:50:31] **Ted Hardie**: Ted Hardy, no relevant affiliation. Thank you very much. I think I wanna go back to the conversation that we started with Hessian. I think it was a very important description of the problem space because I think he was describing this not in terms actually of a session layer, but in terms of a context which needs to be propagated. And that context needs to be propagated in a multiparty way across trust boundaries and across modalities. That's a pretty complicated thing, but it is actually a tractable problem. And I think what we are looking for in a charter is a way of describing that that says what this working group will do is enable a signaling protocol that will allow the setup and management of context propagation through these trust roundies in a multimodal way for these multiparties. And I keep coming back to multi party because of something very important Jonathan Rosenberg said in chat. When we have done session initiation in the past, we have typically focused on endpoints. SIP allows this call to go from this place to that place, WebRTC from this browser to that browser. In this case, we are actually going to need multi party because you're going to want to be able to move the context with the party as they move from one device to another or over time. So I think looking at the charter, I would reframe this as context propagation, and I would particularly bring the framework up to doing that first. The way this is written right now, the charter has those two items moving in parallel, the development of the technical work and the development of the framework. And I think it would really help the rest of the industry, particularly the folks working on MCP or A2A, to understand how this differs from what they do if they see it as a signaling protocol for this context propagation rather than necessarily a replacement for the actual communication protocols that are already in play. Overall, I I feel this BOF has been really helpful for me to understand what the work the ITF could take on here is. And with the kind of tremendous second thing going on in the chat, as usual, I actually think that this is something that we could tackle and do well. So I'm I'm supportive of rewriting it to focus on the way that Brian and others have have put put into the into that and going forward. Thanks.

[00:52:57] **Leslie Daigle**: Thanks, Ted. Brian? Hi.

[00:52:59] **Brian Trammell**: Brian Trammell. Everything Ted said with the minor amendment that if you call it context propagation, you're going to confuse the hell out of all the AI researchers. Like, terminology is hard. We'll figure it out. Right? The the the other bit of the conversation, I would strongly encourage the chairs to go get the chat transcripts and feed them into whatever LLM based minutes thing you're doing. There's a whole bunch of really interesting stuff in there that I think will will make this charter better. I don't have concrete things to say about the charter yet. I might by the end of this path. The way I would encourage us to think about this is what is the minimum viable set of primitives that we would need support in order to make the thing that's new here work. Right? Like, so these are just programs talking to each other. That's what the Internet has been built on forever. I the way that I tend to see this might might just just be my mental model is the thing that's different now is the dynamicity of the connectivity and the dynamicity of sort of the deployment. Right? Like, who's talking to who, how. Right? Like, this used to be a thing you'd on a whiteboard and say, here's my architecture diagram. Now that that's being determined by the system itself. That makes this context propagation renamed thing a really, I think, interesting primitive to tackle. So in with that smaller sort of like that that restriction of scope and sort of like really minimum viable set of primitives, I'd be I think there's there's something here the ITF can do and I think there's something that we could like productively charter around. Thanks.

[00:54:39] **Leslie Daigle**: Thank you. Steven?

[00:54:41] **Stephen Farrell**: So I agree with some of what Ted and Brian were saying. I think there, you know, there there there is a smaller scope that could be taken on. I think there still are a bunch of questions as to how realistic it is for the at the world to pay attention. I'm kinda concerned that I think the authorization information that you'd want to be passing around here is incredibly complicated, and I don't think we've ever done anything like that. And I don't think we have a proof of concept that it can be done. And that would seem counter indicative of doing something until somebody has demonstrated that you can actually pass around really complicated authorization information in ways that, you know, you you might want some agents to have a a visibility of some attributes and another one other attributes and so on and so on. So it can just get, like, incredibly complicated and unwieldy.

[00:55:30] **Leslie Daigle**: So having lived through some of the very early days of the federated identity authorization work and agreeing with you about its complexity, would it be fair to say that what we need to do is effectively scope the impact and outcome of the work based on the level of complexity we can achieve? To do it perfectly, of course, yeah, mean to do it perfectly would need incredible complexity, indeed beyond the scope of what the IETF has tackled before, but, you know, in terms of MVPs, let's say, you think we can frame it in a way that we we can So

[00:56:06] **Stephen Farrell**: so I think we could, but I would be much happier to see that going ahead if there were some proofs of concept that said, here's how you can do these complicated things. Because I fear that the end result might be you essentially just give all your crown jewels to every agent, and they can go off and do everything. And that wouldn't be a good outcome, and that wouldn't be a good thing to enable. So I think there are some risks here, you know, being so partly successfully.

[00:56:27] **Ori Steele**: So, Steven, just perhaps you're asking, you know, could there be security considerations, privacy considerations that apply to the framework document or the the session p does that address your concern?

[00:56:38] **Stephen Farrell**: No. No. I'd I I would love to see a proof of concept, a demonstration that something at this complex level of complexity can be done. I I think the whole framework part of the charter is probably best dropped. But in terms of the kind of protocol, I'm not convinced it can be done in a way that's safe. And then I think there's another point, which is, I guess, the kind of thing that Ecker might have been raising this year. Other people are doing stuff, maybe we we'd be better off waiting until they've have done a proof of concept and then figure out what bits we should fill in. I'm not saying that that's my opinion, but I was

[00:57:08] **Ori Steele**: just to represent it. Thanks. Justin.

[00:57:12] **Justin Richer**: Justin Richer. So, yeah, Steven sort of cracked open the egg that I that I wanted to as well. And that's the the context attenuation and changing as it crosses these boundaries. I'm I'm not gonna want different parts of the system to know everything about what's going on or have the entire set of rights. And, yes, I know that this was talking about it's not specifically solving the, like, identification and sort of core security primitives necessarily, but you're gonna have to be able to propagate that, and you're gonna have a system that is making its own decisions about what those translations between boundaries look like. You know, for example, if I have something that I want to be able

[00:57:59] **Roberto**: to

[00:58:00] **Justin Richer**: go and send an email within a system and even talking just like plain workloads. If I have something that I wanna be able to send an email, I don't want everything to be able to write into the email inbox. But I have like one part of the system that can write into the email inbox that is an access right that it has been conveyed. And I don't wanna have to give that to the virus scanner or other parts of the system. It gets even weirder when this stuff starts getting nondeterministic and deciding for itself that it needs to write into my mailbox for some reason that I haven't figured out yet. All of this to say, what are we proposing and thinking with this working group about sort of tackling or deliberately not tackling the attenuation problem. And attenuation is a bad word for this because attenuation in these cases is often an expansion of rights in a in a limited scope.

[00:58:58] **Ori Steele**: So I'll invite the the proponents to to answer, but my understanding is the framework documents, I mean, part of its purpose is to be able to connect to the other areas in the IETF that are handling some of these, you know, authorization and identification issues. And so, you know, you know.

[00:59:17] **Justin Richer**: So this is just initiation, propagation, carrier type of stuff. That's that's sort of the layer that it's trying to live in?

[00:59:25] **Ori Steele**: I I think I just personal opinion, my view of this framework document and the session piece together is that it sort of describes the slots that the other Right. The, you know, other working groups of the I ITF that are focusing on identification and authorization may fill into, but that's just my personal opinion. Chair the proponents are welcome to jump the queue if they have any any any other comments.

[00:59:54] **Suresh Krishnan**: Thank you. Suresh Krishna. So, yes, Justin. So the like, I think already summarized it, right? Like, we kinda wanna take the outputs from the other ITF groups and put it together in an easy to consumable format. So framework is probably gonna show how a substrate can be formed that can be reusable by application layer protocols on top. Right? That's kind of the goal is to say, hey, WIMSE's got this identity piece, or this got this like authorization pieces. Right? And this is not the word session protocol that's getting developed here. Right? Like, how do we put this all together in a way that everybody understands and makes it easy to interrupt between different agent ecosystems that are existing outside? So that's kind of the goal of the framework.

[01:00:42] **Mike Blanch**: Hey there. Mike Mike Blanche. So I think there's I agree there's been some really interesting discussion and brainstorming in the chat about the need for agent to agent, agent to tool, interop. But then that there's definitely the proviso that the term agent is is very unclear at this point, I I would think. But on the charter specifically, as you have it up on the screen, there's something in there that refers to human to agent communication and proposes that the human to agent communication protocol is in scope. And I I'm not quite sure what that means, and maybe it means the client to agent communication protocol or the user agent to agent? Oh, no. I've used agent term again. Communication protocol. Anyway, thank you.

[01:01:28] **Ori Steele**: Yep. Zaheed Zaheed is one of the proponents. Go ahead.

[01:01:33] **Leslie Daigle**: And while while getting ready to answer that, I just want to observe on the point about good comments in the chat, I agree and I agree that we need to capture some of what's in the chat in the record of this meeting. But if you think there's a really strong item in the chat, please bring it to the actual working group, like on mic, raise your hand. Thank you.

[01:01:57] **Zaheduzzaman Sarker**: So yeah, I think that's a very good point. So what when we have been thinking about it, it is more about, like, okay, who invokes the thing? It starts with the user, like as a human user, perhaps, or something like represent human users. And that's the client that represents human. So, yeah, of course, this is if you look into the use cases and requirements, we are actually in the scope. It's like when somebody initiates some puts a task to do done by agent, that need to be communicated to an agent. That's part of the scope. And you call it human or you call it client. It's I mean, it's just your definition.

[01:02:39] **Dan Romascanu**: Dan Rutza with AT and T. I think this is very useful, and and it's very well organized and very well explained scope. I do think that there is a need for some implementers and operators to really understand what is gonna be the impact. By the time we're gonna have some RFCs, assuming that this is actually gonna be formed, you have frameworks deployed, and these frameworks that that are rolling out are not waiting for the protocol to to to be standardized. So I I I think it will be and if you look at the stack, you know, any anything below the the the session layer that was described there, There's a lot of stuff, but I I'm not I'm trying to understand what is the impact on the existing frameworks that are becoming de facto, like the application layer that is mentioned out of scope there. So I think it will be useful to to have at least something in the charter that kind of calms down some of the concerns about the about the heavy lifting, the rip and replace type concerns that that I I might have related to this. Thank you.

[01:03:56] **Jonathan Rosenberg**: Jonathan Rosenberg. So I think Ted has really helped us make progress here. And if you think about this as we place the word session with context, and the protocol we're talking about here is, in essence, a context management protocol. Allows us to start a context and append to it with real time audio, video, text. It allows it to pause us, resume it, and allows us to manage it across different devices. And I think this is one of the ways in which, and I posted in the chat, this is quite distinct from SIP, which is really was a point to point ephemeral connection, which, yes, exchanged media, but it was point to point ephemeral. This also needs to exchange media, but it is not ephemeral. And it can exact in fact, perhaps be held for a few days and come back, right, from a different device to a different server, and we wanna make sure all of that works. So that's some of the ways in which I don't know how to interpret that.

[01:04:47] **Leslie Daigle**: Yeah. Some somebody's leaning on the light switch.

[01:04:51] **Jonathan Rosenberg**: Was leaning on the on the light switch. Please turn the lights back on.

[01:04:54] **Leslie Daigle**: And there this is a good time to point out there are a few open seats if you're tired of standing at the back.

[01:04:59] **Jonathan Rosenberg**: Yeah. Thank you. I I also think if you think of this as a context management protocol, it also becomes clearer as to why it's relevant for user to agent, agent to agent, and agent to tool. Those are all places where one entity wants to start to create a context and continue to augment it, pause, and retrieve it in these different hops in the system. And rather than having totally different protocols for creating and managing those things, let's have one. Just like with SIP, it's the same SIP, sorta, between the user agent and the server and the so between servers and the server remote side with differences that apply in each of the different legs. And that's the way in which we'll have these different application protocols, which are different things unique to the fact that, oh, this is a tool, which is perhaps a little shorter lived in some cases from a user where identity is different, and that's the way in which we have different application protocols. And then this framework just ties all this together. So I don't know why people get all bent in and on in the framework. It's a good way to understand all the layers we're talking about seems like a good thing. So, obviously, I'm a proponent. I think there's hard, good work useful work here to be done, and, obviously, the details get worked out in the working group. I'm a favor. Thank you.

[01:06:03] **Leslie Daigle**: Thank you, Jonathan. Arnaud?

[01:06:07] **Arnaud Taddei**: Hello? Yeah. Okay. So Arnaud, no affiliation. So I'm going to concentrate on the charter right now because that's what we need to discuss. There there are things I like, things I dislike, and there are things I don't understand. So the first problem I have is the charter is the the definition of a Jontic AI. So that's the ends definition I see on a Jonti AI this week. And if I would zoom on all the presentations we got between the same meeting, we are at m. So I have no idea how we are going to agree something when the first element actually is not even in agreement across the whole of IT. And the problem it causes is that I can clearly see the debate that is not cut, not happening, and frozen about what is an agent. Some believe it's just a program on the workload, and some violently disagree with that. So that's a challenge for this charter, but not just for this charter for ATF. Back to my rounds yesterday at the plenary. The thing I like about this charter is the what was very nice was all the from Suresh and Kulin on the multi model. I think that should be the heart of this working group. This is a problem. I think this is very well stated. We need to do something there. There is a good that that's not the first time we discussed about it. I we were end side meetings that led to that one. Good work. I think we should concentrate on that. The thing that I am absolutely against is the framework. The framework, first of all, is one idea of a framework. I could give you tons of reasons why it will not be sticky and why actually it's going to conflict with many other things when you we want to build a control plane. And as you have out of scope stuff from this charter, which are good, like on the behavior, you are going to see that later, oh, maybe there are things in this framework we could have addressed precisely by addressing the control plane and the behavior. Because for many things, you will not be able to give an ID to to an agent. It will be so ephemeral. It will cost so much if you want to start to create the old stack about it. It's not going to work. Coordination, please stop looking inward. You've got other groups. I'm a SG17 chair. I sent a liaison statement. We have already 25 work items established by 42 member states, 54 countries, foreign participants that you could leverage. We launched a focus group where precisely the discussions on whether an agent is a program or an agent is something more will be cut. We have an agenda for that. We have deliverables for that. So this is open to everybody. That's not just for SG17. You could use it. Right? So please add this at least recognize that there are others doing as well some, I think, reasonable job. And I think let me check my list. I think that's it. Framework. Yes. And on identity semantics, etcetera, please do not redefine them here and be explicit about it if you want go this way. Same be consistent with them, and I think that's it for me. Thank you.

[01:09:34] **Ori Steele**: Thank you. Al Altena?

[01:09:37] **Alton Lo**: Altena, Hi. So I ring the charter, and I see the AI agent behavioral security is categorically out of scope, and I have a point against that. So I'm not saying try to solve deepfake or assist in that domain, but I'm saying that if we are developing something that can help the application layer do it, then we should enable that. So, basically, I'm asking that we should have more protocol align alignment and binding, and safety guardrails so that we enable the applications with the audit signals to, detect misuse. For example, fake fake calls or fake synthetic media streams, things like that. Does that sound something the charter can be updated to do?

[01:10:36] **Leslie Daigle**: Thank you for that contribution to the discussion. I think there's still a number of directions in which the charter is is moving, so I don't think we're ready to make a conclusion on that. But thank you. Okay. Thanks. Colin?

[01:10:50] **Colin Perkins**: Colin Jenkins, Cisco. So I wanna just sort of there's been multiple comments about the the security and proof of concepts and things like that. I'd like to sort of address a couple of those a little bit. And the, you know, the the I think the the any large multi I'll call it multi party system where we're moving context around the ITF, obviously, security and how we do that. An important part of what the working group works at. There'll be variations of this problem. There might be use cases that are just not solvable with with a reasonable security that we could build in in an in an easy and direct way that we

[01:11:26] **Arashmid Akhavan**: know how to deal with today.

[01:11:27] **Colin Perkins**: But I think that what is very much in people's imagination of of cases that we would be able to easily solve with what we have today are the type of things like you have one agent that perhaps gets the context of my spoken voice and can make some summary information about it as in a in a text form. And that another agent might be able to have access to that text form, but it can't have access to my original voice which would also give you biometrics that might identify me, for example, and that those are running in different scopes. So I think there's very much the idea that this context has different parts, that the each one of those parts would be authorized to be decrypted in an Indian encryption type way by various different agents, would be authorized to to access that portion of the context or not, and that that would not be equal about things. We do have many proof of concepts of this beyond proof of concepts. They have widely deployed systems today doing this. One of the very common models that's very seems appealing to many ITF protocols is we will have a piece of user agent software running on the user's behalf on their computer that keeps track of all of this and authorizes as it moves around everything. And that's casual level. When I describe it like that, that seems great. But OIDC is exactly that, and that's a horrific security properties. Right? So we, you know, we have examples of this today, and we have varying levels of what security properties they provide. There are lots of systems built on this. I I would certainly want the security properties that are coming out of work in this working group to be well well beyond OIDC, but well beyond the things that we see commonly deployed today. I think that's one of the reasons to do this type of work at ITF is that we we can we do think hard. We're required to think hard about the privacy properties, the security properties, and how to split this up. It's part of why I wanna do it here versus doing it elsewhere. Thank you.

[01:13:21] **Leslie Daigle**: Thanks. And I'll just take a moment to say I've I've locked the queue because I think we're on trajectory for the amount of time left as currently planned for the discussion. Having said that, we will get to the end of that and then decide what makes sense for a next step in the last half hour we have. Please go ahead.

[01:13:37] **Hamed**: Hi. Can we please

[01:13:40] **Leslie Daigle**: And and do please state your name just so

[01:13:42] **Hamed**: that I'm the Hamed. And can we my quest my suggestion is that can we please define what an AI agent is? Because, there seems to be a lot of definitions of AI agents, what they can and cannot do, what is autonomy, what is reasoning, what is planning. Can they work with LLMs? Can they work without LLMs? So I think it would be helpful for everyone to understand what an AI agent is. So before we talk about problems, I need to understand what an AI agent is actually. So that's yeah. Thank you. Thank you.

[01:14:21] **Suresh Krishnan**: Suresh? I'm not answering that question. Suresh, Krishna. So I just wanted to talk a little bit about, like, what Steven said and also what Alton brought up. Like, just because we put it out of scope for this working group doesn't mean it's out of scope to solve the ITF. There is a discussion that Jeff Lombardo, Daping, and I are kind of working on with Yaron and other people from OAuth to actually talk about this behavioral stuff. So, like, what is the agent what did you authorize the agent to do and what it's trying to do and how you communicate the policy is something that's gonna be done in OAuth and not here. So I just wanna see if somebody wants to follow it. There's a disc a meeting on Friday. On the OAuth session, we have a twenty minute discussion slot to kind of see how we go about this. So please come and attend. Thanks.

[01:15:07] **Ori Steele**: Thanks. Sahid?

[01:15:10] **Zaheduzzaman Sarker**: Yeah. I'm not also going to define the AI agent. I think you can read it. I think we have published a couple of drafts that you can read it. And if you have comments, you can tell us, like, what's we're doing wrong there. So first of all, as a as a proponent, I mean, I'm really grateful to get all these feedbacks. It's really helpful. The two things that I have in mind is, honestly, the goal and the context that need to be propagated. It's not only about context. And then when you're crossing the boundaries, you can actually hide a couple of things, because this is about traceability, accountability. When you cross a domain for a particular purpose, you can hide the goal you why you are crossing the domain and what are the context you can propagate and all those things. The other thing is like when you are communicating the contrast, I think we talked about a control plane kind of signaling and stuff like that that need to be multimodal. But the communication also needs to be multimodal. The other thing that I would like to focus on the framework thing is like the I think we're talking if you really, really want to do in our agentic communication, we are not talking about a single protocol. I don't think, like, this is the one single protocol this working group will produce, and that solves every problem. That's not the case. It's a protocol suite. So how do if we now come to ITF and say, like, Okay, I want to do communication with IT protocol, what do I do? What's the flow? What are the protocols I use? And that's where this framework comes that's initiated the framework thing, which actually holds the key and binds every protocol IT defines and says, like, this is how and these are the protocols we use in this framework. So this is not a framework just for this context propagation or goal propagation or identity propagation. I think the overall idea of this working to host and framework that to bind everything that's happening in IT and they could consume all the working group works here. So thank you.

[01:17:15] **Leslie Daigle**: So I appreciate the proponents are not trying to identify what an AI agent is. But just to come back to that question and address it briefly, I think it's a very fair point to say that when there is a charter for this working group, it should be clear what it means is in the context of an AI agent or the material. So thanks for that input. Go ahead.

[01:17:37] **Yanmei Liu**: Hi. So Sohaz from Cisco.

[01:17:40] **Speaker 12**: Coming from a person who's working with the team, very closely that deploys a lot of agents at scale in enterprise, some of the things that we have seen in the last couple of years is that there's been dozens of agentic frameworks and dozens of agentic platforms that came out. And every time we try to deploy for an application or enterprise use case, we have a fragmentation problem. When I say fragmentation problem here is that in terms of transport lock in, like, each of these things have their own way of using, like, HTTP polling or GRPC mesh, but there's no standard wire format. And something like the some of the there's no way for these kind of tools and platforms to interrupt with, each other. And there's also a lot of security gap. Some many of the important tools that we have seen have evolved using some of the ITF protocols, but still many of them use some ambient keys to basically set up the security properties. This is where an ITF can definitely come and guide the and also, there every different, platform, whenever we want to support an enterprise application, there's a custom blue cloud, glue code in terms of how the coordination happens. There are multiple each of these frameworks or platforms come up with their own way of coordinating between tasks or between, agents. But the when whenever we want to go across different tools and frameworks, we always we keep writing this custom code again, the n square kind of problem, which kind of slows down. And also the agents tools discovery, there's no easier way to do today. That's ad hoc, and it does not scale at the enterprise level. Finally, the most of the real time inter interactions that we do is kind of bolted on. It's the protocol is not built or transport is not built to kind of support these things. These kind of fragmentation problems and we we we we still believe that there'll be a lot of tools and framework that will keep coming in, and we need a better way. And, hence, defining a unified session would kind of solve, the fragmentation problem for and sets, any new tool that's coming in the future to kind of way to enable interoperability. So I can support what we're doing here. Thanks. Thank you.

[01:19:48] **Chairperson**: Naved? He's very tall. Hi, Navita Sunil here. By the way, the chat is fascinating, and I hope you're capturing it because it's too interesting to lose. I have a gap analysis question.

[01:20:03] **Ori Steele**: Please speak into the mic.

[01:20:04] **Chairperson**: Oh, sorry. I'm too short for this. I have a gap analysis question. The charterer already says audibility of agents initiated actions and independent verification is a motivation. But the sessions end and the credentials expire. I think the audit's only worth building if you can point out who was responsible for what that agent did. The charter routes identity to Wimsy and OAuth, but those are runtime credentials, and they don't point out a durable owner. And so Yaron Chefer on the Wimsy list noted in the agent auth draft review and said, you know, in what registry after the agent is gone. So will the gap analysis name a durable ownership as part of the building block? Or will it assume that's covered elsewhere? And if so, where? Thank you.

[01:20:52] **Stephen Farrell**: So

[01:20:56] **Ori Steele**: just briefly, I I know there's been some discussion about, you know, protocol layer and then, like, logging and, you know, auditing layers separate. And so I encourage folks to follow the discussions within the ITF, various side meetings on this topic of sort of the authorization layer being part of the session and then evidence of previous interactions with agents for auditing and long term retention purposes. Lionel, go ahead.

[01:21:26] **Lionel Morand**: Lionel Morand, Huawei. So maybe some context, I would say. This buff is not coming from nowhere. We had a lot of side meetings, maybe too much, a lot of drafts, AI generated or not. But we had actually a lot of use cases regarding the agent communication. And, actually, what we have so far is something that we have identified as a proponent as at least a minimum to be done here. Of course, we are clarifying the scope, but it is the point. Regarding the question of the definition of AI, actually, we have AI agents. We could say the same for tool or even for user, and it will be part of the clarification in one of the deliverable when we are seeing that we will describe the use cases and clarify the problem statements. So along the work done on the context management, on session area, or whatever, we will we will we will do also the job here. The other point is that I think that no one said that the notion of a context management is something difficult to address, and it might not be specific to AI agents. But for sure, we have existing use cases with AI agent, and it is what we try to solve here. After that, if the solution can be reused for any other context, it will be fine. But I think having at least one specific use case and trying to address that is the right way to progress here within IGF. And why we did within IGF? Because we assume that we are building solution on top of IGF solution protocol. So it's why we are also inviting people to join the the job coming from other open source communities, ITU, or whatever. But because we want to rely on IETF protocol, I think it's the right place to do that. And, that will conclude my comments. Thank you.

[01:23:12] **Ori Steele**: Thank you. Pam?

[01:23:14] **Pam Dingle**: Yes. Pam Dingle from Microsoft. I think there are a couple of things missing from the Charter that I I would suggest you at least debate and see if they should belong. First of all, what we're really talking about here has another word that I hear more commonly talked about, which is orchestration. So I would suggest deciding whether there that is the same thing or not and and including that in the charter for disambiguation. Second, the, you know, the framework does not mention cross domain implications, I think, from a chartering perspective. You do say Internet or intranet in that charter text. I think you need to be more specific because crossing domains changes all the context that Colin talked about. Third, I think performance. Is this thing going to be performant? I think that should be also charter relevant, or at least very high level. And lastly, those of us who work in identity know that starting a session is easy and revoking it is hard. And so I would like to see something in the charter that talks to the places where, for example, federation ran into big issues. Right? How do you revoke a thing if the agent is no longer available to execute the the order?

[01:24:29] **Leslie Daigle**: Thank you.

[01:24:32] **Tong Feng**: Tong Feng from China Telecoms. Yeah. We all know that AI has been a major focus of open source communities. And so regarding the context and the framework raised by the proponents, my question is, have you had any discussions or correlation with open source communities? I think such kind of coordination or cooperation should be encouraged and supported for for your work. That's my suggestion. Okay.

[01:25:06] **Arashmid Akhavan**: Arashmin Ekabin, Huawei proponent of the both. So there are one thing I want to emphasize that there are many different functional blocks that the agents basically communication have to go through. Identity, security, and those things as well as in all those things are important. In this particular working group, we try to carve out this particular piece to actually work on, which we think this is one of the most important parts. However, we need other working groups to actually help us to actually with things like identity, authorization, and those things. But we cannot do all of these things in one working group. So that's why we carve out this piece. As far as collaboration with other entities outside OETF, yes, that's the that's the very good noble idea. However, we cannot force everybody hands to actually come here. So they have we hopefully will try to actually create an environment which is inviting enough that other people can actually feel that, oh, they can actually bring work here and collaborate with us. So we don't have any leverage on those organizations, but hopefully, we'll be inviting enough so that they can actually feel free to come and work with us.

[01:26:27] **Ori Steele**: Alright. Aishin?

[01:26:32] **Aijun Wang**: Yeah. Hi, John. I I'm very curious. You know, we declared this protocol should be will be used by the eight way or MCP, but there is no expert from the eight way or MCP express their requirement here. So I think maybe in future, maybe the eight way and MCP develop their own system control protocols. So, and their speed is faster than us. So, I want to ask, how do you think such trend? Maybe we'll do some future work.

[01:27:14] **Ori Steele**: Do any of the proponents like to respond?

[01:27:18] **Suresh Krishnan**: I think the

[01:27:19] **Lionel Morand**: next person Okay.

[01:27:23] **Ori Steele**: Yanmei?

[01:27:30] **Yanmei Liu**: Hi. Yanmei here. I wanted to say that the agent protocol for multimodal commit communication is quite useful. We do have scenario for multimodal agent communication. The omnimodels that's trying to understand the real world through video frame and audio input. And I also wanted to recommend that the working group also take consideration of the low latency communication between user and agent.

[01:27:59] **Ori Steele**: So who who is we? What affiliation?

[01:28:10] **Yanmei Liu**: Yeah. Yeah. I'm working for Alibaba.

[01:28:11] **Ori Steele**: Oh, thank you.

[01:28:12] **Suresh Krishnan**: Yeah. So I'm proud of, like, Suresh Krishna, she's, like, working on the NCP implementation to answer agent. She's working on NCP stuff for Alibaba and deploying it.

[01:28:21] **Ori Steele**: Oh, thank.

[01:28:24] **Suresh Krishnan**: Into the discussion in the mic. Sorry. I was trying to face Ai jen. So to answer that, like so Ai jen asked, like, who's implementing MCP and deploying it? So Yanmei is deploying implementing and deploying MCP for Alibaba. Thank you.

[01:28:42] **Aijun Wang**: I think the Alibaba is just one one company. They they also proponent. You know, the the eight way proto is not defined by Alibaba. I think the more opinion from the other our expert, other company may be more convinced.

[01:29:01] **Ori Steele**: Thank you.

[01:29:04] **Leslie Daigle**: Okay. So okay. Dipeng?

[01:29:09] **Daping Liu**: So sorry. So just one quick response to the comment earlier comments about open source coordination. I I disagree with the comments that the open source, for example, MCP community is not involved. Actually, if you look at the chapter, you will see there is a pull request by the MCP core maintainer David. So, basically, he give us very concrete feedback. I think that that idea is also mentioned by today's discussion by other experts also to try our best to reuse existing patterns. For example, the commutation patterns for agent tool calls, and then basically extend a little bit to more semantics, as experts also mentioned. So, also, from other parts of the building block, we do have experts who get very deeply involved in MCP open source community and try to bridge those MCP open source community and other efforts in Linux Foundation in ICAP. So so I disagree with the point. I think that is reality and already happened. Yeah. Thank you.

[01:30:24] **Ori Steele**: Alright. Thanks.

[01:30:27] **Leslie Daigle**: So we are at time for the next step in our agenda. I think that it's pretty clear from discussion this morning that there isn't in fact enough support for the charter as drafted to do the call for moving that charter forward. I do though think there is enough momentum in this room to say there is some well scoped work that can be done within the IETF to address what the proponents are trying to get at. Would like and before we end this session, would like to capture that sense of momentum so that we can move forward. I suspect that we will have to have a new mailing list because we've been hanging out on the agent to agent list which is doing a lot of work and we don't want to get lost in the shuffle of all the other work, too. So what I'm getting at is I think I'm going to try to quickly draft a show of hands to confirm that there is a sense in this room that there is IETF work that can be done here even though we don't yet have the charter drafted for it. Is that a fair thing?

[01:31:43] **Ori Steele**: Yep. We want to ask you all the BOF questions So we have good input for the ADs and good context for the remaining charter discussion. The current draft charter is in the hands of Charles, I who I should have introduced at the beginning of the session. Charles is the responsible AD for for this session. He's in the front.

[01:32:03] **Leslie Daigle**: So do you wanna do the actual lock, or do wanna do some generic questions?

[01:32:07] **Ori Steele**: Nope. That's too generic.

[01:32:08] **Aijun Wang**: Yeah.

[01:32:17] **Leslie Daigle**: Jonathan.

[01:32:19] **Jonathan Rosenberg**: Jonathan Rosenberg. I I think I think we had a little bit more than just there's something to be done here. And though, admittedly, there's surely plenty of microediting that can be done on a charter, like messing around with the definition of AI gen or whatever. I do I would like I would be interested in the questions being asked, whether people think that we should do work on a protocol and a framework.

[01:32:43] **Colin Perkins**: Thank you.

[01:32:44] **Leslie Daigle**: So I'm absolutely fine with asking those questions. Where I think we're going to run into troubles is when we start talking about the actual charter text, because I don't think there's agreement for the actual charter text beyond just micromanagement. But I could be wrong. We can try we can try the standard buff questions.

[01:33:00] **Brian Trammell**: So apologies if you're completely ignoring your authority to control the queue. Brian Trammell, plus one to Jonathan. I do think there's probably also a thing that you wanna do where you've got a larger community of people, especially the people who've been active on the chat. I'm one of them who would be interested in joining that charter word bashing discussion that's obviously going to happen after this meeting because it's already kind of happened in

[01:33:27] **Leslie Daigle**: the chat. So as Ori mentioned, Charles has control over the Right. GitHub of the charter. So

[01:33:34] **Brian Trammell**: Got it.

[01:33:35] **Leslie Daigle**: We will create a new mailing list. It is a public mailing list for onward discussion, including that.

[01:33:39] **Brian Trammell**: Do we want to start sending PRs to that charter GitHub or do we want to wait until we have a mailing list discussion? That's my question.

[01:33:45] **Ori Steele**: You are welcome to send PRs to the charter. The RDDs control the change control for the Perfect. Okay. Cool.

[01:33:54] **Zaheduzzaman Sarker**: Thank you.

[01:33:56] **Leslie Daigle**: So I have launched a poll. Do you think that the problem statement is well understood, solvable, and useful to solve? K. We seem to be settling down, although only about half of you have voted. Go ahead, Charles.

[01:35:02] **Charles Eckel**: Yeah. Charles Ecclesisco and also responsible AD for this, Boff. Just wanted to just clarify a few things. It's pretty much in line with what Ori and and Leslie have already said. Yes. Pull requests on the charter are welcome. Yes. We will work create a mailing list for that discussion to happen, probably called agent proto.

[01:35:27] **Leslie Daigle**: Suggest a better name in the chat. Quiz.

[01:35:29] **Charles Eckel**: So that will happen, and you can have discussion on the charter there. When you hear us talking about the problem statement, I think there's a a couple themes that that I heard. One is, you know, a focus on perhaps what we call context, and maybe we need a better word than context. But, you know, when you think of session, that that session is a place where that context lives. And and then so assume we'll be doing something like that, and you can help us with that wordsmithing. Also, what an agent is, maybe don't get so hung up on that. Let's think about the the use cases and requirements of the communication that come out of that and assume that we'll straighten that out. So, hopefully, that gives you an idea a clearer idea. Don't get so hung up on the exact words, but the the spirit of what we're trying to solve with this problem statement and trying to address. And so as we go through the rest of the questions, I hope that helps. Just have that in mind that those things are going to happen and then answer the questions, you know, with that mindset. Thank you.

[01:36:33] **Leslie Daigle**: Thanks, Charles. Ten second timer on the closing of the poll. Get your last choices in. Okay. Thank you. That's a good and concrete input. It's not a slam dunk, but there is very clearly support for the problem space. So we're going to step through all of the standard questions. Thank you, Jonathan, for not letting us wriggle off that hook. And here's the next question. Is the need for interoperability clear?

[01:37:18] **Ori Steele**: To be clear, this isn't necessarily a standard question, but it's one that I've added in. So if you don't like it, it's my fault.

[01:37:54] **Justin Richer**: Clarifying question on the poll. Are we avoiding calling out interoperability of what?

[01:38:02] **Ori Steele**: Fair. This is my fault. The intention is interoperability in the proposed standards deliverables components of the charter. So the session protocol and the framework are the two existing deliverable. Okay. Sorry.

[01:38:21] **Leslie Daigle**: We can call it whenever you want. Okay. I think I think we're just about settled out. I'll give you a few seconds to make your final choices. Okay. It's bouncing up and down now. Thank you. Thanks. Alright. Do you think the IETF is the right place to do the work? You seem to be settling out, so I'll give you another few seconds to make your choice. Okay. Thank you. Alright. Now we get into the scary stuff. Do you think the initial scope from the charter we just discussed is correct? Okay. I think we're settling out. So another few seconds, and then we'll call it. And Ori asked me if we should be asking if people who say no wanna step up, but I think that we've heard a lot of that in the in the hour of discussion that we had. So okay. Thank you. So the next question is do you think the deliverables we've discussed are correct?

[01:42:23] **Laurent Ciavaglia**: Laurentia Valley and Nokia. Just on this question, the previous one, I think, could be important maybe offline to situate because it's is it correct? Not to be confused, is it complete? Part of it may be correct, but people don't agree that it is complete.

[01:42:36] **Leslie Daigle**: Yeah. I appreciate these are binary questions, and it doesn't mean I think the earlier comments make it clear that people think there is something here, but it's a question of tuning it, not a question of starting over from scratch. We seem to be settling out. I'm going to give people a few more seconds to vote. Not that we vote. Provide their opinions. Going once, going twice. Thank you. And now the biggie. Do you think a working group should be formed on this topic with a charter based on the draft charter we just discussed? K. We seem to be settling. Going once. Going twice, sold. Thank you. Now the easy one to ask and hard for y'all to commit, are you willing to help write and or review drafts in this potential working group? Thanks for the enthusiasm. K. I think we're pretty close to done. Give you a few more seconds to get your vote in. Five, four, three, two, one. Sold. Alright. Thank you all very much. That's very useful, input for the onward process here. I would say thank you all for your input and thoughts, both in terms of the content and structure and direction, and in the redirection of our discussion here. Do we have anything else that we really need to cover? I

[01:46:28] **Ori Steele**: think we've covered these questions. That mailing list is the the one where we've been meeting up until now. As Charles mentioned, you know, we're really hoping for a smaller, more focused on just this work mailing list to continue the discussions for the draft charter.

[01:46:46] **Leslie Daigle**: Yeah. Before I unlock the queue, I'll just say that I think that it's, as I said, really helpful input and does provide clarity about where more work is needed, so it's been very constructive. Alright. I will unlock the queue and happy to run it till the top of the hour. Go ahead, Alyssa.

[01:47:10] **Alissa Cooper**: Thanks. I was wondering if you could do a show of hands of who would implement the protocol of the shape that we talked about today. Might be nice to have one more poll in the record with the others.

[01:47:24] **Leslie Daigle**: Sure. I can put that in as a queue that people can answer while Myria is on mic. There we go.

[01:47:33] **Mirja Kühlewind**: Yeah, Myria Kulevent. I just have a very quick admin question or request. Talking about mailing list, I would like to request the ADs or the IHG to kind of take a broader approach about which mailing list you really need. Right now, everything is crumbled into one mailing list. That's not very helpful, but we should also not create 20 of them. Right? So let's try to figure out, like a small number where we can get the different discussions somehow distributed such that they wouldn't overlap too much but we still can have a useful discussion.

[01:48:07] **Leslie Daigle**: I think that's a fair point, my counter is that I think we're on the verge of becoming a working group, so having an area that's pretty specifically focused on this seems to be important in order to achieve liftoff. Yeah. Arnaud?

[01:48:23] **Arnaud Taddei**: Yeah. So I'm really confused now. So we have a poll. In the poll, we have a clear no on the charter, and yet we have a clear yes for a working group. So what's the process now? Is it like a or?

[01:48:41] **Leslie Daigle**: No. So the process now is we take everything that's been captured from this discussion and people then start contributing to refining the working group charter. The problem isn't that people think the workspace is wrong, the problem isn't that people think this is off the rails, it's that we don't currently have a charter that captures accurately what can be done within the IETF and what should be done at this time.

[01:49:07] **Arnaud Taddei**: Right. So let's assume we work on the mailing list correctly. Let's assume we step by step get to a charter. How how how is the process then? We we have a new buff in November?

[01:49:22] **Leslie Daigle**: So I invoke Charles.

[01:49:36] **Charles Eckel**: Yeah. So thanks for that. I I think I I think I'm gonna maybe provide a little bit more of what I was thinking to provide at the end because I I think it'll be be helpful. We we obviously had a lot of people show up for for this bot. I really appreciate that. I counted I saw 325 people at at one point. That's fantastic. My sense of the room is is that we're getting a lot of people kind of coming to similar conclusion that there's something useful for us to do here. I'm actually glad that it wasn't just like everyone saying, yes. Do this. Because then that means as we would have messed up, like, we should have chartered this a while ago, and and we took too long. So this is why we have the boff, right, to describe an idea that that we think makes sense and get some constructive feedback, and and you certainly provided that. So I I think we all know that the the charter needs some work, and there's many people who put their hand up saying they're going to help refine that charter, so that's fantastic. Now what's going to happen is still maybe too early to say, but we could form a working group before the next IETF. Perhaps it won't go that well, and perhaps we will need to have another BOF. I'd say that's still to be determined, and a lot of that depends on how the mailing list discussion and the refinement of the charter goes. But what I'm seeing is we we have a a really good step in the right direction

[01:51:10] **Suresh Krishnan**: here.

[01:51:12] **Leslie Daigle**: Thanks.

[01:51:13] **Laurent Ciavaglia**: Thank you.

[01:51:18] **Arashmid Akhavan**: So Arashmin from Huawei. To add to what Mirja was saying, so in terms of mailing list. So we are going to create a new mailing list, but I think we need to actually manage that mailing list better so that, you different topics that are related to agentic, but not related to the working group and this bot.

[01:51:35] **Leslie Daigle**: Yeah. That's that's really the point of having a Right. A new space. I mean, I I will say there were times where there were discussions on the agent to agent handling this where I felt, well, that's not actually advancing the this box work, but what can you do? So yeah.

[01:51:49] **Arashmid Akhavan**: And quite frankly, you know, the the the noise is so much that, you know, the the the actual topics that are related to this box is lost.

[01:51:56] **Leslie Daigle**: Because it's a big space.

[01:51:57] **Arashmid Akhavan**: Yes. It is.

[01:51:57] **Leslie Daigle**: Yep. It is. Yep. Thank you. Go ahead, Grace.

[01:52:01] Speaker 32: Yes. So I'm Grace. I'm from the Decentralized Identity Foundation. So the scope of the first part of it, of the session, or the context, whatever you want to call it, is squarely within IETF and how it works, which is kind of a hyperscaler driven world, a hyperscaler driven Internet. And I think the reasons that AI is different, one is that it's moving incredibly fast and mutating itself, which is not really similar to other things. And the other is that we're in the middle of a huge geopolitical shift. And having the know, originally, the Internet was developed as a government project out of The US, and now it's migrated to something that where enterprises and hyperscalers are working on it. And now we're moving into a world where a lot of influence from Southeast Asia and the Chinese developers is moving into this world of AI. And my concern specifically for IETF and for this working group is about the revocation and transformation of specifications. I think that solving these short term and medium term problems around context and AI is really important, and it's important to say that the framework question, which is the second part, isn't set yet. And if the framework turns out to be completely different from the framework that the Internet has run on so far, there needs to be room in the IETF to make those shifts if the IETF wants to continue to be relevant. That's really where I think there's a process question about how quickly can the IETF change if the path that's chosen by a framework isn't the right path or isn't the one that becomes consensus. I think there's a right path, but let's just say, in a really huge geopolitical and AI shift, I think we're really early and there needs to be some kind of mechanism for making those changes for the IETF to continue to have the weight that it does going into the future.

[01:54:17] **Leslie Daigle**: Okay. Thank you for that. I'm just going to observe that I've locked the queue. There's six minutes left in our time slot, so people can be brief. Go ahead.

[01:54:29] **Hisham Al-Khasib**: Wu Changsheng from China Mobile. Know, AI agent evolves very rapidly. So I think ITF standardization should keep the pace to meet the requirement. So if the working group performed, I hope the working group can timely deliver the standards for the industry. Thanks.

[01:54:56] **Leslie Daigle**: Thank you.

[01:55:00] **Roberto**: Hi, folks. Yeah. Is it me?

[01:55:03] **Ori Steele**: Yes.

[01:55:04] **Roberto**: Roberta here. Yeah. Hi. My perspective as someone that has started coming to IETF is that this is a protocols issue, and you're really known about protocols. And I really wanted to point that we have the expertise to be able to solve some of the issues of the protocol and not addressing here frameworks or interoperability or other stuff. But the protocol itself, we know that we have some flaws because all the layers got together. Everyone here will have an a different opinion about what is the the issue. Mine is the flavor of security, but, you know, I think what is happening now is that we don't have a place where we can talk about this without the, the ideas getting lost into a sea of not being a working group and being, you know, supported by a process. And I really wanted to say that this makes me really happy because I think this is will be the place where we're be we're going to have this, you know, this this breath to be able to do the work that, I think everyone here wants to do, which is to fix some stuff. Because in here, we want to fix some stuff to help the world. And I really believe that, and I really want to contribute. Okay? Thank you.

[01:56:28] **Leslie Daigle**: Thank you so much. Suresh.

[01:56:33] **Suresh Krishnan**: And thank you very much for Suresh Krishna. So thank you, everybody, for a lot of the comments. There's a lot of things I learned in the especially in the chat and, like, know, how people start like, especially Ted kind of, like, clarify a lot of the things. The concern I have is, like, you know, all these things are gonna be lost because they're not on the mailing list. They're not on the chatter PR. So can I request the chairs to do some kind of once the new list is set up, to do some kind of call for charter comments or something with the time box wherein, like, people can actually come and contribute? But I also promise to look into the chat after the meeting to try to see if I can start throwing PRs at Charles because I think we have some amazing momentum. I just don't want us to lose it going to the next meeting. Thank you.

[01:57:12] **Leslie Daigle**: Yeah. Plus one on the momentum.

[01:57:14] **Ori Steele**: Yep. We can do that.

[01:57:16] **Leslie Daigle**: Alright. Again, thank you to everybody for coming, for showing up, for participating, for participating in all the polls and providing clear input and direction. And and once more, thanks to all of our opponents who put a lot of work into providing a clear explanation of the ideas and what we're trying to do here. So, Charles?

[01:57:35] **Charles Eckel**: Yeah. And yeah. Charles Eckel. I I wanted to take this opportunity to to thank the chairs. I think you guys did an amazing job. Really, really.

[01:57:44] **Leslie Daigle**: Thank you.

[01:57:49] **Charles Eckel**: And then, I guess, also, just again to thank all of you. I think you've you've given me a lot of I don't if I'd say ammunition, but but good stuff to bring back to the rest of the IESG and start to bring them on board with the discussion we've had here. So so thank you for that.

[01:58:04] **Leslie Daigle**: Thanks.