Monday, 2026-07-20, 12:00 UTC
Recording: https://youtu.be/vsyUFIwZ7p4?t=47
AK did the introductions and went through the document status. The scope
for the meeting today was the role of the IETF IoT technologies in
enabling AI agent interaction with IoT environments, following up from
IETF 123 in Madrid.
Video: https://youtu.be/vsyUFIwZ7p4?t=418
AF presenting. There is a WG forming BoF on Tuesday 14:00-16:00.
AF: Why is this just about agents? We are looking more broadly at
entities, and also address finding compute. ("When is a thing a thing?";
focused on AI agents but not ruling out other entities.)
AF: In parallel, and later than discovery, there is capability exchange
(beyond discovery: how loaded something is, how trustworthy it is,
etc.).
AF: We try DNS first, and only do not use it if we know specifically
that it doesn't work.
DK: About the DNS idea: it gives us a namespace and a solution at scale,
but it is not great for creating new names on the fly, which can be
important especially in agentic and in IoT.
AF: DNS is not good at some things, e.g., bulk data. Names on the fly is
an interesting idea. The assumption is that the registry needs to be
tightly screwed down. Going to an AI agent that isn't what you think it
is would be a disaster. Possibly there is a domain hierarchy (home,
office, factory) where you discover more dynamically because it is not
open to the world. Then you do not populate through DNS, but discover.
DK: After having the name, you also need to know if you can trust it.
AF: There are multiple levels: first the search, then you have a pointer
that needs to resolve to an IP address, and then you set up
communication that will have lots of authentication in it.
DK: Compare this to the web. There, other mechanisms establish trust in
the server. The IoT requirements may differ.
AK: DAWN is looking at the larger picture, and T2TRG is a good venue for
the IoT specifics, especially when research is needed.
AF: If you note that DAWN is doing 95% of what you need but would need
some tweaks, that is very interesting for DAWN to hear.
DS: This is interesting, because we encountered those functional blocks
in IoTOps around privacy preferences. The nasty problem is that
capabilities are related to data types, purposes for processing, and
things you might want to limit. Have you thought about that part of the
problem?
AF: I have a slide with the architecture and functional blocks, but
every time someone says "yes but...", so I have not gone public with
that. The community needs an architectural picture where we can fill in
the boxes.
AF: The IETF is late to the party; people have their own architecture in
their heads, and nobody has drawn it. Let's share pictures.
DS: Maybe this is more of a semantics problem than an architectural
problem. Privacy policies are defined with different vocabularies. There
is a similar problem with AI agent capabilities.
AF: Discovery is of a basic set of properties. Then the conversation
about who can and will do what starts.
DS, concluding: So we are on parallel paths.
Video: https://youtu.be/vsyUFIwZ7p4?t=1565
JA presenting.
JA (p2): Before discovery, we look at the bigger context, with discovery
as a piece in there (the agent finds its current toolset insufficient).
JA running a demo: listing the agent directory. The successful
operations from Alice depend on the discovered capabilities which Bob
registered. The first lookup for distance information makes our agent
look up a distance agent from the agent directory, and later requests
use that agent directly.
JA: We looked at the different scenarios and at what kind of protocols
and designs exist today, and categorized them.
JA (p4): Using existing tools gets you quite far already.
JA (p12): We still need work on semantic discovery, interoperable
federation, and metadata formats. Trust bootstrapping and lifecycle for
pull-based systems are lacking.
AK: It is an interesting observation that the patterns of the IoT space
apply to the AI space; pieces of software trying to understand each
other and automating how to interact.
DK: This is interesting. In the use cases, do you expect that Alice and
Bob already exist and have been registered, or that they spawn
sub-agents?
JA: We didn't look at that specifically (the on-demand case).
Video: https://youtu.be/vsyUFIwZ7p4?t=2760
OL presenting.
OL: We are exploring if through the use of LLMs we could get
interoperability between data modeling languages (translating YANG <=>
SDF).
OL (p2): How can we be sure to preserve the semantic value?
OL: We prompt for the translation (constraining the context for better
results). The Alpaca format (instruction, input, output) was useful for
guiding the LLM for translation.
OL (p7): We not only pass in examples, but also explicit information
from SDF.
OL (p10): On the measurements, the general observation is that the
smaller the prompt, the better. Fine tuning can substantially improve
the results.
NW: We thought more about the translation of the model; in the SDF work
we looked at cross-ecosystem representations of models. Model mapping is
reasonably straightforward; the harder part is the mapping of "what is
temperature in ecosystems A and B" and "is that mapping good?".
OL: We thought about this but have no good answer yet. For example,
translating Celsius values instead of Kelvins. That is something we need
to work on.
ED: There are several frameworks for expressing YANG/XML/SDF. With some
effort, all of those models could be converted into all others once,
with more resources. That would be less time critical than translations
on the fly.
OL: For the moment we do translation on the fly, and semantic
translation. We want to see what the performance of an LLM is for
different data models, and how capable the LLMs are for translation
tasks. In the future we might want to have different representations and
protocols. We don't have a robust system for new formats, and we are
working on that kind of scalability element.
AK: What's your intuition: do you expect more improvements from AI
models and harnesses, or from better (YANG/SDF) models and extensions
there?
OL: A bit of both, for example using tool invocation instead of entirely
LLM inference.
Video: https://youtu.be/vsyUFIwZ7p4?t=4124
LC presenting.
LC: CoAP and SDF can be enhanced to work better with AI agents. CoAP is
missing the capability to tell apart requests from agents. Interpreting
SDF can lead to hallucinations when certain fields are missing or poorly
written.
LC: We are proposing a new elective CoAP option for an agent to signal
that an agent is making the request. A cryptographic signature allows
the server to verify the identity. It can also enable restrictions on
how the data should be used. The CoRE resource directory can be used for
key discovery. The server can, e.g., return different versions, indicate
use restrictions, or apply rate limits accordingly.
LC (p9): Another approach for SDF is a new content format that is better
usable for agents. It can also include developer defined templates for
translating to an agent-friendly format.
LC (p11): We observed hallucinations. Can we steer the LLM to reduce the
amount thereof? We could add SDF quality with step-by-step example
instructions.
CA: CoAP can distinguish the requester type; there are flexible claims
beyond the subject of the used credential (at least in CWTs; I don't
know about X.509). They can also include a rate limit or have
consequences for one.
LC: Thanks! So the new option is not a good extension point.
AK: Thanks Lorenzo. This was a good example of what kind of things we
could be looking into to fill the gaps for making protocols and data
models better fit for AI agents.
Video: https://youtu.be/vsyUFIwZ7p4?t=4963
TF: This is a short impulse talk on the role of AI in machine to machine
communication. I want to give a perspective on why I am skeptical on the
use of AI.
TF: Why not use AI to solve the complexity problem?
TF: Abstractions have grown from configure / make / make install to
distributions and Kubernetes around Docker images.
TF: There is a danger of losing the end-to-end understanding of
computers, especially the understanding of the parts we're trying to
fix.
TF: If we outsource all that work, we might actually lose that language.
Compare this to cooking: if you turn up to eat at McDonald's every
single day, at some point you might have forgotten how to cook, and that
would happen to me as well.
DK: Computer science is about abstraction.
TF: I agree on computer science. But engineering is about people, and
about solving human problems rather than computer problems.
CA: It's about finding the right abstractions, the few that make sense,
rather than doing an abstraction whenever something becomes
unmanageable.
CK: This reminds me of the simplicity cycle. Systems become more fragile
with complexity.
ED: There is some inevitability in complexity: "life emerged from
molecules and got more complex". That is the way in which things develop
and evolve, and engineers can influence it by coming up with the right
abstractions.
TF: I don't mind IoT getting more complex. It keeps us employed.
MM: I'm not concerned by complexity because it is already complex (cf.
the Linux kernel can't be understood by a single person), as long as it
is splittable to small pieces. My larger fear is whether the splitting
into pieces is done correctly.
MM: To take the cooking example, I spent one week vibe coding and had a
hard time getting back to manual coding. We should create the agent
things "because it's the future", but we can't predict how long it will
take agents to do them.
TF: And if you're able to check, does it do what it promised to?
MM: I'm not even beginning with that.
RG: Is the disagreement about "can AI help us handle complex systems
better", or about "does it just add complexity"? If it's an
entropy-creating thing, we're in trouble (otherwise, good). In networks,
what is the complexity?
TF: From teaching: "understand" can't be measured, so course
descriptions are in measurable terms ("able to analyze parameters").
That is crucial here: do we understand if we get an AI summary? Is it
understanding if we can't perform the task without the tool?
CB: Losing languages is an interesting trigger thought. I used to be a
good assembly language programmer, but probably can't do that any more.
An older professor had to do the spring force equations for relay
mechanisms, and could do that by heart. We lose things we don't need any
more, and we lose languages we now have tools for; that didn't change.
We can rely on those compilers because there is tech out there to make
them reliable, and to test them and get assurance about them. Many AI
tools are used in an exploratory way, without having sound ways to test
them.
CB: In IoT, testing is hard when there is hardware in the loop. SDF can
tell you what a thing can do but doesn't tell you the effect in the real
world. Testing is something we'd need in order to have more reliable
systems.
TF: These are interesting points, e.g., looking back at an X-ray
machine. There are boundaries where we go outside of computers:
semantics, subjective perception.
CB: An anecdote: I was interacting with an intelligence on fixing the
kitchen lights, over many iterations of updating the interactions. But
it was human intelligence, so that is no surprise.
NW: An observation here, from someone also skeptical on AI. Something
humans are not able to do well is the boring things that take lots of
work, like attending to IoT systems. My mother-in-law would not be able
to run or update an IoT system. If it is a proprietary system, you are
under the control of a big cloud player somewhere. When you need another
lamp, integrating it needs an understanding of where the lamp is and how
it works, and there AI can be useful.
TF: We all have experiences of visiting relatives and fixing printers.
The decision for things to be incompatible is not just technical. The
product manager sees revenue and is happy.
MK: A "single person understanding a system" world we had already left
before AI. Even if you are in an industry company or in academia, you
have a hard time making everyone understand. How to break it down and
document it is the key. AI can do something tedious, but it also needs
instructions, as humans do.
TF: There are failures in many places, including collapsing supply
chains. The more the supply chains collapse and the major players see an
AI collapse happen, the more all of a sudden the AI interfaces can be
gone.
DK: Interesting discussion. Many agree that "AI-maxxing" is not always
useful. I'm wondering whether you'd be interested in deducing principles
for useful guidelines for sound architecture decisions.
TF: Usefulness is always a good argument, also when you hear arguments
with devastating impact. This reminds me of Nestlé: "if you want us to
produce chocolate without child labor, nobody will be able to afford it,
so you need to accept it". We see the personal use, while the actual
cost is hidden from us.
DK: Right, it is a question of stakeholder interest: "useful for whom".
Working with AI in a constrained environment, for example.
TF: If we get a simple protocol that works, how do we get the vendors to
use it? Like with XMPP, where we have many instances of the alternatives
deployed.
TF: We have to solve the problem. We can solve it with AI, but we can
also solve it differently.
CB: 15-20 years ago we were meeting in these rooms and discussing how we
can have all those smart things when each uses 5 watts of power, so that
having 200 of them results in kilowatts.
CB: Somehow we've managed to avoid that happening, with way better
energy usage. It took time.
CB: We are still using many systems not yet adapted to IoT use. When we
say AI, we have to qualify that it needs to develop in an actually
useful way.
Video: https://youtu.be/vsyUFIwZ7p4?t=6606
AK: We had good discussions, but we are heading towards the end of the
session slot. Going forward, we can continue the discussion in interim
meetings; we had one presentation on the same topic area that could not
fit here today, and a bunch of proposals on other topics that we could
pick up. We envision some interims happening after the summer vacation
period. Meanwhile, do check out the T2TRG drafts and send your comments
and reviews to the list.