Minutes IETF126: core
minutes-126-core-00
| Meeting Minutes | Constrained RESTful Environments (core) WG | |
|---|---|---|
| Date and time | 2026-07-23 12:00 | |
| Title | Minutes IETF126: core | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2026-07-27 |
IETF 126 - Constrained RESTful Environments (CoRE) WG
Chairs (core-chairs@ietf.org):
- Marco Tiloca (marco dot tiloca at ri dot se)
- Jaime Jiménez (jaime at iki dot fi)
- Carsten Bormann (cabo at tzi dot org)
Date and time: Thursday, 2026-07-23, 12:00-14:00 UTC
Meeting material: https://datatracker.ietf.org/meeting/126/session/core
Notes: https://notes.ietf.org/notes-ietf-126-core
Recording: https://youtu.be/zNrCp2768QQ
Zulip: https://zulip.ietf.org/#narrow/stream/core
Note takers: Christian Amsüss, Rikard Höglund, Mikolai Gütschow
Numbers in parentheses are minutes of time allocated.
Intro, agenda, status (Chairs) (10)
Video: https://youtu.be/zNrCp2768QQ?t=44
- WG and document status since IETF 125
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-chairs-slides-02
MT doing introductions (no agenda changes). Going over the Chairs
slides.
URI Path Abbreviation in CoAP (Christian Amsüss) (10)
Video: https://youtu.be/zNrCp2768QQ?t=535
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-uri-path-abbreviation-in-coap-02
CA presenting.
CA: This document is in post WG Last Call. Next step: Shepherd review by
Carsten Bormann.
Conditional Query Parameters (Bilhanan Silverajan) (10)
Video: https://youtu.be/zNrCp2768QQ?t=680
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-conditional-query-parameters-for-coap-observe-00
BS presenting.
BS (p3): This document is in post WG Last Call. In the latest version,
added tentative value if="core.conditional", indicating server support
for the conditional query parameters.
BS (p5): Message flow example for unsupported conditional parameter. The
server ignores non-understood parameters and processes the rests of the
request.
BS: Ready to progress? Questions?
MT: I have provided editorial nits offlist. They can be processed when
processing the Shepherd review.
JJ: Do we need another submission for title and nits?
MT: Not needed before the Shepherd review. We will have a new version
addressing that review and the nits.
CB: The document title is fine. The document name is not fully aligned,
but changing that would be quite traumatic.
MT: Then we can proceed with the Shepherd review and write-up.
Key Update for OSCORE (Rikard Höglund) (10)
Video: https://youtu.be/zNrCp2768QQ?t=1066
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-slides-kudos-core-ietf-126-00
RH presenting.
RH (p3): Inspired by Appendix B.2 of RFC 8613 (OSCORE).
RH (p7): Focus: Implementation Status, 2 implementations interoperated
during the Hackathon.
RH (p11): On key and context derivation findings from the interop,
helpful pieces of information will be restated in the draft for clarity.
RH (p12): Asking for WG Last Call.
CB: On interop tests: are we really done? Do we need more?
RH: We want to do more; we can do that with Francisco again across the
Internet. (E.g., to confirm multiple executions of KUDOS in a row)
CB: Should we set a date in September for (remote) interop tests?
RH: Good idea.
CA (on chat): please rename the x byte to something related to what it
does
Observe Multicast Notifications (Marco Tiloca) (10)
Video: https://youtu.be/zNrCp2768QQ?t=1694
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-observe-multicast-notifications-00
MT presenting.
MT (p2): Recapping the protocol.
MT (p3): Two new versions since the last presentation. Minor updates
also to the companion document not covered today
(draft-ietf-core-multicast-notifications-proxy), whose content was
previously stripped out from the present document.
MT (p4-7): Covering a lot of updates done in prior versions.
MT (p8): In the payload of the 5.03 informative error response,
typically tp_info is included. However, the semantics of the payload
was changed to define that parameter as formally optional. For example,
there are cases with proxies (see companion document) where including
that parameter would not be strictly needed. Those are special cases.
Normally, like in this document, that parameter is present.
MT (p9): Also added a section about operational considerations.
MT (p10): There is a working implementation in Java, tested both without
and with security. The implementation is at
https://github.com/adriankastrati/californium-thesis-work/tree/multicast-notifications
MT (p11): Ready for WG Last Call?
CB: Just 1 implementation? Interops with itself?
MT: Yes; it took a lot of work to produce it.
CB: How to recruit more implementers?
CA: I plan to implement it too.
CB: So the next step is gaining implementation experience. I think that
we want one more round of implementation testing before the WG Last
Call.
AP (on chat): I would be interested in giving a try on implementing
this. @Marco, is there a git repo I can clone and try to run some code
against?
MT (on chat): @Alex, that would be great! Please see the repo that was
linked in slide 10:
https://github.com/adriankastrati/californium-thesis-work/tree/multicast-notifications
Non-traditional Response Forms (Carsten Bormann) (10)
Video: https://youtu.be/zNrCp2768QQ?t=2372
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-coap-non-traditional-response-forms-00
CB presenting.
CB: The previous talk was an example of this.
CB: In 13 years, we did things that now need finding commonalities. We
might have common code in implementations.
CB (p2): Non-matching: e.g., a response to a multicast request does not
have a source address showing the target where the request was sent to.
CB (p3): This draft is a general discussion about this particular
responses plus proposed CoAP options.
CB (p3): Beyond these general options, others pre-exist (e.g., Q-Block).
The Respond-To Option would need many security discussions for specific
cases, so maybe it is better to just have per-case CoAP options and keep
specifically the Respond-To Option in the backburner for now.
CB (p4): Current proposal from the authors.
CB (p5): Are we ready to go forward with the Response-For Option?
CB: The Leisure-For-Responses Option means "send me up to N more
responses, in addition to the requested response"; we could have extra
variations that mean "I will be ready to receive for N seconds".
CB: Implementation question; so we will not finish this next week.
MT: On the Leisure-For-Responses Option: the mentioned variation is
being specialized in draft-ietf-core-groupcomm-proxy with the
Multicast-Timeout Option intended to a proxy, by which the client says:
"For this number of seconds, I am happy to receive multiple responses to
this request that I am asking to be proxied over multicast". So there is
a partial overlap.
CB: We can point to it.
ED: We could rename the option in draft-ietf-core-groupcomm-proxy to
make it more general...
CB: The Leisure-For-Responses Option indeed rather fits with timeouts
instead of with counting.
CA nodding vigorously.
ED: Still, we can generalize. At the same time, the Multicast-Timeout
Option in draft-ietf-core-groupcomm-proxy is for requests to be proxied
over multicast. I do not think that we defined an analogous semantics
for fully unicast requests.
CA: It makes sense for unicast, we will just require an option to make
the responses non-matching. We have it in Onion CoAP: "I am sending you
this message but the hostname is actually YYY". We should generalize
that, we have ways of using it already in a number of drafts.
CA (on chat): Correcting myself from earlier: The option for unicast
sensibility is in multicast-proxy; the options in Onion OSCORE are
related but not right the ones we need here.
ED (on chat): Also: are we happy to keep the last option on the
backburner - yes ok for me! We can describe its general design.
CORECONF: COMI, YANG Library, YANG Metadata (Carsten Bormann) (15)
Video: https://youtu.be/zNrCp2768QQ?t=3159
-
https://datatracker.ietf.org/doc/draft-ietf-core-yang-library/
-
https://datatracker.ietf.org/doc/draft-ietf-core-yang-metadata/
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-coreconf-unified-datastore-00
VV presenting.
CB: Vojtěch will cover most of this slot, except for the topic of YANG
metadata. Who knows what YANG metadata are? (5 hands raising)
VV (p1-5): Introducing the topic, giving examples.
VV (p5): Utilizing RESTful design; a message is a transaction performed
automatically.
VV (p5-6): For constrained environments, a transaction is
resource-heavy.
VV (p7-8): Solution proposal with respect to encoding.
CA: I have no experience with YANG, but, for implementing CoAP servers
and CBOR, having that list seems very useful.
CB: For context: COMI is pretty old (~2013). It took time to find how to
optimize it with SIDs, but the rest was clear early. NMDA was created in
parallel in NETCONF; it was ignored until a reviewer asked about it. Use
cases did not touch on the problem points, and the unified store was
created. But it disagrees with reality and make-before-break is
realistic.
VV (later): The list can still be indefinite-length.
ED: If one of the items fails, it is skipped it. Is there any feedback
given?
VV: The structure of the response is not yet decided. The tentative idea
is to give feedback.
CB: The CoAP toolkit has two things: RFC 8710 on multipart
Content-Format, and RFC 9290 on concise problem details. Instead, in
COMI, we invented YANG-based problem details, which received
not-so-happy comments (probably we need problem-details anyway). We
might throw out the part of that because we have new tools now.
AP: We are working in this area for 13 years now. Can we just ship
something simple and then do transactions/NMDA like "and here is how you
do it"?
VV: We want to strip out the transaction semantics. The current text
would require rolling back, hence we are proposing those solutions. Then
we can fix atomicity in a later document.
CB: Atomicity would be an extension, while doing simple thing first.
IP: So, now we can get into an inconsistent state, but people should be
careful how they implement things?
VV: Yes, but the server should not care, and the client should create a
message that does not create inconsistencies (and if it does, it gets
repaired in the response).
ED: If you do not want PATCH, you can also use POST, and a future
document does proper PATCH.
VV: This in p8 uses PATCH. A POST would be connected to the YANG RPCs
and actions (i.e., POST is used for something else).
ED: We can just avoid PATCH now and other-PATCH with different
semantics.
VV: Semantics should be from options in the message.
OSCORE-capable Proxies (Rikard Höglund) (10)
Video: https://youtu.be/zNrCp2768QQ?t=4122
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-oscore-capable-proxies-slides-core-ietf-126-00
RH presenting.
RH: Scope.
RH: Completed addressing a review from Christian (two points were still
not addressed).
RH (p4): To address one point, we improved the presentation of the
algorithm for processing incoming requests. The logic and outcome of the
algorithm have not changed.
RH (p5-6): For the other point, we have described how a proxy can
determine when establishing/using OSCORE with an origin server. That
includes discovering support/capabilities of the origin server, which
can rely on DNS discovery and new SvcParamKeys. Register SvcParamKeys?
RH (p7): We also included one more example of message exchange, with two
proxies in a chain.
RH (p8): There are two implementations (one in Java and one in Contiki
NG) that successfully interoperated.
RH (p9): Next steps: handling of multiple responses a-la Group OSCORE;
operational consideration.
MT: About next steps (related to p5), we can also define actual
SvcParamKeys to be registered (they are simple compared to other ones we
defined in other documents). Seeking feedback about it.
KEM for Group OSCORE (Marco Tiloca) (10)
Video: https://youtu.be/zNrCp2768QQ?t=4695
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-kem-for-group-oscore-00
MT presenting.
MT (p1): See also the Monday presentation in ACE:
https://datatracker.ietf.org/meeting/126/materials/slides-126-ace-20260720-ace-oscore-gm-kem-00
MT (p2): Motivation for needing this. In the pairwise mode of Group
OSCORE, the derivation of pairwise keys is currently not quantum
resistant.
MT (p3): Goal: Make the Group OSCORE pairwise mode quantum resistant.
MT (p4): New way to derive pairwise keys using a KEM (e.g., ML-KEM).
Most things in the derivation stay the same; the only change is using
two different secrets (i.e., one per pairwise key), derived through the
KEM used in the group. The Group Manager facilitates the exchange of KEM
public keys and KEM ciphertexts among the group members (similar to the
support for exchanging public authentication credentials).
MT (p5): Detailed functionality.
MT (p6): Requirements for GM that supports this. These are kept at a
high-level in this document. The details depend on the specific
realization of Group Manager. An example is given in the ACE document
presented on Monday. That document is
https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-kem/
MT (p7): There is a placeholder section to be completed, intended to
provide details and guidelines when the KEM used is specifically ML-KEM.
That can take the same style and approach used by other documents about
the same topic.
CA, clarifying: What's the attack that a quantum computer can do? It
would break into the pairwise mode, but it still needs the group key, so
it would "just" defeat source authentication and limit confidentiality
from the pair to the group? (As IIRC that goes into the pairwise key).
The group Master Secret is still protecting group confidentiality as a
whole?
MT: Yes. Good point to clarify in this security considerations.
RN: I will gladly review this document, latest before the next IETF
meeting.
YANG SID Discovery using DNS (Laurent Toutain) (10)
Video: https://youtu.be/zNrCp2768QQ?t=5229
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-sid-in-dns-00
LT presenting remotely.
LT (p1): How can we put SIDs into DNS? When you receive CORECONF data,
you want to understand the received data and find out what the SIDs
actually mean.
LT: Why on DNS? It exists, it is queryable, and it is already used for
this kind of mapping.
LT: YT is short for "YANG Tracker" (and French island). We ultimately
want a domain like .sid.iana
LT: On megaranges. (In particular, SNMP users have PENs that are usable
with SIDs).
LT: Example of querying DNS to get a pointer to a SID file. The
serialization may be result of multiple YANG models.
LT: Proposal on ranges. PENs are better for internal use, but things can
move between companies.
LT: Registrars can maintain integrity.
LT (p8): Open questions.
CA: Considerations from dereferenceable identifiers apply; in
particular, "hey someone opened my file, because they hit my DNS".
CA (note to self): tie in in
https://christian.amsuess.com/idea-incubator/media-types/
JJ (on chat): Is SID+DNS intended for local/private networks (DNS-SD,
mDNS) or Internet-wide too? I would assume DNS folks may complain of
this use.
MM: I have many questions. What happens when a company/server goes down?
The document needs IANA actions: complete the procedure on how to
register DNS sets for every PEN, and another to check if the contact
information is accurate. I could go on. Did you think of these problems?
LT: If a company goes down, the SID cannot be allocated anymore but the
YANG data model exists. So, a registrar could maintain this allocation,
I need to study this case. on the IANA actions, yes, we need to see that
too.
VV: RFC 9595 already talks about how the registry should look like, if
there are requests for megaranges. Is this needed? What is the
relationship?
LT: Good point. We have a link to the SID-file that is not "secure". One
mapping can be between a number and a namespace, then there is a query
for the data model.
CA: Especially when considering delegation, this may cause a privacy
situation. Opening a file can be revealed through dereferencing (here
contacting a DNS server). See Carsten Bormann's and my document
deref-id; it might have more questions than answers though.
VV: For the delegation, the registrar would need to be paid. No one will
pay if the company goes bankrupt. It could be about some old product
sold long ago. I do not see that delegation will work. Maybe we can
mandate devices to carry their own SID file inside them.
LT: That means sending SID files when you send information. With respect
to the business model, it needs study. It will be different from DNS
names (where you lose the name).
AP: The SID RFC talks about registries, it does not speak of an
interface. We could have an HTTP/HTTPS/any interface. This provides DNS
interface to that. The problem around paying is there for anyone. At
that time, we asked IANA, and they said that they will do it for IETF
RFCs.
SB: I appreciate the questions from Maria Matějka. Have you seen such
use cases before with RFID and IEEE identifiers? As a registry we feel
it is economic.
ED: I agree with Alexander and Maria. The IETF could host this for their
registered modules/SIDs. A megarange could just even have things on
paper and not public, and only used internally. So, no general solution.
For IETF standardized ones, it works. We do not require companies to
publish or expose anything. So, the solution would only cover part of
the SID space and, without 100% coverage, it might not catch on. The use
case is not clear from the presentation, but I should read the draft.
LT: The goal is that you need to understand all SIDs in the information
you got, and those may come from different spaces.
ED: Could it be already built into the software?
LT: I had a demo during the Hackathon. We can discuss more.
MM (on chat): thinking through the SID-DNS over and over again, i'm
still convinced that as soon as a device is sold to a customer, it
should be self-contained enough to allow querying its own yang module
and sid file directly. i know that it needs some bytes but consider that
both files can be pre-compressed, and generally the scale of the code is
at best linear with the size of the YANG model and SID file. all in all,
i don't expect the inclusion of the sidfile and yang module to eat a
significant amount of rom/nvram/flash compared to the necessary
parser/encoder code
LT (on chat): Yes the device, but the one that receives the message from
the device ... does it have to be configured with all the SID files to
understand the message
MM (on chat): if it receives a message from a device, it should be able
to query the same device for the sid file and yang module
LT (on chat): a SID file can be very big and in a constrained
environment it may be difficult to get.
MM (on chat): there is no reason to have a SID file unproportionally big
to the constrained environment size → if you are able to process a
complicated YANG, you are obviously able to store a similarly
complicated YANG file and SID file. If you have a monolithic YANG file
and SID file for lots of different machines, and each one is producing
only a small portion of these, then you did a bad modeling job, and you
should have split the modules and cleaned them up so that they contain
only necessary things. People lose files, services go dead, even a
simple static YANG+SID HTTP endpoint will go 410 eventually, and you are
stranded with a device communicating just by weird numbered structures
with no keys to the numbers
CoAP Extensions for Task Resources (Linzhe Li) (10)
Video: https://youtu.be/zNrCp2768QQ?t=6413
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-coap-extensions-for-asynchronous-task-resources-01
LL presenting.
LL: The goal is to provide a way to control/monitor long-running tasks
on a server.
LL: The pattern is common, but the implementation is
application-specific.
LL: Monitoring the task allowed us to identify a fault more quickly.
LL: Showing task life cycle and states.
LL: Details on interaction with tasks, new Content-Format used.
LL: Open issues. Useful abstraction? Aligning with other solutions?
CA:
- The pattern looks familiar.
- At what level are you describing the tasks? Some look familiar from
uploading firmware items (spawning a process). Introspection would be
about getting a backtrace for that execution. - Is it to the level of uploading binary code? Or getting a percentage
of completion? - Introspection: comparison to remote debugging (thread backtrace), and
upload of virtual machines? (p8 indicates from percentage that this is
planned for high-level operations, but is this continuous from low- to
high-level?)
LL: It is for lifecycle. Maybe you can suggest use cases to generalize
this.
CB: This draft is in version -01 now. We could see the first version -00
last week. We had a lot of comments, all taken into account here in
version -01, so very good.
CB: The classical case was the CoAP coffee machine.
MT: The draft considers access control already (pointing to the ACE
framework, RFC 9200), separating the permission for the application
resource from the permissions for the task resource. Looking at AIF (RFC
9237) may be a good way to enforce access control in this spirit.
ED (on chat): I just mailed the list - seeing some similarity
between the 'task' lifecycle and PubSub
https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-21#name-topic-lifecycle
(even though different)
CA (on chat): It's different but there is the similarity that beyond the
CRUD pattern, it has a pair of resources that, in Linzhe's case, might
be "instructions" and "state" and "outcome"
JJ (on chat): We also had that pattern (create a resource for async
check the state of an operation) in lwm2m long ago if i remember right.
it is a common pattern
JJ (on chat): coap has the beauty of observe + query parameters to also
be notified instead of polling. Very neat!
CoAP Message Diagnostic Notation (Jaime Jiménez / Carsten Bormann) (5)
Video: https://youtu.be/zNrCp2768QQ?t=7021
Presented slides:
https://datatracker.ietf.org/meeting/126/materials/slides-126-core-coap-diagnostic-message-notation-00
CB presenting.
CB: Also in the informational space. We are now into 15 years of writing
up CoAP interactions in 1000 different ways.
CB: The problem is the varying notation used, with no clear convention
and no CI.
CB: Let's fix the 80%. Showing proposed notation and examples.
CB: Open questions. Try to apply it to your draft examples. We will
eventually integrate this into the draft toolchain.
(many nods in the room)
MG: Good idea to formalize. It may also be useful for diagnostics (with
Wireshark). On non-traditional responses, how to handle this?
CB: Good question. We can already distinguish a request from a response
using the Code field. The easy answer is to just write down multiple
responses.
CA: It makes sense for CLI clients.
ML: I will have a look. Does it support multiple formats for the
payload? Like hexadecimal and human-readable?
CB: Good comment. CDN is learning to do that.
MT: Please review.
CB: ... and apply the notation to the examples in your drafts.
Σ 120
Video: https://youtu.be/zNrCp2768QQ?t=7541