T2TRG face-to-face/hybrid summary meeting at IETF 123, Madrid
Monday, 2025-07-21, 07:30–09:30 UTC (onsite: Patio 3, 09:30–11:30 CEST)
Meeting video: https://youtu.be/7y4fBymxKDI?t=26
Meeting repository/agenda: https://github.com/t2trg/2025-ietf123
AK doing introduction
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-t2trg-chair-slides-01
Direct link to agenda item in video: https://youtu.be/7y4fBymxKDI?t=352
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-t2trg-why-are-smart-buildings-still-dumb-00
Karolina Skrivankova (KS) presenting
KS: Smart buildings have not quite lived up to expectations yet. Will
discuss here how to make smart buildings evolvable, resilient, and
secure.
KS: Two approaches to building automation in the industry. One is
industrial automation, which is reliable but quite expensive and
difficult to adapt to current operators and users' needs. Another one is
the home automation approach, with devices interacting with a
centralized box and to the cloud through. This is quite demanding in
terms of maintenance. Targeting everyday-life setups, there's a
trade-off between dependability and cost.
Can we take the home automation approach and make it reliable while
keeping it cheap? Going through conceptual approaches, cherry-picking
from the industrial approach.
Discussed example with motion sensors controlling lights. How should
these devices evolve and what to we need to do for that?
Different variants of coupling between new versions of hardware and new
versions of software using it. Software needs to be able to evolve more
independently of the hardware releases. Software can in turn mean
application, firmware, etc.
Hannes Tschofenig (HT):
Commenting on "end users updating sw"; nice idea but misses that these
devices are purpose built. Locked down because of security reasons. How
to prevent attackers making changes. More difficult in future with cyber
resiliency act where lots of responsibility for manufacturers. Business
model and regulatory issue.
KS: addressing later, if try to change device will get more security
issues. But current devices in production are not secure either.
Christian Amsüss (CA; on chat): ad CSRA: Containerization is developing
in embedded devices, and as long as those containers have reasonable
permissions management, this should still be doable.
Gaetan Feige (GF): What is meant by changing software here? Those
devices are purposely built. Defining policies is more about user-side
configuration, not really changing software.
KS: Trying to take advantage of extra processing capabilities of
devices. Devices are capable already. We can do something more useful
than just collecting data. It's not only about the end user at home, but
also about more serious deployments like smart building.
Carsten Bormann (CB; on chat): I think we'll arrive at a new definition
of "smart" device at some point. But this is research anyway...
HT: when say expensive or cheap; need to keep in mind real HW cost and
cost related to many aspects not related to HW. Processes like
certification, real-time requirements in industrial setups. And support
for 20 years. Engineers often don't see but biz people need to take into
account. Need to be careful on judgment here.
KS: yes. Installation cost is major cost here. Real-time requirements
depend on domain; manufacturing vs. smart buildings. Latter are more
lenient. Also addressing how the biz ecosystem could work better.
Expected ability to add support in terms of device functionality,
degrade performance/service gracefully as devices are lost. This all has
an impact on the execution and data flow, towards a control task graph,
i.e., as to what something happening on a device is supposed to trigger
something else on another device in the network/system. This has in turn
to be dynamically adapted, as devices are added and removed.
Specifically on the popular ESP32, it can actually be used well for
decoupling hardware and software and have software developments that
adapt to different stakeholders and run on different platforms. It is
aligned with the intended evolvability and dependability.
A challenging achievement would be to have web assembly on ESP32. That
provides isolation, which is good for security. A main downside is the
limited interface in terms of system calls.
Proposing to use communication channels/services for communication
between the components. Simple PUT/GET semantics. Even if applications
die, data can remain in the communication channels. Performance
improvements and resilience are achievable by smartly mapping
modules/functionalities of one device with those of another one.
Delicate open points on interfaces (including abstraction, granularity
of containerization, development tools, etc.)
CA (on chat): I hope that this call to action is taken up by CoRE to get
dynlink rolling again. (dynlink can model the data transfer across the
network and has an interface for the server to configure the devices,
it'd just need the compute aspect in an orthogonal resolution)
AK: This is largely conceptual. How much of this has been realized so
far?
KS: We have a working implementation of device platforms. We can manage
and move around devices. We still need to implement authorization. Idea
is to have manifest from certification authority, telling what other
containers can talk to, what APIs allowed to access, what peripheral
exposed, etc. Have lots of ideas on orchestration that have not been
implemented yet. Have small testbed now but building also emulator to
support hundreds of thousands of devices.
HT: You're already looking at mobile devices. If you switch for capable
devices running embedded Linux, you don't need to do any implementation
work. You can already do orchestration and be done with existing tech.
No need to rely on WASM either. It looks promising if you just deploy
containers, still relying on cheap hardware. That's also applicable tech
certificate management in the security area. Why haven't you taken that
extra step; tackling now with problems of low-end hardware.
KS: Depending on how much better the cheap devices will get. ESP you can
get in bulk for some 40p. Linux and docker capable devices would be more
expensive. Also for Docker has issue how to constrain interfaces for
external resources.
HT: That problem was solved in the industry. Everyone talks about Edge
AI. Massive capabilities for compute and memory coming because of that
trend. Quickly in Raspberry Pi scale. Requires digging to numbers but
the borders coming fuzzy.
KS: trying to see how numbers work out makes sense; cost/maintenance
benefits too.
CB: I fully support what Hannes said although I don't accept the
consequences.
Dockerization; imagine we had used VMs with web pages for client side
functionality. Every browser becomes hypervisor etc. In computer science
we often solve old problems for new environments. Need to be sensitive
about the kind of environment we'll have in 5-10 years. Important
consideration: we want to have many devices. Then each can't consume a
Watt. How to do useful functionality on platform that is frugal with
energy usage. Don't want to have 40 Raspberry Pis at home creating heat.
Worth thinking new approaches even if old problems.
Manu Fontaine (MF): I echo what Hannes said, and what Carsten said on
security and the ten-year horizon. In the next couple of years, cheap
and small devices can come up with TEE and the like. That can change
features related to authorization, key management, decentralized
computing, etc. Smart devices connect beyond the systems in your
authority. With this in mind, we should think about these problems and
system design on a global scale. TEEs are a major step here that will
become mainstream coming years.
KS: Yes, that supports more dynamic ecosystem. Better security
capabilities, encryption, hardware, etc.
HT: responding to Carsten, shift from higher end device to low-end
higher-end is fuzzy. If want flexibility described here, will favor
model that is embedded Linux style. May not be big power difference
between Raspberry Pi and ESP if doing containers. Will have to look into
numbers. But big difference in developer experience, embedded is
difficult. Regarding WASM, was enthusiastic earlier. WASM was promising
candidate for containerization. But still cumbersome. Coming up with
interfaces from the sandbox the problem. Need many APIs, not only for
sensor access but security, storage, etc. Then looks like cheese instead
of nicely segmented code.
KS: We want to have pre-defined sets of services, then devices can
expose specific APIs according to intentions (e.g., about access).
CB (on chat): numbers: rfc7228bis...
GF: coming back to architecture, full mesh and devices talking directly
to each other is interesting. Ways to avoid failure also with central
controllers. Will need central orchestration point for policies etc.
even if device talk directly. Failovers not necessarily fully automatic.
Making fully autonomous is not easy. If remove central point for traffic
create security issues too.
CA (on chat): The failovers can well be automatic if there are redundant
sources configured.
KS: we have restricted channels that devices can use to talk to provide
security. Taking central box out of critical path; still need for
orchestration decisions. Device needs to do something, like could keep a
copy of container, spin up redundant container. Can have mitigation
strategies that you don't have currently with the rigid systems. Can
also take further offline.
CA (on chat): (With the pluggable software, a "take data from here but
if it's not coming start polling there" is something that can be
deployed by a server that is aware of potential trouble)
CR: You think a lot about keeping things running. There's also another
aspect, about keeping things "in tune" by setting boundaries. "Can only
use this amount of energy" for example. What do you think about it?
KS: exactly what we'd like to enable. Multi-agent optimization
environment. Have talked with lots of people working on building
systems. Cost is mainly in sending out someone to install or replace
something.
Direct link to agenda item in video: https://youtu.be/7y4fBymxKDI?t=3313
CB: now going to the other end of the spectrum, where much more
requirements on reliability and control. Good to understand this is a
spectrum and we need to tackle different parts.
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-t2trg-ietf-iot-frameworks-and-standards-for-secure-communication-at-the-energy-edge-00
Craig Rodine (CR) presenting
CR: Focus on distributed energy resources (including energy storage) for
the sake of managing generation and distribution of energy.
CR: In energy systems, communication is usually distrusted, and the
focus is understandably on safety. This becomes in practice a limitation
on what the system can in principle be made able to achieve. But explore
here what can be done with modern IETF technologies.
Current protection schemes rely on local measurements and actions only.
CR: A strategy to shake things forward is to introduce "just enough
communications", relying as much as possible on well-established
building blocks. In the long run, this can reshape the attitude towards
communication in these systems. Performance requirements are really
relaxed, with no particular expectations and with a lot of leeway. But
it has to be secure and without vulnerabilities. Aim for best-effort
reliability from an IT point of view, but absolutely safe and reliable
from a physical point of view.
Think that these have to be based on open standards. Viability can be
shown with simulation, but we also have prototypes.
Strategic goal: prove to the energy community that these control systems
can be securely deployed and used.
CR: Proposed system "SHARPS" as part of a running project. It's
self-healing: if an event occurs that would normally lead to a
large-scale outage, the system contains the damage and
rebalances/adjusts the system to stay acceptably up. So highly-robust
while threat agnostic.
CR (p6): Example of practical features at work. Notably, devices
self-identify.
CR: The targeted communication model is SNNC (secure nearest-neighbor
communications). It can build on work done already 802.15.4 / Wi-SUN;
get plenty of bandwidth for the current needs. Here to figure out the
L3-L7 of the protocol stack.
CR (p10-11): Listing potentially relevant/useful building blocks from
the IETF to use in this use case (IPv6, 6LoWPAN, RPL, CoAP, CBOR, SenML,
CDDL, EDHOC, COSE/OSCORE, SUIT, RATS) There's also further use cases
that we plan to explore more. Federated learning and compact data with
CBOR interesting here.
CR: would like to know who has used what tools to simulate these techs
(see slide 12). Need for next steps with customers.
AK: running out of time here, very interesting work and hopefully
writeup coming in form of a draft / email discussion but let's continue
the discussion on the list and potentially interims.
Direct link to agenda item in video: https://youtu.be/7y4fBymxKDI?t=4780
Presented slides:
https://datatracker.ietf.org/meeting/123/materials/slides-123-t2trg-agentic-ai-operation-of-iot-systems-00
Jaime Jiménez (JJ) presenting
JJ: Presenting implementation of AI agent that interacts with IoT
devices natively. Often, having something happening in an environment
requires first to have a lot of tools prepared in advance. One would
just like to have something asked and done. The agent can take care of a
high-level request from the user and translate it into a sequence of
actions that eventually produced the wished result.
JJ (p3): Showing the architecture.
JJ (p4): Knowledge based and LLM (from which the agent may also use
training data directly from). Tried multiple LLMs.
JJ (p5): Using "smolagents" as agent. Creates python code for the
actions that also helps make runs more deterministic.
JJ (p7): Used a virtualized docker environment with a few IoT devices,
using CoAP and JSON serialization. Implemented and tested a number of
features (discover, read value, write value, subscribe) corresponding to
actions that can actually be invoked by the agent following the
interpretation phase.
JJ: Showing a live demo
JJ: vague request (e.g., "it's dark") can be given to the system. Uses a
react loop to check facts and uses tools to find suitable devices and
plans to act accordingly to retrieve sensor values and use actuators. We
added bit of description and available methods to CoRE links to support
this. Agent typically checks the result of actions and actuators by
retrieving latest values from the sensors. For out of context requests
(e.g., "make a pancake") agent ends up hallucinating. Can run also in
closed loop; observes all devices and tries to fix anything out of
bounds.
JJ: As a high-level takeaway, agents don't need a priori (pre-knowledge)
about the devices or system they are plugged onto, they learn by
discovering and interacting with the endpoints. They need a well-defined
entry point to start from in order to learn what they need to perform
the tasks they are "asked" to perform. HATEOAS-like Client.
IETF specs part of most LLMs so they are well aware of the relevant tech
here. Standardized affordances can help agents. CoAP is well suited for
agents.
Agent can recover from execution, interaction, and outcome errors.
Agentic systems can adapt to new features in systems at runtime better
than traditional systems.
Alexander Pelov (AP): very interesting work. Glad to see how IETF/T2TRG
technologies like SenML are making this possible. How would work if
would make some time to reach certain temperature and with many sensors?
JJ: already have five sensors here and would need more semantics to know
which ones to use; now just sample environment. Would be nice to test in
more real-life environments. CoAP implementations should work the same.
Also this is natively using CoAP and not, e.g., MCP in between.
Direct link to agenda item in video: https://youtu.be/7y4fBymxKDI?t=6406
Marco Tiloca (MT) presenting.
MT: Efficiently and securely distributing software updates to multiple
target devices, using the CoRE building blocks now available.
Intermediary proxy takes care of distributing SW updates with multicast
and OSCORE for protection. Design goals with making transfer efficient
and secure. Limiting the need to interact with the distributor of the SW
update. New methods presented for dealing with the checksums of the
outer chunks. Maybe future discussion in CoRE for options to support all
this.
AK: interesting discussions on the security and interoperability topics
with a flavor of AI too. Will continue the discussion in interim
meetings and on the mailing list.