**Session Date/Time:** 20 Jul 2026 12:00

[00:00:26] **Tobias Fiebig**: Yes.

[00:00:47] **Ari Keränen**: Okay. It's 02:00, so time to get started. Welcome, everyone, to the Thing-to-Thing Research Group meeting here. First, as you saw, a quick reminder on the note well. You are being recorded if all goes as planned. Remember to be nice to each other, and the IPR guidelines apply. There's also a longer version of the guidelines in the chair slides. Go check them out or ask us chairs if you need to more need any more details. Also, very quick reminder of the goals of of the IRTF. So here, we focus on the long term research issues related to Internet, while the parallel organization, the IETF, focus on short term is just engineering and standards making. So this is about conducting research and not doing the standards, although, of course, there's a lot of cross pollination of ideas and people between those organizations. Quick note on the admin side. So for the notes, you can all join the the IETF note-taking tool. Thank you, Chris, a lot for volunteering to help with the note takes already. There's the Meetecho chat, and you can also join with Zulip. And if you're not already on the mailing list, we highly recommend you to join it. That's the place where we announce all the related act activities, etcetera, so you'll be able to follow what goes on on on the research group. And as always, we have a a repository git at GitHub for each of the meetings where you find the latest information and details. A very quick note on the status of documents. We do have one document at the IRSG review, the operational security considerations of manufacture installed keys and trust anchors. There are a couple of documents, resource group documents that are getting ready for last call. There's the guidance for RESTful design for IoT. A Few final things to fix there and then call for last call, and also recently updated the terminology and processes for initial security of IoT devices that is approaching maturity to get get ready for last call. So we very much welcome your reviews on both of those documents. There's also one more resource group document in progress application attacks using CoAP. It needs a bit more details on the mitigation side, but then we also believe that we'll be ready for last calls pretty soon. And a set of documents that are upcoming candidates for adoption, including routing with CoAP, distributed software updates with end to end group communication, and the dereferenceable identifier pattern. But the key topic and scope for the meeting today, would be the role of the IETF IoT technologies in enabling AI agent interaction with IoT environments. So we chose this topic, to follow-up on on the discussions we had at the IETF 113 in Madrid, where Jaime Jiménez presented his work on how the current technologies can be used with AI agents to solve many interesting use cases. And what we learned already there is that the IETF IoT self description technologies, for example, CoRE Link Format, SDF format, etcetera, they can help already today to discover or agents to discover interaction capabilities of the IoT devices. And also, there are currently existing IoT protocols and data formats, for example, are quite usable for agents already. But, of course, there are still gaps and and needs for evolution. So this would be this session would be about discussing where are those gaps, where's the need for evolution, what should we do about it, And also, are there some areas that are missing enablers completely? For example, security is probably an area where much more work remains to be done. But, of course, this AI agent topic is much broader than the things in T2TRG. There's a whole range of AI agent topics across the IT for IRTF, you know, for many POFs, DAWN, Agent-Protocol, for example, and site meetings this week alone, and dozens of of of documents.

[00:04:45] **Tobias Fiebig**: However, a lot of that work is mainly in the software and cloud domain, whereas here in the Thing-to-Thing Research Group, we,

[00:04:51] **Ari Keränen**: of course, care about the things and the associate device of the physical world. So here, we'll be looking at this agent and physical world interaction, intersection where the agents can discover and act on the real IoT devices. So with that, we have now two main themes within that topic. First of all, discovery is, of course, a very critical part of these automated in interactions, how agents can find other agents services, but also devices that are very much of interest in the Thing-to-Thing RG. And here we have two topics two presentations today. Adrian will give us an overview of of the dawn of discovery of agent workloads named entities, and Jari Arkko will give an overview survey of the agent discovery landscape. And if all goes well, also a short demo. Then on the second part, we have to focus on the device interaction stack, how the agent can actually understand and then act on the devices themselves. So here, Oscar Lopez will talk about LLM asset translation between YANG and IoT data representations. And Lorenzo Cornea will talk about enabling AI agents on the IoT stack, what kind of, potential enhancements we could have for CoAP and SDF to support this. So here's then the full agenda, and then we have, as you can see, at the end of the agenda, we have also a fifth talk from Tobias Fiebig on losing end to end language with the Tower of AI. This goes, of course, well beyond the topics that we had in in the earlier parts, but it's also part of our ongoing work to interact with the local, research community. So Tobias has recently, been a Berufener Professor in the local university. So very much looking forward to that, broader view and hear about it. So that's the plan for today. Any questions or comments so far? Okay. Then with that, I'll give the floor to you, Adrian. Oh,

[00:06:59] **Adrian Farrel**: it's a nice spotlight. If I stand like this, I am not a national socialist. Okay. Oh. You wanna start with me? Yeah. Sure. So I'm I'm gonna start this with some apologies.

[00:07:18] **Tobias Fiebig**: Yeah.

[00:07:18] **Adrian Farrel**: I'm not physically a 100%. My laptop broke overnight. I bought a tablet this morning to write these slides on to replace the slides I'd written but not uploaded. Slides are always worse the second time around.

[00:07:37] **Ari Keränen**: Yeah. Now we see it has some technical problem with the slides. They're not in the not in the yet.

[00:07:45] **Carsten Bormann**: Can you just Yeah.

[00:07:47] **Ari Keränen**: If you without the meeting. Like, without the window.

[00:07:50] **Adrian Farrel**: If you'd accepted them late, you have to press the magic button.

[00:07:53] **Carsten Bormann**: Yeah. Yeah. Right. And it's probably down here with three thingies and there's something like we know it.

[00:08:00] **Adrian Farrel**: So while we're doing that, Dawn is above tomorrow at 2PM. It's aimed at working group forming. It comes out a buff in Brisbane called Catalyst where we tried to pull together, perfect, the the strands of all the different crazy side meetings that were going on about AI with the aim of finding some pieces of like, you know, functional units within the space. And one of them turned out to be discovery. So that's pushing forward for a BOF. A big challenge is that there are lots of pieces around the discovery ecosystem that are not part of Dawn that people correctly want to solve. So the way I've approached this in a bit of a hurry in the last hour is to lift some text off the charter to try and set some scene scenery here. So it's it's looking at kind of the distributed processing environment that is classical AI agents. So one agent an example is a travel booking system. And you go to the agent and say, well, I want to go to Vienna next week, please. And the agent that agent says, well, I need to go and talk to ABB, and I need to go and talk to Austrian Airlines, and I need to find out which which roads are closed. So I need to talk to different agents to find more information. How does it find those agents? Along the way in this discussion, we got ourselves wrapped around an axle of why is this only agents? Surely, this looks exactly the same if you're looking for workloads or named entities. You're just searching for things that you want to reach out to. So we sort of restructured as as entities and we put in a definition of entity. And that I guess is what brings me here today. Because when is a thing a thing? What is a thing? Do you have a neat tidy definition in this research group of what a thing is? Yes. Oh, cool. Well done. Then you're one step ahead of me with entity. There's clearly some kind of overlap here, know, finding things. Does an AI agent need to find the things? Do the things need to find AI agents or other entities? So after a lot of backwards and forwards, we decided that the pressing need in the industry at the moment is AI agents. All the other stuff is super exciting and fun and there's no desperate drive. My personal one, I I chair the CATS Working Group. One of the things we have to find is places that can do compute for us. So I got sort of excited. Oh, Dawn could Dawn will address all my CATS problems and I can close my working group and go go home. But talking to the ADs, talking to the community, AI is just so driving everything. What we've done with our draft charter, and this is just a draft, we haven't had the buff yet, is say, the first thing we're going to focus on is AI agent and we're going to be aware sort of in a Star Wars force way. We're going to be slightly conscious of the applicability to other entities. So we're not ruling them out accidentally, but they're not driving our work. There's a little bit here about metadata that, you know, it's it's not enough just to say, find me an entity. You've gotta say, find me an entity of this type possibly with these capabilities and maybe not too heavily loaded at the moment. And drawing the line between the core base print principles, the metadata, and all the other gloop about, well, I don't wanna trust something from this vendor and and so on and so on and so on, should not be part of the discovery system. It should be part of a later authenticated capability exchange. So given all this stuff, wouldn't it be cool if we had an interoperable way of doing this? Preferably generic, but let's focus on AI agents first. Wouldn't it be even nicer if we used existing protocols so we don't have to develop stuff again? Although it's fun developing things, if you want to hit the field soon and not crash on early deployment, then picking an existing protocol is is the way to go. And the the bottom line I think is it's not just discovering agents within your silo. It's discovering a bigger agent space, finding things that are are out there. So where possible, do it in a modular way. Modular nice. Use existing ITF protocols if possible. And what that led us to write in in the draft charter is, let's start by looking at DNS and see whether it does the job. If it doesn't do the job, okay. Move on. Pick something else. But, you know, there's there's a possibility that DNS is good enough for what we need. But we have to cycle around and and clearly document what we need before we can say whether DNS will do it for us. And, yeah, ultimately focus on the AI agents. Out of scope is really important because this is a a big ecosystem that is necessary to support discovery and to use the results of discovery. And what we hope is that we can put all of these bullet points out of scope of dawn, which does not mean out of scope of the ITF, And chatting to the AD this morning, he was totally happy with the idea that we've come out of this both with two working groups or maybe three working groups. Picking off not just discovery, but one or two of these other bullets. So clearly getting stuff into a registry in some kind of authenticated way is really really crucial. How you discover where you go to discover is out of scope but is important. What happens after you've done discovery to get all this bulk capability information out of scope? And the agent to agent communications way out of scope. There is another buff on Agent-Protocol for that that piece. So we have few questions that are kind of open to the both. What about these other functional blocks? Where should they go? And and, you know, it's a total possibility that the the boss will say, we don't care about discovery, but registration is really important and everything swerves over. Should we remain focused on AI agent or should we look at broader entities? And I guess that's where you guys start getting excited. What are those basic building blocks of discovery? What do we actually need to ask for and receive back? Do we do do we limit ourselves to some kind of organizational boundary or is this internet wide? And do we start with DNS or do we have to spend some cycles understanding the problem before we even look at a protocol beauty contest? That's all I have to say based on the thirty minutes between buying a new tablet, configuring it, and getting slides to these guys. But I'm happy to have a conversation.

[00:17:45] **Ari Keränen**: Excellent. Thank thank you, Adrian. So, yeah,

[00:17:47] **Rahul Jadhav**: we do

[00:17:47] **Ari Keränen**: have some time for discussion here. I think we have on the queue. Go ahead.

[00:17:56] **Dirk Kutscher**: Hi. I'm, ITF chair. This is just a, you know, technical question. Thanks for introducing this. So I was wondering the DNS idea. So DNS is, of course, great because it gives us this coordinated namespace. It gives us resolution at scale. Where it's maybe not so great is creating new names on the fly, which could be maybe a thing in agentic networking, especially in the IoT. I'm just curious what's your current thinking of this.

[00:18:33] **Adrian Farrel**: Yeah. Yeah. You know, DNS is is is not good at some things. And I if if you'd ask me to list them, I'd have said bulk data. Mhmm. Names on the fly is interesting because I think there's an assumption that the registry, at least the distributed registry, needs to be really tightly screwed down because the whole idea of you accidentally going out to an AI agent that isn't what you think it is, that's big disaster. Right. So possibly, there's a domain hierarchy here. So, you know, you're in the home or you're in the office or the factory, and the discovery can be much more dynamic because it's not you're not opening up to the rest of the world to come in and use your agents.

[00:19:32] **Oscar Lopez**: And

[00:19:35] **Adrian Farrel**: would you use DNS in that environment? Don't know. Possibly, you could because the the register is much smaller. So you wouldn't use DNS to actually populate it, of course. You'd use some other management loop. And

[00:19:53] **Dirk Kutscher**: so right then, if you have the name, you still need to figure out, can I trust this thing? Right? So who authorized it and then so on?

[00:20:03] **Yari Arkko**: What

[00:20:03] **Adrian Farrel**: I mean, I I think this is like a three layer thing. Just like there is when you're searching the web. Okay? First first level, you do a search. It's kind of intent based.

[00:20:13] **Dirk Kutscher**: Right.

[00:20:14] **Adrian Farrel**: Back from that, you get a a pointer, URL, whatever

[00:20:17] **Oscar Lopez**: Right.

[00:20:18] **Adrian Farrel**: That you now need to resolve into an immediate IP address. And there may be load balancing going on there. And then, you've got to actually set up a a communication and that's gonna have a lot of authentication in it as well.

[00:20:36] **Dirk Kutscher**: No. I'm just saying, I mean, in in in the web, for example, I mean, we have DNS, and then we have another mechanism to establish the trust to a server. Yeah. So in just I mean, this is, of course, very early on the discussion, but maybe in the IoT, we have slightly different requirements that require different ways of doing this. It's just what I'm currently thinking. Thanks.

[00:21:02] **Ari Keränen**: Excellent. Thanks thanks, Durkan. Yeah. Absolutely. As you said, like and then on that IoT, more specific things, would have very much of interest in in this group. Whereas, Dawn would be looking at this agents and the very broad picture, and then those that are especially more uncertain and likely need more research. Perfect fit for here.

[00:21:18] **Adrian Farrel**: Yeah. I just cut in on that and said to both of you, if you as time progresses, you notice that Dawn is doing something that is 95% of what you need, but just as a little bit off, then, you know, come and nudge us to be able to welcome IoT. If on the other hand, you find, well, we're only 50% of what you need, then it's clearly separate. Sorry.

[00:21:49] **Daniel Smullen**: Yes. This is, Daniel Smallen speaking. So this is really interesting because I encountered some of these functional blocks that you're mentioning, while trying to solve some of the problems related to the work I presented earlier today in IoT ops. And that was actually about privacy preferences. And I guess the sort of nasty, big, hairy problem there is that when you're talking about things like capabilities, you're then talking about maybe processing capabilities. But if you peel that layer back just a little bit further, you might start talking about things like data types, purposes for processing, the kinds of things that you might want to impose limitations on, which are not easy to do because from a security sort of role based access control and authorization standpoint, it's not really easy to distinguish them. Right? Yeah. And so I'm wondering the extent to what you thought about that particular part of the problem, noting that you did say a moment ago that that whole capability thing was kind of out of scope.

[00:22:48] **Adrian Farrel**: Yeah. So I have a PowerPoint slide that I drew while I was on a call with somebody on a completely different topic. And it kind of shows an architecture of functional blocks and interchanges between them. And every time I show this slide to somebody, they say, yes, but So I haven't gone public with it. But I feel that there is a need for the community to have this big architectural view and discover whether it's applicable broadly or just in one environment. And then we can start filling in the boxes. Yeah. The trouble with coming late to the party which the IGF definitely has is that everybody has gone away and formed their own architecture in their head and nobody's actually drawn it. So if if you'd like to huddle with me at some point and I'll show you my picture and you show me yours.

[00:23:57] **Daniel Smullen**: I I I want to, if I may, sort of maybe redirect a tiny bit here because I'm not sure that necessarily the problem is even architectural in nature. It may even be a problem of semantics. Right? And so, in the in the privacy context, this comes about because, you know, you've got these privacy policies and everybody sort of defines them differently, and every company's got their own policy, and they use different vocabularies and so on and so forth. And I think that the same problem exists when you're talking about AI agents and the exposure of their capabilities. And so I wonder if maybe, you know, perhaps there's obviously architectural touch points here. Right? But I think that there's something missing here. There's some sort of mechanism for disambiguating these things that I'm just I'm not sure where that goes.

[00:24:48] **Adrian Farrel**: Yeah. Yeah. I mean, I and I think our answer to that has been that the discovery

[00:24:52] **Yari Arkko**: Yeah.

[00:24:53] **Adrian Farrel**: Is of only a very basic set of properties.

[00:24:56] **Oscar Lopez**: I see.

[00:24:57] **Adrian Farrel**: And then then you start a conversation agent to agent Yeah. Saying, well, what are you prepared to tell me about what you can do? And, actually, I'd like you to do this instead. Can you do it? Yeah. And that becomes part of the agent to agent communication as a kind of boots session bootstrap.

[00:25:18] **Daniel Smullen**: Yeah. So it seems that we're kind of on parallel paths here, actually. Okay. Interesting. Thank you.

[00:25:29] **Ari Keränen**: Very good. I think we're now actually very well on on time here. Thanks a lot, Adrian. Very relevant. And I really want one of the key points of the session today was to increase this awareness of work happening in different domains, on IoT domain, agent domain. I think this very good for that. As I said, Adrian, like, I'm I'm sure we'll be taking a look at the work having it done, and let's have this conversation going. Like, how are those building blocks coming and what can we use from insights? Well, thank you. So next, we have. Let me

[00:26:02] **Dirk Kutscher**: share some slides.

[00:26:06] **Yari Arkko**: Everybody. So we will be talking about discovery again. And sort of Adrian's piece was obviously a good preface for this. So we're going maybe a little bit both backwards looking at what we already have and also a little bit forward on some concrete things that we are perhaps missing or at least our opinions about this. This was work by a group of people, Jaime, Miria, Jim, Rajat, and myself at Ericsson, looking at the discovery protocols and mechanisms and why do we need it, what's out there and do we have everything that we need. That was basically the question setting. And before we go into the details of the discovery, let's talk about this in this bigger context. So if we have these agents, they typically operate in a loop. They look at the current state or current task that they are on and, you know, how far we progressed. They do some reasoning, try to figure out what to do next. Is there some action to be taken? Then based on that action or the results of that action, loop back and do it again and see what happens. And they, of course, use the LLMs for the reasoning part. They use various kinds of other components or entities rather, sorry, for tools and other agents and resources and so on. They also may have or may not have a user to talk to in real time, but they also can have this discovery piece. And so how does that fit in? So the idea is that agent reasons about the task and then it discovers that, well, I need to do, you know, math or whatever. And it realizes its toolset is insufficient that it currently knows about. So it goes into the discovery source and asks it's about, you know, can I do you have something for this purpose? And it finds some things, adds what it finds to its working set, and then continues the task perhaps by invoking the a tool or other agent that that it was just disco discovered. And then continue from that onwards and do the go back to the loop. So that's the bigger context. And I have a short demo assuming the the thing will actually work, let's say, Am I sharing on the computer rather? So in this example, we have an agent, Alice, that we're talking to. In addition to Alice, we also have another agent, Bob, and a bunch of other tools that we can we can use. And then we have an agent directory that Bob registers to, and Alice can find Bob using the directory by doing a lot lookup. And once Alice has found Bob, then she can call Bob directly without going through any other infrastructure in between. And everything here in this particular example is soft state. So registrations are soft state. If you learn something, that's soft state and then we use it. And if if you fail, then then we can go back to redoing discovery. Yeah. Let me now try and switch to my screen. Few

[00:29:34] **Ari Keränen**: request. Yeah. Just a moment. I'll grant you. Let's change that again.

[00:29:49] **Carsten Bormann**: Yep. You have a screen share there. Yeah.

[00:29:52] **Ari Keränen**: Alright. Let

[00:29:53] **Carsten Bormann**: me go

[00:29:53] **Yari Arkko**: to yeah.

[00:29:54] **Adrian Farrel**: Let's see.

[00:29:55] **Ari Keränen**: Let's see here. Here we go. Mhmm. If I click grant, nothing happens.

[00:30:01] **Lorenzo Cornea**: Can you grant? Sorry.

[00:30:08] **Yari Arkko**: Technical difficulties. Just a sec.

[00:30:14] **Carsten Bormann**: Yeah. I think you need to close on your slides before you can

[00:30:19] **Yari Arkko**: But it's not

[00:30:20] **Carsten Bormann**: on my screen. Yeah. Can can you close on the slides?

[00:30:30] **Lorenzo Cornea**: No. Nope.

[00:30:40] **Christian Amsüss**: Better. Thanks.

[00:30:55] **Yari Arkko**: Yes. Yes.

[00:30:57] **Ari Keränen**: Go ahead.

[00:30:58] **Yari Arkko**: Alright. It works. So here, what you see is basically this at the top, see a part of the screen that shows the agent directory's memory. It knows about couple of tools currently. It doesn't know about Bob. And then we are connected to Alice so we can directly interact with Alice, the the other active agent in this case. So now if we ask something from Alice, for instance, whether in Paris, it will give us an answer. So we got an answer and we got this answer because it went to this directory and asked about stuff and it got back among other things, weather service and it used that. There we go. And let's ask something else from Alice. For instance, this from Helsinki to Tokyo. And now in this case, we don't have any matching capability because Bob hasn't been registered in the directory yet. And we can do the registration. And now you see that the agent directory actually knows about Bob. So if we now ask about the distance to Tokyo, then we should be able to get an answer. So we get an answer and we also see the sequence of events. So we went to the directory, we asked about particular type of things and got an answer. Then then we got a sorry. The screen is too small to show show everything in in one one go, but but we basically got got the knowledge of the things that Bob is able to do, and then we directly contacted Bob. So Ale sends direct messages to Bob. Now if we're to do this again, we would directly again contact Bob and not go through the agent directory because we have cached the the information. So very, very simple thing. Now maybe go back to the slides again. So if I stop sharing here. Alright. I mean, it's a very simple demo. It's nothing fancy, but we're basically trying to show that basic discovery works with existing standards. So we can already do many things. There might be some parts that we'll talk about later that would need potentially more work. So we were using basically API catalogs and something similar to the co co op resource directory patterns and then HTTP caching. It wasn't more difficult than that and few 100 lines of Python code. So really a trivial thing. And you can do discovery at runtime, not just the start up. You can probe for multiple different formats and types of discovery with graceful feedback. And then once you get some information, then you can invoke services on the other entity directly driven by the metadata that you received. So it's pretty neat to be able to do these these things already today. But let's get into, like, more holistic understanding of this space. So we looked at a number of different things. We looked at different kinds of scenarios that you'd use this or use cases. And then we looked at what kinds of protocols or designs exist today, categorise them, show some examples, and then talk about the gaps at the end. So the scenarios first. So we had a couple of different cases. So one is this curated set case, and this is me selling you an agent that comes with the ready made tools and other agents that you can use. And I fixed those, that set, you can change it. There's really no discovery. It's just a static configuration. Then you have a local context case. Maybe it's in your home. Every device within your home can be, you know, a tool for the agent or another agent. Or maybe in an enterprise, the local admin there would would dictate this. There's few different technical mechanics, but it's sort of local con context is one one potential scenario. And then there's this known partner case. I do all my hotel bookings at Hilton. Therefore, I contact always Hilton for for my booking services for hotels. Then you have federated cases where we have mutual agreements among a group of people, And then then we would be able to use each other's systems. And then there's finally free form search. That does scare me a little bit. Like, would you, you know, pick a random agent from the Internet and and run it? Maybe not. But, you know, for some some things, this may be applicable as well. I also should mention that discovery is not just a, you know, go from a name to IP address kind of thing. It's it's it's actually more complicated. So, typically, you have something that you wanna look up. It could be beginning could be like, you know, hilton.com or whatever the the starting things, or or it could be also a search question. But in the end, it produces some set of names or identities or references. Each is kind of associated with the description that this thing here will be able to do this and this and this and this is how you interact with that. So it defines an interaction pattern involving like what protocols to use and what do you expect out of this and what do you need to feed it and so on. Some sort of specification of the trust also needs to be there, like which endpoints do you actually trust to do this or which can actually speak this thing. And then also, maybe you need somebody of authority, maybe your employer, maybe some other entity that you trust that says, we vetted this thing and this is, you know, good for your agent networks. It does what it's, advertising to do. And depending on what solution for discovery you look at, typically, they address different parts of this diagram, not necessarily all everything in this diagram. So we looked at the bunch of different mechanisms. You have all the references in the draft. I'm not going to go into details of that today. But we looked at DNS based ones, we looked at host level ones, We looked at registries and directories and also some other categories mainly for humans perhaps. Anyway, you have references in the draft if you're interested in the details. But let's just briefly go through these different categories. The DNS based resolution, basically, the idea is that you'll talk to DNS in some form. Maybe you start with the main domain name, the hilton.com, and then you figure out what the agent servers actually are in that domain. And maybe you get some extra little bit of information there as well. And then you connect direct to whatever you found. It's pretty simple. Basically, no new protocol elements needed, at least in the very bare bones version. If you wanna declare some additional parameters about the details of of this agent, then maybe you need a little bit of format definitions. Of course, it's per domain scope. You can't really acquire the DNS for, you know, find me a hotel booking thing across the Internet. That's not that's not what it does. And then there's this host level self description. You guys are very familiar with that in the IoT space, obviously. So that's well known, and and then you ask about stuff. API catalogs defined in the ITF. A to a has this. MCP has something similar. A and b has also that well known. You could also I'm not sure exactly what this AI deep does, but but there can be other mechanisms as well. And, these are typically pool based. So you go to the thing and ask, you know, give me the data dump. And now this can be, you know, potentially a lot more data that you can have lots of information about the thing that's that you're asking for. So typically, go to the source, ask about what do you have, what what agents, for instance, you have, and then you get the long list, and then you pick the one that you're interested in, and you acquire more details about that. And once you have those details, then you can, again, invoke the the actual agent or tool directly. Pretty simple again. And then you have registers and directories, a bunch of example solutions here. So here the idea is that in some fashion you register to a directory and this could be with soft state or some other form of registration. And then it's there in the directory and then others can look up stuff either by name or get a full listing. Then again, you pick the one that you're interested in and invoke directly. And once again, it's pretty simple. Nothing super fancy and all doable today with existing technologies. I guess one message that we had looking at all at all of these things that there's probably no single solution that fits everything. I'm not sure there needs to be either. But but definitely, there's more works being more more tools exist for this curated set local context and non partner case and maybe a little bit less, but some also exist for this federated consortium and free form cases. So basically, you need to compose mechanism in order to do something. That's really relevant here. So finally, this last slide, what's missing? And we don't necessarily have all the answers either, but this was our team's idea of what we thought we might be missing. Maybe there's some functionality issues that are missing, but it's also a question of interoperability that we have, you know, 10 different ways of doing x and therefore, you know, we can't really interoperate and therefore the ITFs should do the eleventh version of the thing. And hopefully, you know, that would improve things or not. But that is the state of the world at the moment. So semantic discovery, for instance, there are some of these mechanisms that can do this. So like free text search kind of thing. But they do it slightly differently. Same with interoperable federation. There's different kinds of mechanisms. Some use DHT, some use other mechanisms. We also have tons of things that expose a set of APIs, but are really about APIs, not so much about agents and tools, like 3GPP CAPIF is one example of that. Perhaps this could be upgraded to be agent capable also. Then there's metadata formats. There's plenty of those, but again, fragmented space. And then there's two things that I think actually are a little bit like lacking at the moment. Trust bootstrapping. So it is this issue of, well, we can certainly verify that, you know, foolbar.com is foolbar.com, but we don't really know if they should trust it. So where does that trust come from? Does it come from a registry that I trust that they have vetted stuff? Or how does it come? Or maybe W3C can provide something that there. I'm not personally familiar with that. I don't know. And then there's another thing with pool type of systems. You know, what happens when there's an update? Some of these things could actually be dynamic. So how do we know that there is a change? And we don't we didn't see too many mechanisms for that in our research. Anyway, this is what we did. If there's any discussion or questions or comments, I'm not sure I can answer too many questions, but maybe there's discussion in the group of did we miss something or else there are other categories that are missing from this categorization and so on.

[00:44:02] **Ari Keränen**: K. Thank you, Yari. I think at least one one observation here is interesting. Of course, I'd like that at least the patterns that we have been looking on the IoT space, of course, are very much applicable also the agent space. Typically, Piece of software trying to understand each other, trying to automate how we interact. So I think that's clearly a very, very interesting things to explore further there. K. Go ahead, Drew.

[00:44:26] **Dirk Kutscher**: Thanks. That's very interesting. I just wanna in the use cases, did you assume that Alice and Bob already exist and have been registered? Or could you also have use cases where, you know, I spawn a new agent and I registered it and and maybe that agent spawned sub agents and and so on?

[00:44:48] **Yari Arkko**: We didn't look at that specifically. That's an interesting question. You could also imagine, like, on demand stuff that, well, I I I need a thing and then, therefore, an AI can go and make the thing and then you can actually use it. So, yeah, that that would be super interesting to look at also.

[00:45:12] **Ari Keränen**: Okay. Great. Thank you, Jari. I'm looking forward to hear more. So next, we have Oscar Lopez presenting remotely. So oh, sorry. On-site.

[00:45:32] **Carsten Bormann**: That's a remote. Sorry. So let

[00:45:36] **Ari Keränen**: me just switch to the slides. This always takes a while. Okay. Here we go.

[00:45:58] **Oscar Lopez**: Thank you very much. Thank you for being here, and I'm going to my name is Oscar Lopez, and I am going to present my work, which is my the subject of my PhD research. This is funded by the European Union, and this is program, and is LM assisted translation between YANG and IoT data representations. So I want to give a little bit of of context. We know that they're within the IoT ecosystem. The device need to communicate using data representation for passing the data and a protocol to exchange that data. But they can do that as long as they they share the same protocol in the data representation. So when two different devices has the different protocol, they cannot communicate between each other. So due to the heterogeneous data, we don't we can't have interoperability in this ecosystem. So we thought that by using LLMs, we have a feasible solution to ensure that seamless communication and to reach the full potential of the IoT ecosystem. But that arise the question, how can we ensure that we can maintain the semantic value that is within the data if we have different representations? Where? Well, we thought about two different categories. The first one being the data models. In this case, for this work, I tried to focus on the gen data model. I use it on use it on NetConf, for describing the work configuration. It works perfectly in that scenario, and we also have the semantic definition format, SDF, is that used for represent objects based on based on JSON. And it's lighter but more constrained. So we have two data models that operates in a different context. So how can they relate within each other? So after looking at the RFC and SDF tracks, we saw that the YANG statement and the SDF keywords name can represent the same information because they share similar functions. For example, we know that the leaf is used for represent the property of a property, whereas the SDF property can do exactly the same using a different syntax and the current language construct. So based on that, we can have semantic equivalent between those data representation. And we also have another category of equivalence, which is more oriented towards the the the formatting itself. In this case, I am focusing on JSON and XML representation, which only involves changing the slide, the syntax, but conserving the language construct of each data model. In this case, we're focusing entirely on on Gen. And here, can send a sample of information that can be represented several ways. All of them share the same semantic value. But okay. We know that there are similarities between the data formats data and models, but how can we teach that to the LLM? Well, luckily for us, we have plenty of tools to to do that, but we need to give the information in a specific format so the LLM can understand those relations. One of them is streaming all the necessary information that the LLM doesn't need to fulfill the task. For that, an option that I found was using the placeholders as a tech to replace long stream fields that don't up or anything to the model structure. And also to reduce their context window sorry. To reduce the the input then to don't reach the content window context window of the LLMs. Another important part of this translation task is giving the LLM directly instructions since it's able to own understand not only that the structure about human life test. We thought about the possibility of giving instructions on when it's a data model translation or a data format translation. The way we can separate those tasks. Additionally, we can represent that information in the Alpaca format, which is the way that the LLM can understand that information. We also included their harness, a harness methodology that is a way to guide the reselling process of the LLM to fulfill the task in a specific way. So now we can give the this information to the LLM, but we're not done yet because we can also get give knowledge to the LLM, not only specific concrete examples, but also give it more con more context with the direct information from the SDF and YANG draft. We can do it in a same fashion as we did before using the Alpaca format. And now we have all all the tools. We need to properly process the the information and generate the database to give it to the LLM so it can learn that semantics equivalence, data structure, and therefore, I relied on the r f of the RFC of Jan and ZF to give it knowledge. The difficult part was to generate the the equivalence between Jan, ZF, JSON, and HTML. And for that, I tried to rely on using the schemas to gather information from different databases and try to put them using YANG and SDF schemas. And, also, I tried to use the information available on Internet from different vendors on different companies such as Nokia, Huawei, Cisco, etcetera, and use the same philosophy of the schemas to have the same information, different representation. There was very this was very laborious. Like, it took a lot of time. And even if I okay. And you might be thinking why using the schemas sorry. Why using the LLMs instead of using directly the schemas? Well, this is very limited using this approach, very high labor. It doesn't escalate over time. If there's a, like, modifications on on the RFCs, well, it might require to modify the code, and that requires time and and money. But with the use of LLM, we can retrain the this model and also generalize that knowledge to different unknown use cases. This is the proposed schema for the translation. We cannot rely entirely on the LLM probabilistic nature, but we need to surround it with deterministic methods to boost its performance to have, like, a more reliable way to to to see, okay. This is good. This is wrong. We can avoid this the hallucination

[00:53:29] **Yari Arkko**: of

[00:53:29] **Oscar Lopez**: the LLM, etcetera. So as mentioned before, I'm a preprocessing phase with the place for the replacement and the prone construction according to the desired data translation format. We have defined to net LLM. In this in this case, I am trying to rely in small bottles and rely on parameters. And then we have the validation mechanism to actually ensure that the LLM output is accurate or at least that it conserve the semantic value. In this case, for the especially for the JSON like structures by using different libraries, I am able to verify the the syntax and also to to correct if it's necessary. In the case of the JSON format, can use directly the pyang library to ensure that is properly parsed. And and, additionally, we use an external agent to to focus on the difficult task of ensuring that the semantic value is maintained. The agent is also fine tuned it with more knowledge of the YANG and the SDF RFC. As mentioned in the previous presentation, this all the structure relies on a on a loop. So in this case in this in the case of having, like, not proper translation, we can give the feedback to the LLM, and the LLM, we try to do the that requires correction to have a proper translation. In this case, we try to use Yank as a preferred data representation for for the translation. And after having architecture, I'm trying to to check to see how it performs, we're trying to focus on two different measures, like the execution time and accuracy depending on the problem. In the experiments, we found that there is a linear relationship between the problem length and execution time, which is already aligned with what has been saying in the state of the art about the LLM's behavior. In this case, the LLN have to process the also the tokens from the instructions and the data model link. And the larger the problem, well, the larger the the execution time, but it doesn't entire entirely rely on the problem, but also on the on the data representation. For example, as mentioned before, because YANG is the desired is the preferred data model for this translation task. Then majority of the database are reliant on gen data models, then with the JSON like representation and after with the HTML representations, we can see that the translation to whatever that the representation to Jan has a better performance compared to the Jan to other representations. So that means that the LLM was able to have a better understanding of this data model, and we maintain the linear relationship from the previous case. And we're trying to focus all in another aspect, also their accuracy. We can see that, again, aligned with the state of the art. The smaller the prompt, the better the the accuracy since the the closer that the problem gets to the contest window, the inference of the LLM decrease. So some of these behaviors, at least in the first and third case, were kinda expected after conducting the state of the art review. But then we we we try to compare if this fine tuning methodology actually works, like, if base model is able to execute this translation task well. It it was a very it required a lot of setup to actually be able to have the base LLM to generate the ASR output since the small models have some of them by default. They they sterilize their chain and thought process, and they can give you the the translation. But even the whole process that they went through to do that, so even it required, like, a lot of output constraining to have the desired output for the base model. And in the best case, with JSON like translations, we got 40% of accuracy, whereas in the YANG and SDF, we have almost 10% of of accuracy. But after fine tuning the model, given the concrete examples and knowledge, the performance improved all around 90. So here we can see we had two different kind of errors, the semantic error and the syntax errors. In some cases, the LLM is able to properly translate the the data representation, but it lacks in the element of parsing properly the the data. Maybe some problem of missing curly brackets, also missing elements in the XML format. But here we can see, like, the fine tuning process makes the different for achieving the translation task.

[00:59:00] **Yari Arkko**: Also,

[00:59:02] **Oscar Lopez**: we can see that the LLM maintain the behavior of forwarding the JSON like formats. And we have also the percentage of error of having semantic and syntax issues I already said a lot, but we wanted to to see if we maintain the integrity of the semantic value so we can do that round trip translation trying to retranslate the output to the original data representation. And we have a similar similar results. But when you are trying to look into detail of if it's actually accurate, we saw that the LLM, despite of being fine-tuned at all, has some hallucination problems. We can verify this with the the representation run through translation table. Whereas for success, we have the a set translation. Literally, the run through translation was the same as the original representation, whereas the just semantic, we maintain the same structures, but slightly modify in order, but it still counts as accurate translation. And then no semantic, in this case, we can see that, for example, from the preview from the first table that I show about the semantic equivalence, there were, like, no injective relationships. Sometimes the so in January, the statements can lead to several SDF statements, and the other case also happens. So we can see that this this validation layers are no no, and we need to rely entirely in another kind of metrics to ensure that we have the we maintain it during translation. And in the most common cases, we got uncomplete uncompletely translated models, names that were replaced, some replacement on the different numeric or integer values, etcetera. But as a whole, we can see that compared to the base models, we have a huge improvement on on this translation task. Yeah. For sure. There is work to do, and there are some limitation as mentioned before. I still have the we has we still have the problem of the LM hallucinations despite of being fine-tuned. Where and there are also more work to do concerning the evaluation of the LLM translation, one of them. Being ensured the integrity of the structure of the original data model. And this is the plan that I have that I have to improve this translation framework, work more in the harness to have a better guidance over the LLM on how to achieve the the translation task in trying to constrain the o the LLM output even more with the use of grammar rules. For example, BNF grammar rules and also trying to integrate retrieval augmented generation to have update knowledge as where the LM can fetch that information and not rely entirely on its knowledge. Try to evaluate the performance with different LLMs. In the future, try to implement this in a real life scenario in a with different IoT networks and expand that into not only semantic, but also intent context instructions. So thank you very much for your time, and open to questions.

[01:03:05] **Ari Keränen**: Thank you, Oscar.

[01:03:06] **Niklas Widell**: Go ahead, Nicolas. Nicolas, well, Ericsson. You for your presentation. An interesting question here. I mean, I never thought of my my direct use in thinking about NLMs and SDF and so on was not about using it for translating the models, which actually would be the problem we had when designing SDF a few years back of mapping was how you represent temperature in one ecosystem and comparing that to another ecosystem, like translation from an integral in IPSO to, like, a temperature tag and something else, right? So have you thought about that as well? Because much of the other sort of model mapping is reasonably, you know, yes, you can use an LLM, but it's reasonably straightforward if you make some fundamental decisions. But the kind of the mapping of what is temperature in ecosystem a, how does it map to the equivalency in ecosystem e, and is that mapping kind of good or not? How do you think about that?

[01:04:02] **Oscar Lopez**: We thought about that. It's still a a question that I haven't been able to answer. Like, for example, the l n can do a translation from, let's say, to environment e to environment b and to environment e, to environment b, but environment b might might use Celsius instead of Kelvin or etcetera. So in in this case, for the agent, it might be a good translation even if, like because of the hallucination, it skip the change of the sentence value. So in in in that case, we don't I don't have an answer on how to verify that extra layer of intention in in translation. It's just something that we got to work on.

[01:04:46] **Dirk Kutscher**: Thank you.

[01:04:51] **Esko Dijk**: Esko Dijk. Yeah. Question here. Maybe I missed that part in the pre presentation, but I was thinking, like, you have several of these, frameworks for representing, like, Yang, SDF, XML. So that's only only a few. So you could say maybe if we just do some effort and translate all of the existing models into all of the other ones and then spend some bit bit more CPU cycles on that, including an LLM so you don't have to do it with within a few seconds, and you don't have to do it on an embedded device, for example. Would that be something to consider, or is there a good, yeah, reason to to want to do these translations on the fly, like, in a in a device itself?

[01:05:35] **Lorenzo Cornea**: Yeah. For for for the moment, this sort

[01:05:37] **Oscar Lopez**: of translation on on on the fly. This at at the beginning was just a semantic translation. We want to see how we like, which was the performance of the LLM to translate over different data models, and then it's escalated to data formats. Like, this is a way to this this are experimentation to see how capable are the LLMs to handle different translation task. I I think in the future, we might want to implement different representations, different protocols. But, again, it's something that that has been done on on the fly. We don't have, a it's a a robust mechanism to actually adopt new new representations, new format out of the fine tuning methodology. We're still working on, like, that kind of escalate scalability element.

[01:06:31] **Carsten Bormann**: K. Thank you.

[01:06:44] **Ari Keränen**: Good. Thanks. I could also ask one question. Like, what's your intuition? Like, how much will the improvements come from, you know, new models and new harnesses, or is there something that should be in the models themselves? I don't know. New extensions towards this kind of automated translation. Where are the biggest gains in the future?

[01:07:04] **Oscar Lopez**: I see in the future more towards a little bit of both. One thing is using, for example, NCP, like, rather than relying thoroughly on the LLM inference, trying to use another tool invoking other tools to achieve the translation task, like adding different valid validate validation mechanism within the LLM architecture. And also, over time, we have seen improvement of the reasoning of the LLMs not only to to handle a human like test, but also code verification, test generation. It's like trying to use the advantage of the improvement of the LLMs that been quite kinda huge in the in the previous years. But I think that the the the aim is looking forward, develop a a structure around the LLM. Again, they're trying to rely on on on SAP probably to make the framework even more robust.

[01:08:08] **Ari Keränen**: Great. Thanks. Okay. No more questions. Then next, we have Lorenzo. Thank you. K. Go ahead.

[01:08:43] **Lorenzo Cornea**: Yep. Okay. Hi, everyone. Here is Lorenzo from Ericsson, and this is a joint work together with my colleagues Jaime Jiménez and Ari Karenen. And, yeah, in in this talk, I'm gonna show a few ways that we could use to extend the SDF and co op to improve the interaction between IoT devices and AI agents. And we also have a draft newly submitted just before the cutoff date. So if you want more details, please go there and go there and and read that. Okay. So we are trying to build, on top of what Jaime has been presenting the last year at IETF 113 in Madrid. And there, he basically showed how we could use agents to interact with IoT system by simply delivering user intents. Like, it is too hot in this in this room, and then the agent would figure out all the machinery for fixing the issues reported by the users. And yeah. And then in in this draft, we are aiming at building on top of that, and we will propose a few way to improve the interaction between agents and IoT systems. Yeah. As mentioned, we are going to address specifically co op and and SDF because we have quite some experience with those. And so in the last couple of years, we have been conducting several experiments running co ops and SDF in conjunctions with AI agents. And we identified several gaps. And in this presentation and draft, we decided to report two of them that we find quite interesting. The first one is that we noticed that co co op lacks a way to distinguish between a request made by an agent or a human or a machine because we are into T2TRG. Right? And also, SDF models are prone to cause hallucinations in AI agents when certain elective fields or descriptions are either missing or they're poorly written. So when it comes to implement the AI agent identification in co op, we proposed a procedure in three steps. Namely, we could use an elective co op option for signaling to a server that an agent is making a request to the system. Then we thought to enhance the resource directory to host part of the machinery that is required for performing and validating the keys or whatever material the agent is delivering through the co op option. And finally, once those two steps are checked and validated, we can use that information for delivering tailored responses via the server to the agent. And here, in in the draft, we decided to call the selective option agent ID. And it is elective because in in the lack of that, we could assume that, well, this is not done by an an agent. Of course, this might be wrong. And so far, don't have an a a way to detect that. And, otherwise, when it is there, the agent ID carries a cryptographic signature that allows the server to verify the effective identity of the of the agent. Otherwise, there might also be references to where the server can get the public key for performing the validation. And and here on on on the example, there is a quote request and you can see in bold, the agent ID is carrying some string. And yeah. And and at this point, when the server retrieves this type of request from an agent, then resource directory could be leveraged to to provide tools for for the server to validate the key. So, for example, we can extend the resource directory to host key material with another item that is credible, discoverable. And once on that, when a server receives this request with the agent ID, then either the key is already in its position or otherwise, you can just query the source directory or eventually, you can also refer to the external link that can be provided anyway by the source directory. Yes. Once we have done this validation, the server can perform many different things. And here, we're just reporting a few instances of that. So for example, once we discover that the agent is sorry. The the request is coming from an agent, we can return a picture description together with the sensor data that was requested that can be consumed by the agent. I'm gonna show an example of that in the SDF part later on. And also, we we can indicate to the agent in the response back that there are restrictions to the usage of this data. And, for example, that could be that, yes, this is your sensor value, but I don't want you to use it to train a model, for example. Of course, there is no way to enforce that, and this probably something that we could discuss later on. Otherwise, we can also do things like applying rate limiting in case there is a crawler that is making use of our system and the system owner doesn't want to wants to privilege things interacting with each other rather than scraping the system. And also, we can potentially withhold information from from the agent. Like, maybe we don't want the agents to know how many people are in this room at this moment. Yeah. And when it comes to to to SDF, we identified two promising, directions here. The first one is about, providing machinery for content negotiation for, SDF when it comes, to interaction with AI agents. And, also, we we we thought to embed into SDF, mechanisms for, adding developer defined templates and structured examples to guide the the agent towards better achieving the user intent and and reduce the the hallucination. So we we could, for example, signal that we are interacting with an agent by defining a new content type. Here for the sake of of an example, we called it text/sdf. And and basically, you you can the agent can signal in in the request this this in a in a header field like the accept. And here, there is an example on a co op request. We we we ask for text/sdf in the content negotiation part. And and we see that instead of getting the usual JSON SDF document, we are getting some textual description. And and and and this is all because we ask this text/sdf. And now, how how can we deliver this textual description? Of course, we could have a bunch of TXT files or a database and trigger that prefetch them and and store them there. But perhaps we can do something a bit nicer, like, for example, defining a new SDF quality, like SDF bot in this case, in where we can add textual, elements or instruction directives for agents, directly in SDF documents. And then also, we think that we could have, some simple referencing mechanism so that we can that the external tooling that can traverse the old SDF documents and and recompose the the textual description that we we saw earlier. We we see also here in the in the red in the red text at the bottom of the slide. And and, yeah, once then the server gets request for the text/sdf, then it can triggers the reconstruction of of this string at runtime. And here, just looking at the example, we have at the root, our new quality SDF bot. And and and that tells us that, okay. This is a temperature sensor, and then there is this at t. At t is what we have been using for making a reference to the property t, which is actually defined within the STF property temperature in a sdfRef. Right? And then in the sdfText within that affordance, there is the the text that is going to be appended to the root description. Right. And also something that we noticed running some experiments with Jaime and and Ari is that many times we were given instructions to the LLM. Hey. Hey. This is the SDF model of of our device. Please do some operation like low lower the temperature. And often

[01:18:25] **Yari Arkko**: with a with

[01:18:26] **Lorenzo Cornea**: a good probability, there were hallucinations. And therefore, we thought, okay. Can we actually steer the the LLM to, let's say, reduce the the the amount of hallucination and make it more accurate. So we thought to add a new SDF quality. Here, we called it SDF structured examples where we can, you know, step by step instruct the agents on what to do. A structured example is made of a task, which is the the user intent, the goal that we want to achieve with this example. And then there is a list of steps and each steps is composed by an action that tells the agents what to do and there might be optional parameters. If we see the example on the right side of the slide, we we want to perform some update firmware on on our device, and we want to update to the version number two. And the steps for doing this in the example are three. And so the first action is about set this dev property firmware to version two image, and then in the parameters, we can point it to the the binary that that should be uploaded on on on the chip, on the device. And then as a second step, we can execute the x SDF action update firmware. And and then we can conclude by observing when the SDF property firmware version is updated to the value b two. And the ready when clause offers us also a termination point for for the agents to to perform it its its task. And then the idea is that when the agent or the user is going to ask the agent to perform firmware update, the the agent can fetch this example and copy that and make sure that the intent of the user is fulfilled. So this was my last slide. And, yeah, happy to take questions and and discuss with you.

[01:20:33] **Ari Keränen**: Thank you, Lorenzo. See we have Chris on the line.

[01:20:36] **Christian Amsüss**: Thanks for the presentation. I can't talk much about the AI applications, but what surprised me was the question about not being able to distinguish them from the requests because while we don't have the options in the coop message, we do usually have some extension points in the credentials that are presented to the coop server. So maybe the subject of a CWT is a bit not structured enough, but that information could quite well be conveyed there. And usually with co op authentication, we try to have the information about who is talking to the server in there and do that once at setup time and not for every single request. So I think for that point, for that single point, there are good options already.

[01:21:17] **Lorenzo Cornea**: Okay. So you think option is not the way to go there? Okay. Yeah. Thanks for the feedback.

[01:21:30] **Ari Keränen**: Thank you. Any more questions, comments here? Yeah. Thanks, Lorenzo. I think this was a kinda good example of what kind of things we could be looking into for for filling these gaps and making these protocols and data models and other technologies more better fit for for AI agents and in general. Very good. Then we have our our our final talk for the day. Tobias? Yes.

[01:22:06] **Carsten Bormann**: So we'll bring up this live and.

[01:22:09] **Adrian Farrel**: Amazing.

[01:22:19] **Lorenzo Cornea**: Okay.

[01:22:22] **Ari Keränen**: Oh, yeah. So we might need to do a quick

[01:22:29] **Oscar Lopez**: Yes.

[01:22:40] **Ari Keränen**: There.

[01:22:43] **Tobias Fiebig**: So good morning, everyone. Well, not morning anymore. I'm Tobias. I'm from TU Wien, and I, head the network infrastructures, Internet infrastructures research unit there. And I was asked to give a short impulse talk about the role of AI and machine to machine communication. And most people who know me know that I am, not not not the most enthusiastic when it comes to the use of AI. And I thought that for this working or research group, it might actually be interesting to get a little perspective on why I am so skeptical. So let's see when the towers crumble. Who here knows the Towers of Hanoi? Okay. Good. Good. Good. All sorted out. Anyway, complexity. Complexity is a very beautiful thing and usually engineers have this habit of building more complexity. We really like to do that because we like complex things because they keep us busy and we need to understand something. And we we want to solve a problem and then we have all these things that solve the problem, but we do not solve it like we want to solve it. Not invented here syndrome. That's also very prominent also in these rooms among all the engineers in the IDF. And then then then we have ideas how we can make that even better so we get something more complex. Quite some time ago, together with a colleague, I made certain propositions on the Internet for a Burning World and one of them was systems that are too complex to be understood by a single person cannot be sustainable. And in a sense, that is kind of what we are going for. I mean, we are talking about bringing agents into machine to machine communication to have more dynamic things, to have things, well, evolve, build, and to make it easier to interact with those things, to make it easier to integrate different things from different vendors that might have no similar specifications. So the question is, why not AI to solve a complexity problem of interconnecting devices, interconnecting machines, and making things work in this complex little world which we have built? Well, what that basically does is abstraction, and that is something that we have seen in other parts of computing already. So in the beginning, we did the three sentence solution, configure, make, make, install, Then we got packaging, then we got docker containers, and we got Kubernetes, and now we have a lot of problems. So using AI to solve or interconnection issues to outsource some of that figuring out what the specifications are, figuring out how different components can interact might make things work, but it also makes it abstract to us as the engineers who have to deal with that. And that kind of brings us to the issue of staying fluent. So if we outsource all that work, we might actually lose that language. I mean, who here can cook? I'm I'm I'm a very, very avid fan of cooking my own food. If you turn up to eat at McDonald's every single day, at some point, you might actually have forgotten how to cook and that would happen to me as well. It is the same thing with doing anything that is about computers. If we do not do those things anymore, we might be losing that end to end understanding, that language we need to speak with these computers. And if we then find ourselves without our, well, translators, without our tower, we might actually find ourselves in a situation where that tower has actually collapsed. So Christian methodology, Tower of Babel, the humans tried to build a tower to reach the sky and God and God made the tower collapse and gave us different languages so we could no longer understand each other. Well, we might find ourselves in a situation where we no longer understand that really nice complex obstruction which we have built or at least not the parts we would have to interact to fix it. And I think that is the big challenge we have to deal with if we're trying to make machine to machine communication using AI actually work. So this was supposed to be a thought provoking piece. Usually, I have the tendency of it being more like a depression invoking piece. But, well, I think that's the point where we start discussing.

[01:27:09] **Ari Keränen**: Very good. Thank you, Tobias. Any immediate reactions on cautionary tale here?

[01:27:17] **Niklas Widell**: Sorry, in the queue, but

[01:27:19] **Dirk Kutscher**: computer science is often all about abstractions. So how do you deal with that?

[01:27:25] **Tobias Fiebig**: Yeah. So so I fully agree computer science, but but the problem about computer engineering is that it's usually not about technology but about people, which most engineers, because they are computer scientists, at least the system network engineers, do not understand because they learn computer science and that's about being with computers. And they try to solve problems with technology which are not technology problems, and they come up with technological solutions for things that are not technology problems because they don't understand that it's not about technology but about humans. And I think that is putting the divide we have to deal with and also our education and how we teach these engineers. Like like, it brings it to the point.

[01:28:05] **Christian Amsüss**: Picking up on the abstractions, I think it's like, yes, it's about abstractions, but it's also about finding the right abstractions that make things easier, not just putting abstractions on top of it for the sake of or just to solve the problem, but finding the few abstractions that really make sense and that that cover the domain well.

[01:28:27] **Participant**: So this idea reminded me of the simplicity cycle that says that you add more complexity and the system becomes more complicated and more fragile. And then you have to add more complexity to deal with the fragility. And so the system gets more complicated, and so the cycle go cycle goes. And so also, it reminded me of the end to end argument that says that you shouldn't put, like, complexity or functions in the basic level. It should to the to the point. So maybe we are talking about, like, constrained devices. And if we put too much, like, complexity and agents, like, close to the agents, maybe this might not really be a good decision. So I kind of agree.

[01:29:24] **Tobias Fiebig**: Thank you.

[01:29:27] **Esko Dijk**: Okay. Hey. That's good. Was just thinking about complexity, as you mentioned, and, there is kind of inevitability to it. So since life emerged from molecules, it got more complex, and it keeps getting more complex. So I don't see, like, it would go back or so. Not okay. That's just to keep in mind. But the way in which it develops and evolves, that's something that, I guess, even engineers can influence a little bit by working on the right things or coming up with the right abstractions or solutions. Yeah.

[01:30:02] **Tobias Fiebig**: Yep. So I personally do not really mind the IoT getting more and more complex because my personal retirement plan is traveling around the wasteland probably by then and being paid probably in accommodation and food to rip out IoT devices out of life critical systems like water pumps and solar panels for a living. So we all gotta retire someone.

[01:30:27] **Michael Richardson**: Maria from Bert. I am, myself, not concerned so much about the complexity because things are complex already. Like, Linux kernel cannot be completely completely understood by one person even even if Linus Torval said anything. But at least it's it's split able to to smaller pieces, which what's maybe the more the more major fear that the splitting into pieces is done whether it's done correctly or not. The other the other thing with the with the analogy to cooking is that I spent just a week last last month or so white coding. And then I had a quite hard time getting back to manual coding. And with the same thing, it's like, I am feeling that I should create the agent things to do things for myself instead of doing real productive work because it's the future. But in the end, I don't know how long it will take to get the agentic thing to do the things.

[01:31:39] **Tobias Fiebig**: And whether you will be able to check still check whether it does the thing it promised to do.

[01:31:44] **Michael Richardson**: I am not even beginning with that.

[01:31:58] **Rahul Jadhav**: Shall I go or Carson?

[01:32:04] **Carsten Bormann**: What's the queue? The queue says, Escrow, Maria, Rahul. So you are next.

[01:32:09] **Ari Keränen**: Yes.

[01:32:09] **Rahul Jadhav**: Okay. So I guess the only kind of see, grades for AI, which maybe Tobias will disagree with me here, AI help us understand complex systems better, or is it a way of adding more complexity? Because if it's an entropy creating thing, then I think we are in trouble. But if it can help us tame some of that complexity by improving our understanding, then maybe it can help us add value. And in the networks thing, what is the complexity of, agents interacting or things interacting? Do we end up with a situation where with AI, we can help under the single person or a team of people can understand the thing, or can they are they going to get overwhelmed?

[01:33:11] **Tobias Fiebig**: So one point about that. So as an academic, I also have to teach and then you have to do these teaching educations and there you learn a very, very bad word to use when you define learning objectives, which is understand Because you cannot measure understand. So we are asked to put our course descriptions into terms that are measurable. Like the student is able to perform ex epsilon tasks. The student is able to analyze given parameters and not understand. And I think that that is the very crucial thing about your statement. Like, do we really understand if we get it summarized by an AI? Can we express whether we understand? And is it still understanding if, given that the tool is no longer present, we are unable to perform the task?

[01:34:05] **Carsten Bormann**: Yeah. Karsten Berman. Losing languages. I think that that's actually an an interesting trigger thought. I used to be a pretty good semi language programmer, and I don't think I could do it anymore after forty years programming in c and c plus plus and and Rust and and so on. And so an older professor told me he still had to do the the spring force equations that was underlying relay mechanisms. And so he could do this by by heart at some point. But for some reason, we don't do Springforce calculations that much anymore. So we we are losing some languages that we simply do no longer lead need. We are using losing some languages that we now have tools for that work with those. So that hasn't changed. The the the last fifty, seventy years, computer scientists have worked on on creating tools that that support our work. And I'm extremely grateful to the people who write the compilers that I use every day. But I think that that's also an interesting point because I I'm able to rely on those compilers because there there's a lot of technology out there that that really checks these compilers. And there there are test sets and so on. So we we have made a science out of getting some assurance about about the capability of those tools to solve our problems. While we are using many of of the AI tools right now in in an exploratory way, and sometimes they work, sometimes they don't. But we haven't really found good ways to test them to to make sure that that they always do what what we actually want. And so that's probably an interesting point in the IoT space because testing something becomes difficult when when there's hardware in the loop. So you you cannot test an engine controller for for a plane while the plane is flying. That that's a difficult situation. And we we may need some ways of describing what effects we actually want to see. I mean, SDF is already pretty good to telling you what you can do, but it doesn't describe the the effects because it doesn't have the interface to the real world. So you might enter a room and tell the AI, oh, it's too warm in here. Excuse me. It's too cold in here. Make it a little warmer. And the AI comes in and says, oh, yeah. I I have a a temperature sensor here, and that says it's too cold and have an actuator that is coupled with that. Let's turn this a little bit warmer. But, unfortunately, I I just screwed up my my fridge. So understanding the the relationship between the the technical world, the IoT world, and the world that that I'm perceiving and that that I'm having to endure the consequences of actions is probably something we need to support better to be able to have these these more reliable systems where where we can throw test vectors in it and and make sure that when I I'm personally feeling too too cold, somebody doesn't screw up my my fridge.

[01:38:01] **Tobias Fiebig**: I I personally think that that has a lot of interesting points, especially when we think back of the issue. I think it was some IBM implementation that had an issue with X-ray machine back in the day. It it kind of feels similar and then the cat was a bit too warm for a bit too long Mhmm. Which is really hard to explain to the owners of said cat. So I I I think there there are a lot of boundaries where we're also going outside of computers because to us, it looks like computers, but what we're actually dealing with are questions like comprehension, epistemology, semantics, subjective perception. Like, what does it mean for me when it's too warm? That usually means that it's above 18 degrees. I perceive everything as summer which is more than 20. I know people that have a very different opinion there.

[01:38:50] **Carsten Bormann**: Yeah. So maybe one more anecdote. I recently interacted with an intelligence about fixing some some lights in my kitchen. And I wouldn't say that that intelligence has hallucinated, but the guy had some some pretty weird ideas of how to fix that light. And I had to actually update my instruction instructions for him several times before he finally had fixed them in a way that I could use them. And that, of course, was a human intelligence and not an artificial intelligence. So I think that's not a surprise, Setting up things, finding the right way to do things, that's probably something where we have we'll have these these interaction loops even with with humans. But then when when I'm done with it, I really like my kitchen lights to always switch on when I press the button for that.

[01:39:54] **Niklas Widell**: Hello. Nicholas Eyal, Ericsson. So one observation here. I'm also kind of skeptical about AI. I think you rise a lot of good points. But there are certain things that humans probably are not able to do because they are boring and they consume a lot of work, like IoT systems, for instance. And I'm thinking here, not that the people in this room are unable to do these things, but because my mother-in-law will never be able to install or run or update any IoT system. Right? And if they have something, it's like a proprietary system that's totally welded in, you cannot change anything. And you're totally at kind of at the the under control of some, you know, big cloud player somewhere elsewhere. So one thing, because we've been thinking about this billing IoT system, that's where I think this I o so AI could really do a help, is be able to do this thing. And what I'm talking about here is not the kind of initial configuration. It's when you buy another lamp, and that needs to be integrated in your system. Needs to understand, as the customer is hinting at, where is that lamp situated. So how does it work, so to speak. And that's maybe one thing where it actually could be useful. But, of course, there are other all the other points of kind of making engineering less, you know, whatever. That's a different thing. Right? But this is probably something where I think it's really, really useful.

[01:41:09] **Tobias Fiebig**: So I think we all have that experience of visiting parents in law roundabout Christmas having to fix the printer. Probably triggering one or another form of really bad memories. I think the biggest problem there though is that the decision that those systems, especially from different vendors, not playing well with each other is not really a technical decision. You also don't want that. You want people to use your product and to expand on your product. And getting that idea that maybe you're a bit incompatible or you make it a bit harder for the Pluck Together AI to plug things together if it's like not Huawei, not Ericsson, that that's really easy to get into the brain of a product manager. Like like, they love that idea. They they see that and they see revenue and they are happy.

[01:42:04] **Matthias Kovatsch**: This is Matthias. As an individual, just some thoughts on this. So you mentioned this is single person understanding the complete system. I think we left that space even before AI became so popular. So we heard like the Linux kernel, but there are so many other things where you only find very few people on this whole world who actually are capable of still understanding a huge chunk of it. But then even if you are in an industrial company, you have these development teams and so on. It's really hard to make them understand this. You have this in academia where you have students. So this is not grandmothers not understanding it. This is people who are actually really interested in technology and things are so complex they don't understand it. So in the job of a system architect, for instance, it's about then finding the language, how to break it down, how to document it well. And this is also something that I now find, if I do it in a way that AI can work with this and that produces intermediate results that then help again the human to understand it, that this gives a benefit. AI can do something that could be tedious or whatsoever or explore some things, But you also get something that we, as a human, without AI, anyway would need. So there is something of this end to end, I think, that you mentioned in there. And yeah, we have to find a way with or without AI that we can keep track.

[01:43:28] **Tobias Fiebig**: So one thing to keep in mind is that that argument also is from like these certain propositions on Internet for a burning world. So imagine a world where global supply chains collapse because somebody starts a war in The Middle East and, the Ever Given is deciding to do another holiday blocking, the Suez Canal, and, all the other cascading failures. May maybe we humans decide that it's too cold on this planet and we would like to have it a little bit warmer and like, you know, France is on fire and not enough water and then, like, cutting failures and global crisis. And, of course, collecting supply chains and no more data centers. Somebody able to buy RAM recently? Because I I do have to set up a research group and I need new service. Anyway, point being, if, like, these constraints are there and we have access to those people which are everywhere on the planet because there's a handful of them but whereas there's one per continent, then, of course, this continues to work. But as the more of the global supply chains would collapse and the more big players, like, what do we do if OpenAI disappears because they misspeculated and Deutsche Bank is like, you know, we borrowed your money and we don't really see an see any ROE, like bankrupt, then all of a sudden that AI interface is gone. Well, they they then probably is still Grok, but Grok would have the same fate, etcetera. But yeah. Anyway, I think I can

[01:44:56] **Dirk Kutscher**: again. So this is actually, I think, quite interesting discussion. So I I guess many people would agree that, you know, AI AI maxing is not always useful, especially not in the IoT. On the other hand, people are also happy to use many abstractions. For example, taking a flight using a clearly very complex system that not many people understand. So from your work on your propositions and so on, so I'm wondering whether you'd be interested to maybe deduct some principles. So I mean, what could be useful guidelines for making sound architecture decisions? I mean, because I also it's useful, right? So I mean, we cannot really say never use it.

[01:45:41] **Tobias Fiebig**: So so so useful is always a good argument. I mean, Linus Torvalds just made the argument. When I hear arguments that are justifying a technology with a devastating global economic and ecological impact, I always am remembered of Nestle because Nestle went in, like their press department I think, went in front of like the European people being like, you know what? If you want us to produce chocolate without child labor, none of you will be able to afford it. So child labor is useful. And that is kind of what the useful argument about AI often feels like. We need to accept all those negative consequences, all the water being lost, all the shifts we are seeing in our economic system because of speculation in a hope, in a bet, on that this will, at some point, have outcome because we are seeing our personal use while the actual true costs are hidden from us. I feel that that is a dangerous argument.

[01:46:40] **Dirk Kutscher**: Right. I mean, this is probably a question of also, you know, stakeholder interest or, you know, and so useful for whom. And but, I mean, so if here in this group, we're like, if we are thinking about currently, apparently, I mean, what's yeah. Not as useful, quote, unquote, way to to work with AI in in a constrained environment. So and what should be driving this discussion? That's why I'm I'm curious. Have to get it.

[01:47:11] **Tobias Fiebig**: So so to maybe answer the question of what should be driving this discussion because I very much see the problem of, like, making things interact. I think the problem which we have to solve is not making those things interact. The problem we have to solve is if we build a simple protocol that makes that work, how do we make the vendors actually use it? Because that that is where it fails. Right? We we had XMPP that that let us, like, chat across Facebook and Gmail and whatever you self hosted back in the day. Like, you you may have encryption for that, but then it changed and now we have all these instances of messages. We have the same thing when it comes to light bulbs. So that that is a problem we have to solve. And we don't need AI for that. If we use AI for that, we solve a different problem, which we could also solve with a protocol.

[01:48:01] **Carsten Bormann**: Yeah. So, Kirsten Bowman, about twenty years ago, fifteen years ago, we were meeting in these rooms and discussing how we were going to to have all these smart things when each of these smart things consumes five watts and you have 200 of them, so you add a kilowatt to to the the energy use footprint of of every household. Yeah. So somehow we have managed to avoid that happening. I mean, it it may not be as rosy as I think about that, but it it's much better. We now have much better devices with respect to their energy usage. Took quite some time to to get there. Right now, of course, we are using many systems that are not yet adapted to to actually an IoT use. Like most of the early IoT work was done with Raspberry Pis and and other world class devices, which, of course, you cannot have in every light switch and and in every light. So, of course, when we say AI, then we probably have to qualify that this will need to develop in a way that is is actually useful.

[01:49:25] **Tobias Fiebig**: And I think that is a good closing word for the discussion. I'll just see myself out before torches and pitchfork.

[01:49:34] **Dirk Kutscher**: Quickly on the cooking question. Are you using a Thermomix?

[01:49:44] **Tobias Fiebig**: I'm not sure whether the question is a code of conduct violation,

[01:49:49] **Niklas Widell**: but I do know do use knives.

[01:49:56] **Ari Keränen**: Okay. Very good. Thank you, Tobias, for this very good, presentation and and good discussions. I'll follow following on that. So we're now, ending towards the end of the session, wrapping wrapping up here and and thinking about where where to go next. So first of all, thanks a lot for all the presenters and and all the discussions that we had. Very good and lively. We will have, going forward, interim meetings. We had at least one presentation that we couldn't fit in this interim meeting on the same topic. So perhaps one around this one will be had, and then we had a bunch of other topics that were proposed that we couldn't fit here today. So we envision some interims meeting happening after the summer vacations. And then on the work presented today, you know, there are already things with T2TRG drafts on bunch of the topics, and also some of the drafts are outside of the T2TRG. You know, go check them out. Send your comments. Send your reviews. And then, of course, also, all the existing works that we presented still at the beginning, please do check them out too. We need your reviews to move move them forward. But with that, any final questions, comments, thoughts?

[01:51:12] **Dirk Kutscher**: Alrighty.

[01:51:16] **Ari Keränen**: Then I think we're we're done, and looking forward to calling to discuss them in the future meetings and, of course, here at the IETF. So see you around. Thank you.