Session Date/Time: 23 Jul 2026 12:00
[00:00:41] Karsten Bormann: You didn't set any alarm. Sorry about that.
[00:00:44] Marco Tiloca: Hi, everyone. Welcome. This is the session of the working group at one hundred twenty six. I'm Mark here and I'm a humanist there. Yeah, we assume people to have read the list as discussed in today's meeting. We hope to advance the status of these documents and have a high bandwidth discussion as needed and time permitting not well applies. More on that later. We have two notakers, Christian and Rickard, thank you very much. Please help them out. On the not well, this is just a reminder that you have actually agreed already to comply with the conditions to participate at EIF meetings in particular, but not only it's about APR, please disclose any personal knowledge of IPR that you have or refrain from participating in technical discussion. It's also about code of conduct, so please be nice and professional with one another. Reach out to the AD or the chairs for any question. A few particularities we've been recorded. If you are participating here, be sure to mute everything. You can join the full web interface or use the mobile meta conversion instead. If you are remote, please try to use a good headphone set and, yeah, stop your reading audio unless you're presenting. You can use mic to us to relay questions to the mic. This is the agenda for today. It's very packed. So presenters, please please be on time. And after this introduction, there's Christian, URI Path Abbreviation in CoAP, and build on conditional query parameters. Both document are post working or post call. And then we have representing KUDOS, key update for OSCORE, and I'll give an update on Observe multicast notifications. Karsten has a presentation on nontraditional response forms followed by a slot on different core-comi cop topics that will be actually mostly covered by Wojtek through his slides. Then, recap again with OSCORE capable proxies and that completes the working of documents. Then we have four individual submissions. I start with a new one, came for group-oscore- Laurent presenting remotely, Yangtze discovering using DNS. We had also new submission on CoAP- as asynchronous task resources and finally, Karsten has also a new document to ring up, quoted with Jaime about the diagnostic notation for CoAP message. Any agenda bashing or comments? None? Okay. Christian?
[00:03:30] Christian Amsüss: Hello? Can
[00:03:31] Marco Tiloca: I have a clicker? Oh, we're not there yet. Similar introduction. I thought you had an agenda bashing point.
[00:03:37] Christian Amsüss: Sorry. No.
[00:03:39] Marco Tiloca: Be your turn soon. I'm sorry. No worries. Yeah. Quick update on the document status. We got three year since published since Shenzhen. This is interesting because the the first two ones were published a few hours after the Shenzhen meeting and the third one was published a few hours ago. Only in well, this slide is up to date. So congratulations to the authors and the working group. And, yeah, following right after in terms of status, we have now three documents approved for publication on the RFC editor. Two are bundled together in the same cluster, In fact, together with two more documents from the working group about the group communication for CoAPing itself and security protocol Group OSCORE accompanying that. They are both in final review. And we also have in final review CoAP href. Yeah. Looking at the proof of publication in other working groups as related to core, the documents I've just mentioned, plus a document in IoT ops. I think the first one approved from IoT ops has also entered the RFC editor recently, terminology for constraint non networks. Also, publication requested, we finally made it and we sent to the ASG the CoAP PubSub architecture. So now it's in the hands of Mike. On post working robust code processing, it's about two documents that are both in the agenda for today. You are right from Christian and conditional attributes from Bill. In other working groups related to PubSub, we had also the security profile of ACE for PubSub in CoAP that was waiting for the core document to proceed that happened. So this is now also in ACE expected to enter the Shepard review soon. And in the Shake Working Group, there's also a document obsoleting RFC ATA24 on Shake compression of co headers that are completely working group plus call is expecting a few final touches before getting into the final ship or review steps. Other documents in court has been a number of working group documents updated recently that couldn't really fit the agenda for today, but they received to different extent updates. So please have a look and reviews those. There's also an individual submission that was updated and couldn't fit today on obfuscating the OSCORE option. And we had five individual submissions. The first one was presented at an interim meeting by Lauren and then brought also to the ship working group. I think it's going to be presented on Friday this week. But we had four more that are all in the agenda for today's meeting. And other documents related to call, but in other working groups, there were some updates on working group documents in ACE related in different ways to OSCORE and an individual submission in TeeP by Carlos and one document I presented on Monday in ACE that is in fact related to the one I'm going to present later today. Reviews, thank you very much. The trend is good indeed. I tried to list here the reviewers that stood out on the mailing list, unless I'm missing anything and of course, we are due keys. There's a backlog. We are going to make this even at the end of the session. So don't run away. Much appreciated in the review including issues of comments and PRs on the GitHub. Great job. Please continue. Interesting reports for the Hackathon, there was quite a few things happening around core. There was a project from different people around Javier, but to and related to YANG SID. We had Metro working on the implementation of EDHOC for COSE, but directly applied in the stack including CoAP and OSCORE for underwater nodes. And three more actually, there were implementations and interoperability tests of-two-cutters implementations, we can say more later today in the presentation. And also project from Lindsay was going to present later today, the related draft on CoAP task resources and also unsecure, I think, we call it. I presented updates on the development of the unified and modular CoAP stack in RIOT OS. This sounds great. Thank you very much. And just to remind you that we scaled already and it's all booked for the next years of interim meeting after the say, summer break, but we're planning to resume in in September on the ninth. We should have five meetings until the cutoff for San Francisco, Which now brings up to the actual agenda. Christian's floor is yours.
[00:08:51] Christian Amsüss: Thank you. I'm real. So hello, everyone. I think most of you are familiar with that document, because I've presented it at the last meetings. So the very, very short version is your IPaths can be a bit too long for some applications, so this document presents how to do this more compactly, and especially even in alignment with the IDF rules that we have for not encraching on URI space of our hosts. The current status is that I've received a number of good reviews and even pull requests and worked them all in. Thanks to reviewers for all of that. Most of the changes were editorial. There's one that I'd like that's probably still editorial, but I'd like to point it out. That term reject has a very special meaning in CoAP or with UDP or in CoAP in general. And when we're not meaning that, we write refuse now. IANA has been as helpful as to provide an earlier review. One result of that is that text that used to be in the section for IANA is now moving into the text because IANA won't look at that. And we're not trying to have designated experts here, so it's just I'll make sure the text is where it should be. Working that in is something that I couldn't yet do because I just talked to IANA in the morning, But I hope that that can happen in parallel with the Shepard review, which is, I think, the next step for this document. And that's it for me.
[00:10:23] Marco Tiloca: That should work. Karsten, are you up for the write up?
[00:10:26] Karsten Bormann: Yes. I'm going on vacation right after.
[00:10:31] Christian Amsüss: So then I'm not in a hurry with with working the changes, I'll be doing this also. Okay.
[00:10:37] Marco Tiloca: Thank you. Thank you. In one minute. Wow. So the next is Bill. Right? You have control. Hi. Well, it's Christian.
[00:11:19] Bill Silverajan: Much better. Yes.
[00:11:20] Marco Tiloca: There you
[00:11:20] Bill Silverajan: go. Okay. Hi, everyone. I'm not gonna break Christian's record. I've got probably a few slides here. So the this is about the conditional query parameters for CoAP observe, and the the draft is inappropriately named conditional attributes, but that will change. Okay. Quick I status. Current version is version 13. I think I've closed all the GitHub issues coming into the last one that was open that that was closed just at before this meeting was issue number 59. And that's that's the the the biggest change in in in the in the draft. GitHub shift 59 was actually raised by Christian, but there there has been some context behind that. There's been several mailing list discussions. We discussed it in interim meeting, and then the the the other draft, section 2.4 of the draft that that talked about clarifications and corrections also addressed this issue. Essentially, what we are looking at is how how any resources that support conditional parameters can be discovered. And the the way forward was to introduce this IF attribute with the value core dot conditional. I think it's still, at the moment, tentative. Of course, we can change that if necessary. And it's it's said that the that the resource may advertise support using core dot conditional as a target attribute, so you could you could combine it with other other attributes like like so. Also, the the resource may support this without really advertising the interface type. And conversely, there is no strictly bound condition that enforces that if the interface type has been advertised, then there's no guarantee that a specific kind of a conditional parameter is supported. So the the the granularity is is not that that that fine grained for for this. Okay. That's that's a change. So that's a that's a new section. If you haven't had time to read the draft, please go ahead and and and read it. And then the other part of this was something that I think it was there was also another discussion around it related to the discovery of the of these conditional parameters. And I think what happens if you get if if if an origin server obtains obtains a an observed request that contains a conditional parameter this does not support. So so the the current guidance in the draft on the server processing is that if such a such a condition occurs, then it should be treated as having no effect on the observation. But that doesn't necessarily mean that you reject the the entire request. So the context I I I got from the discussions is that this is what we want, but I just wanna confirm at this meeting that this is exactly what we want. And I've got some examples to show what what's now what's now in the draft so we could we could have a quick quick look at it. So, essentially, what we're what we're saying is that there are two examples here. If you are doing an observation and you have a query parameter such as this that has no real support, what really happens? So you're not gonna reject the entire request, but the the the server will process the request in such a way that it will process it as a regular observe. It will process it with the with the understanding that, okay, I don't have support for conditional parameter c dot new thing, which means that you're just gonna get a resource update each time the the the resource representation changes. Similarly, in example two, if you have a, let's say, slightly more complex string with a bunch of query parameters, and then you do have support for some and you don't have support for the others, then you go ahead and support the ones that you actually know. So it's sort of here as a no op, but my impression is that this is what we want, but we're we're we're we're good to change that if necessary. Okay. So this is basically the the the the the biggest changes in the draft, which means that I removed some bodies of text that that said we're not gonna support any sort of in interface formats and and and so on. So that's that's just a bunch of text that's taken away from the I think it was the server or the implementation consideration section. And then the last part is that it has already been as as Marco mentioned, it's already in the post working group last call. We received early review from the IT director already. Documents ready to move forward. And that's it. That's what I'm looking at. So I'd be happy to take any questions either today in the mailing list.
[00:16:18] Marco Tiloca: Any questions, comments today? Yeah, just minor I just have minor editorial needs that I suggested you offline and I can make a small PR later around the shepherding process, but it's really needs nothing substantial.
[00:16:35] Bill Silverajan: Sure. Thanks. Yeah.
[00:16:36] Marco Tiloca: Yeah. And we have a shepherd appointed.
[00:16:40] Shepherd: So I'll I'll do the shepherding. Like, maybe one question. Do we do another submission before the shepherding for, for instance, for the title and other minor needs?
[00:16:48] Marco Tiloca: Not because of my needs. I can make a PR to factor in, to prepare a final version to send to the IRG and that we we can work on that together with your comments for
[00:16:58] Shepherd: the whatever you prefer. Yep. Thank you.
[00:17:00] Karsten Bormann: So, the title is fine. The draft name is wrong, but changing the draft name is always traumatic, we shouldn't do that.
[00:17:13] Marco Tiloca: So we can proceed with the Shepard app, I think. Yes. Okay. Awesome. Okay. Thank you, Bill.
[00:17:21] Bill Silverajan: That's it. Thank you very much.
[00:17:22] Marco Tiloca: Thank you. Got it. And these slides are not ordered now, so I need to take the long route.
[00:17:37] Karsten Bormann: They
[00:17:40] Marco Tiloca: ended up in the end. Let me give you control.
[00:17:46] Rikard Höglund: All right. Thank you. So hello, everyone. I would like to present some updates to this draft, key update for OSCORE, also known as Kudos. And just to recap, I think many people know what this is about, but it's basically a lightweight key update functionality for OSCORE, where you want to renew the master secret and master salt to derive new sender and recipient keys. It has a lot of beneficial properties and it's flexible in terms of message flow so that really any core message, any OSCORE message can be a kudos message. It's loosely inspired by the Appendix B2 key update functionality in the OSCORE RFC but with multiple improvements. But fundamentally, it relies on exchange of two nonces, N1 and N2. And these are placed in a new field in an extended version of the OSCORE CoAP option. You then feed these two nonces plus x byte that encodes the length of the nonces and some flag bits for various functionality. You feed that to this updateCTX function, which essentially produces a new master secret and new master salt. We have some features of kudos like preserving observations. We also have two modes, one for a secrecy mode and one no for a secrecy mode. The reason we have this no for a secrecy mode is to support very constrained devices that cannot store to persistent memory. Usually, if everything goes right, kudos will finish in a single round trip. We have basically a state machine. That's the way that kudos is described. So you have these three states, either busy and pending. And when you start Kudos, you go into the busy state. And then depending on your own state and also the messages you receive, you will progress in the state machine. If you want to see here, it's basically the state machine and normally, you would have a quite straightforward path to the state machine going from the pre idle to idle to busy and then back to pre idle when kudos is finished. But basically because messes may be lost or reboots may happen, there are also some more complicated paths that you may take through the state machine. But the fundamental key thing is that you will end up finishing going through the whole state machine and either you establish new master secret and master salt or, I mean, kudos fundamentally fails and you revert back to your old context to continue using it. So yes, what are the updates we did now for Version 14? Number one, we removed a section describing a Yang model for Schick which turned out to be redundant. And this was also related to a comment to another draft where the same change was applied, basically saying that, I mean, there's no need or it's even inappropriate to put this young model in this document. We did a number of editorial improvements, update to the legal boilerplate and other metadata. And the key thing that I want to focus on is that we added a section, our implementation status covering two working implementations, one in C and one in Java. And we also had a chance to do interrupt testing of these during the hackathon. So what are these two implementations? Well, implementation number one is from us, RISE, basically implementing Kudos in Californium, in Java, building on an existing implementation of OS core that we had. And then we had other implementation from people at University of Murcia, specifically Francisco Lopez Gomez and some of his colleagues. So a very big thank you to them for implementing this and offering to Interop. And this was actually built in C based on this U. S. Core UADoc library. That's an existing library. So what happened during the hackathon? Well, we managed to do interrupt testing of these implementations. So starting with the Java client and C Kudos server, We did a successful execution of kudos in the forward secrecy mode and confirming that we end up establishing the new master secret and master salt that are equivalent, which in turn means we get the same sender and recipient key. Now we did try two consecutive executions and we did have a problem here because the new of course security context derived did not have its replay window reset to being empty or uninitialized, meaning that when we ran the second kudos execution, we had this replay detected error, which is functionality from OSCORE, basically. But I think this is a minor thing and it can easily be fixed if we have more time to work on it. Then we also tried the Java server towards the C Kudos client. And again, we successfully executed kudos in the forward sequence mode, a single execution. So those are the results, I mean, very successful. And then we also had some lessons learned. So for the specification clarity, one point that came up was it's actually a bit ambiguous to say that you sort some data or byte arrays in lexicographical ordering because that can mean like you always take the shortest one first, but it could also mean like in a dictionary that you actually compare the you just compare the bits straight up, right? So there's a better word, this short lex order, that's more specific and that's the term we should use. That's the term we intend to start by comparing the length. Only after that, you compare bit by bit if the length is equal. Another kind of nuance that we noticed is that because we inherit this structure from TLS that we feed to produce this kudos expand label and some of these fields basically are vectors, variable length vectors, so opaque data. But if you carefully read the TLS RFC, you will see that actually this vector data type is defined such that you need to prefix the value with the length, which was something that we actually missed. Another thing to clarify is that we say in the draft, like, okay, the MTC per buy string is indicated as 0x. But just to note that, okay, it's actually encoded as 0x40 for the purpose of bit comparisons. Other points about the key and context derivation. When you derive a new, of security context, you should derive a new sender key, a recipient key, but, very importantly, also the common ID. So we can stress this. We're basically pointing to the normal OS score context derivation, but this is good to point out. And also to point out that this new context, it should be like it's a brand new context. You start over from sender sequence number zero and you have an empty replay window, which is fine because you have brand new keys, it's not a security problem. Another point we noticed, that was kind of nuanced more about OSCORE itself, but when you do the construction of the AEDNANS, you should use the sender kid length even if that kid is not present in the OSCORE option of the message. But you still can retrieve that from the OSCORE security context. Yes. So to summarize, I think the design is in a very stable state. We didn't do any major modifications in a number of versions, and we have no major modifications planned. So we would like, as authors, to request working group last call for this document. As far as implementations, I mentioned we have two working ones, Interop, and we also have a third one actually kind of work in progress for Contiki NG in C, which needs to be updated still to be aligned with the latest functionality. And yes, that concludes my presentation. Any comments, questions or reviews are welcome.
[00:25:53] Marco Tiloca: Yeah,
[00:25:55] Karsten Bormann: I'm not sure when you talked about the interrupt test that happened here. It's good that we have these interrupt tests. Are we done? Are we happy? Do we want to do any more?
[00:26:15] Rikard Höglund: Yes, very good point. I mean, we want to do more and I talked to Francisco. He said we can really do interrupt at any point because, I mean, we don't have to sit together in the same room. I mean, we have the Internet, right? So yes, and specifically, what we would like to do is multiple consecutive executions and see that it works. We would like to have that done also, yes. Now it was a minor thing to fix, but I think that would be good to do.
[00:26:41] Karsten Bormann: Okay. So would it be useful to maybe fix a date and say in September, where we don't sit in the same room but do communicate synchronously?
[00:26:54] Rikard Höglund: I think it makes sense. We can set a date in September. I can run that update, you know, new interrupt with updated code. Just confirm that we can do the multiple executions. And then we can have more kind of strength behind this interrupt to say that it's more like fully featured interrupt, let's say.
[00:27:20] Marco Tiloca: Yeah. Christian just a note in the chat that he has editorial comments, but will come on the list.
[00:27:25] Rikard Höglund: Okay. Thank you. Sounds excellent.
[00:27:28] Marco Tiloca: Thanks. Now I have to juggle a bit.
[00:27:49] Karsten Bormann: The the number of clicks you need to do to get a slide set uploaded or active reminds me that when I joined University of Bremen, I needed 18 signatures to get a student employed. And this has been designed by the same people apparently.
[00:28:13] Marco Tiloca: Okay. Hello, everyone. This is an update on the CoAP Multicast responses document now in version 15. To recap the overall idea, this is an extension to observe the finding seventy six forty one introducing observed notifications as responses sent over multicast. It's useful in a scenario where you have multiple clients all observing the same resource at the same server, and it'd be preferable that the server notifies all of them at once with a single response sent over multicast. And the idea is that as a new client comes, it attempts a traditional observation request, and the server technically rejects it with an error response offering something better, which is instructions to for the client to align itself and get ready to receive the multicast notifications. The alignment is, first of all, in terms of transport, making I mean, having all the clients on the same page in terms of token value used for all the multicast notifications all bound to a same request, which is in fact the cosmetic request that the server produces, sends to himself, and provides to all the client. If you use Group OSCORE for security, there's also security binding between all the multicast notifications and that cosmetic response using the same traditional mechanisms we already have from Oscore and Group OSCORE in the external AAD. Okay. What happened since November, actually, last time it was presented, we produced two new versions. One in April right after Shenzhen where it was not presented and one more before this cutoff deadline. I'm going to overview those updates. In parallel, there were minor updates made also on on the companion document describing how this is used in setups with proxies If you remember, it was part of this document and it was stripped out, just not overbought this document too much. Yeah. By focusing on this document and the first update that happened in April from version 13 to 14 other than minor editorial clarifications, we made it super clear like it is in other documents related to OSCORE that the conventional way today to identify an HKDF algorithm is actually identifying the HMAC algorithm on which the former is based. Then we have had for a very long time in appendix d describing how this can be used in an optimized way together with the deterministic requests defined in another document, cacheable- That has a number of advantages. Yeah. We re edited that part a bit to describe a bit better what is expected fundamentally support for that method and what the advantages are, especially for for the clients in terms of a bit less over and and a bit less operations to to perform. And, essentially, in a setup where such a support is is ready and the server is able to support anything like this, well, the server is encouraged to use this method building on cacheable- score. But otherwise, it remains a side optional thing. More on that same update, I try to be a bit clear on what is required from the client and the server side to do in terms of roles in the group if Group OSCORE is used and the server really needs to be both requester and responder, at least if more groups are defined in the future. The client can really be anything and things will work either way, unless, of course, the client wants to send the original observation request with Group OSCORE already and, well, in that case, it has to be at least requester, but inevitable. The update in section eight one was a very good suggestion from Christian about generalizing the semantics of an option that we were defining in the interest of this document to enable the rough counting of still interested clients. The semantics was generalized and the name was shortened just to mean the option as a nudge to the recipient of that message with that option to come back with another message for whatever reason because they wouldn't happen otherwise without this nudge. So that's more general now, but in this document, we are keeping using it the the original intended way For the sake of triggering a feedback for the sake of the rough counting of still active clients. On the second update made in July and beyond the federal fixes, there were some CDDL notations that were not valid and that I fixed. And in section nine two one describing the protection of the phantom request, yeah, it was really precise and say, you use group scoring in the group mode. Yeah. With the exception that if you use that particular optimization for cacheable - score, it's not the group mode that is used. It's the pairwise mode. At least it's highlighted now. This was a bigger update that was floating as remnant of notes of of all sessions that that Christian left as post meeting actions, think. What you see here in the figure is the payload of the error informative response sent to clients. We have had that field last notice all along in principle optional and still is it's the field where the server can include the latest sent multicast notification. So, of course, it's still there and it's still optional. It should be included now, and that's just in the interest of making the latest notification available as soon as possible to the client at the time where the error response is sent already. And this importance, I believe, grows even more if there are proxies deployed in between the client and and the server. And related to that, I added also some more text about the the age of the multicast notifications. If they're actually sent on the wire, well, that's just fine. Their age is what is indicated by the max age option or 60, which is the default if the option is not present. But if the multicast notification is taken from that field of the data response, well, that age as it is indicated there is less reliable because it's it's a relative time from from the moment when the server produced that multicast notification, not from the time when it sent the error response. So trying to amortize this this this analysis introduced here that the server must compose and send a new multicast notification when from its local point of view, the latest one has reached its max age. And for the client, we just added consideration about how to read the age indication in anything present in last notice. And still on that same payload, this was another floating suggestion from Christian about making the first field, the TP info optional. For a long while, it has only been the the only mandatory field. Now it's formally optional as to the CDDL and the text says, well, it may be omitted in some particular setups where somehow the clients already know the transport related information and the server assured that that is the case. And we actually have examples in the companion document. Well, that can be the case in deployments with the reverse proxy. Similarly, getting into the TP info subfield TPI details that may also be omitted in the particular case where CoAP interest is transported over UDP and IP multicast. But this is all in the interest of special setups and the formal semantics. Otherwise, like we do in this document is the normal case, that information is expected to be included and must be included. Okay, finally, we also added a Section 13 operational considerations describing usual suspects contents like what the server is expected to log locally according to events that happened there, the management and distribution of key material, and how it is possible to enforce access control. Yeah. I can report an implementation that happened at RISE, but in practice, thanks to the great work of a master student, Adrian Castrati. It's for Eclipse Californium. It was tested with up to three clients and one server. It worked fine. It was tested without security at all or with security, meaning OSCORE was used for the original observed request and corresponding error response, and then group OSCORE was used to protect the FANTUM request and to protect the multicast notifications on the wire. Yeah. We believe all the content we have in mind is here in the document now, refusing quite sometimes stable in its core for a while. So we believe this can be considered for working group plus call. And just pointing out, there are normative references as internal drafts, but four are with the RFC editor. The other one is EDN literals that we are using for the CRI notation, and, of course, a flag is raised because the death tracker says it's informational while it's intended to be standard struck, but it's not meant to be a down-ref. It will sort itself out. Yes, that's all I have. Thank you.
[00:38:03] Karsten Bormann: Right now, we have one implementation that that interoperates with itself. Very well.
[00:38:12] Marco Tiloca: Yeah. And it took some time to make that one even if it was in Java that facilitates prototyping and so on. Sure. There's AI today and such. I don't think something like that can be done quickly. It was quite some work.
[00:38:33] Karsten Bormann: So what is the best way to actually recruit more implementations? It must be somebody who cares about multicast.
[00:38:46] Marco Tiloca: Honestly, my best hope is Christian. Recruiting in general can be not simple.
[00:38:53] Karsten Bormann: So we got a thumbs up there. That sounds good. Okay. So the next step there is actually to gain experience through implementation and then we are ready for working plus call, I think. So working plus call wait? I would think we want one more round of implementation testing.
[00:39:20] Marco Tiloca: Thank you.
[00:39:32] Karsten Bormann: Okay. Marco just gave an example of the kind of thing I was going to talk about next. The the basic idea in CoAP, of course, is that there is a client and that sends a request, and then the server sends a response to that client. And that would be a traditional response. And it turns out we have quite a few nontraditional responses out there right now. So it was time after ten years or certain years now to to look back and see what have we be do what we have what did we do that maybe requires some some breaking in again and then finding commonality and so on? So a while ago, I started writing this correspondence thing and then Christian helped me with that. So basically, have multicast re requests as one case. Marco has talked about multicast responses. We have we have observation requests. We have an RFC that explains how to not send a response at all. And we have the the queue block mechanism that just sends you multiple responses at once. And these are all counted as nontraditional because they don't fit the original pattern which was one client since one request was over that since, like, one response and we're done. And, of course, there there are implications of having these nontraditional responses. For instance, the the request might stay active for a short while or even for a long while and so and so, there may be some common code between these various ways of doing a nontraditional responses. So that's why we started writing that thing. So, yes, a non traditional response is one that that is not the single response one that is generated for request received on the same transport. Non matching response is the response that you get, but that actually doesn't match. So multicast requests don't get replies to the multicast address. That would be weird, but get sent to the original sender. And we have two ways to handle a request in in this situation. One is a configured request. That is a request that is given to the server in some other way. Than in in a normal response, the traditional response, and that might even be configuration. So devices configured when you switch it on, it starts sending responses somewhere. That's why we talk about configured requests. But all cases where where what the server gets is not simply request coming in over the network. It's a configured request. And orthogonal to that, we have embedded requests where the server actually writes the the request that can also be called a phantom request into the response because a response that has no request associated with it is a little bit difficult to process. So you either know from configuration what that response is for or you maybe embed the request into the response. Luckily, we have the the Oscore format for embedding one one thing and one other thing so we don't have to invent a lot to do that. So that's the the landscape that is opened here. The draft has, besides this general discussion, a number of options being proposed. And for a while, we weren't so sure what to do with these options. So response four is an option that can carry a embedded request. So this says, here's my response. And by the way, the this response is for the request given in this option. So the the receiving client has an idea of how to process this. And as I said, we have the OSCO format for requests and can use that. So this is a response option. And on the request side, we have the leisure for responses, which is one way for a client to indicate readiness to receive multiple responses. We have other ways, of course. For instance, Q block has ways for a client to say that. But this is intended as a general way to do this. And we also, I would almost say, hallucinated about an option to respond to because that is your your typical three legged situation where a asks b to respond to c. And we know that has some security implications if you don't do this in a very controlled, very safe manner. So to actually complete the description of of this option, we would need to explain under what situations it is safe. And, really, there are so many different contexts, so there's so many different situations you might want to do this that it's probably a better idea to have options for the specific cases that we know we can make safe. So this this has been known for a while, maybe not not aggressively discussed on the mailing list because it was kind of common knowledge. But that that, of course, has the disadvantage if we don't get discussion, we don't get progress. And maybe we should now learn from what was on the previous slide and distinguish between those, CoAP options that actually would make sense today and those, that we have to develop further. So the current, draft, proposes to go ahead with leisure for responses and response for and to put the respond to on the back burner, describe its general characteristics so that specific drafts can pick this up if they can make use of it. But it's not something that we standardize now because, yeah, to do this in a general way is is a problem that is not yet solved. So, yeah, my last question or my my questions slide, questions to the working group. Is is that a reasonable perception? Are we ready to go forward with response for and leisure responses? A leisure for responses is that something we we want to have as part of the the toolkit, as part of the options that are defined for CoAP. Very well knowing that leisure for responses only has one way to put a limit on there, so we may want to to define variants of that. So leisure for responses counts responses. It says, send me up to five more. But maybe I want to say something like, I'm going to listen for for five seconds for more responses, and then I'm off the radio again. So that those things are conceivable, but it will be very easy to model them after the one that is in in this draft. And conversely, on the respond tool, we put this in the back burner. And there are two ways to do this. Just strike out all text or keep the discussion in in the appendix. We opted for keeping it in the in the appendix at the moment because it's just good for someone who does need to define a respond to option. So that would be the proposal to to go forward. Of course, then again, we have the question, who has implemented that? So it's not going to be completed next week. But that might be a reasonable way forward. Any comments on that?
[00:48:58] Marco Tiloca: I have a comment on leisure for responses. We already have a specialized version of it. If you want in the groupcomm proxy document, there's a multicast timeout option for request that is serving two purposes, saying, first of all, I'm happy to receive multiple responses and for how long and that's intended to be consumed by a proxy though. Still, it's kind of aligned. There's a partial overlapping. So I don't know if in your general blueprint you had in mind to cover the two or diverges enough to be really something different to be rechecked.
[00:49:37] Karsten Bormann: We could simply point to this and explain that's the other way of doing it, not using a number at a time.
[00:49:49] Marco Tiloca: That's good.
[00:49:50] Esko Dijk: That's good, Ike, joining in. So I was thinking while you said that that we might could we could rename our option to make it more general. And then, yeah, instead of saying multicast leisure, just calling it maybe leisure for responses or or something.
[00:50:07] Karsten Bormann: Yeah. Leisure is actually something you would associate with time and not with numbers. So that's maybe a better name for your option that we call.
[00:50:14] Marco Tiloca: This one's okay. I I was coming to that. Yeah. There, we really measure time and then as many responses come, whatever.
[00:50:24] Esko Dijk: Yeah. The difference is in time versus measuring something else, right, so the number of expected responses. And in our case, it was really time. So Yeah. But we could still generalize that, like, that you can think of even without going through a proxy or multicast that you could just say, well, send a request and put a leisure option in and then expect responses to come within that time, for example. But although I I don't think we have defined what actually it means for unicast request to have, like, two answers, for example, from the same server. I don't think we have semantics for that currently, but but well, once we have the option, we could start thinking about that.
[00:51:11] Marco Tiloca: Measure for multicast laser for response.
[00:51:18] Esko Dijk: Okay. But that's an idea, to do something with the naming and to make it prepared for the generic case also.
[00:51:26] Christian Amsüss: Justin, I'm just yes, I think it makes that option makes sense for unicast and it will just require an option to make the precise responses non matching. We have in Onion-OSCORE, actually in Onion-CoAP, options prepared that are basically around something like I'm sending you that message, the host name that this is really about is this and that. I think that slots in nicely here because if you were using that multicast proxy and you're taking multiple proxy hops, it's even in there. Has to be an option that disambiguates where that response is coming from and that can work with unicast just as well as with multicast. I we should generalize and we already have the options that make use of that.
[00:52:21] Marco Tiloca: It's just about finding a better name.
[00:52:24] Karsten Bormann: Christian is a co author, so that will be easy to do.
[00:52:28] Marco Tiloca: Yeah.
[00:52:29] Karsten Bormann: So I know how we go forward.
[00:52:31] Marco Tiloca: Thank you. So next is. Not you. Yeah. Right?
[00:52:38] Karsten Bormann: Yeah. Okay. Let me say one sentence while is coming up. So the next section is the usual section. We discussed this and and it would be a good idea to just talk about. Today, we have two other documents that we need to work on. One is the the YANG library document, which is kind of interesting because in the YANG world, the YANG YANG library has gotten a lot of fresh discussion, and we need to find out which of that is actually applicable to us and which part we we can ignore. And what was the other document? Metadata, which is essentially a slam dunk, but right now, it's just waiting for someone to implement it. And so if you are interested in YANG metadata who in this room knows what YANG metadata are? I do. Ned knows. Not bad. Five people is is probably a higher concentration than you can find in many other pieces of the planet. Okay. So these these are not the subject, but we're looking at COMI. So
[00:54:02] Wojciech Kozaczynski: let's focus on the COMI. Short introduction. The NetMod working group produced the YANG, which is modeling language for configuration, status data, and similar things. And they have protocols such as netconf and resconf for accessing the configuration and changing it. And so we want to bring CORECONF for the constraint environments. The in the YANG world, they define the tester, which is like copy of the configuration and it may be in several instances like the whole configuration can be. So the data store is basically a storage for the configuration, and we can have multiple data stores to describe different configuration for different states. The architecture is pretty complex, so the CORECONF just specifies one data store to make it simpler. And I think the specification is not clear and it is not complete for the unified data store of the CORECONF protocol. This is citation from the draft. This is table required to describe the data store. And this is example of CORECONF message. Here I want to emphasize the format content type which is not CBOR but CBOR sequence and the items in the sequence is always CBOR map. And about the semantics. The CORECONF protocol is designed as a similarity, a similar protocol as RESTCONF. And the RESTCONF protocol is utilizing the RESTful design. And the restful design comes comes on that message is a transaction and the transaction is performed automatically. But I am not sure if this design is good for the constraint environments because implementation of the transactions is resource heavy. We the pass the mess the messages of the CORECONF protocol is richer than the messages of the rest conf protocol, and this brings the this created problem even harder because we are not talking about one sub tree. We are possibly talking about transaction consisting of several sub trees of the data store. So my proposition is that the tran the request is not processed as transaction, and we are processing the things in the message one by one. And I suggest these solutions. The thing this the first one is just simple. The transaction has several the the message request has several CBOR maps and we process them one by one. If something fails, we don't care, we just continue processing. The made before break semantics creates a group when we are also processing the things in the the request one by one, but when we happen to encounter a problem, we just skip all the remaining parts of the group. I would propose that we encode the group as a CBOR map. This way we don't so I think the CBOR sequence is used to make make it easier to stream the data in the packet, but we can imagine it as being an implicit map of the implicit array of the maps which is the tasks done in the request. Yes, this is asked. So I want to open the discussion, what do you think, and ask the working group for comments.
[00:59:28] Christian Amsüss: I have very little to actually none experience with Yang, but with implementing CoAP servers and CBOR, having that list sounds very reasonable, especially because the sender will know the length of what they want to have done in a make before great fashion and then can still retain the options to stream the rest. So it kind of looks good from that perspective.
[00:59:52] Marco Tiloca: Yes, Karl, you also in the okay.
[00:59:59] Karsten Bormann: Yeah. Because the moment, I just wanted to to give a little bit of historical context how we got into the situation we are in. So COMI is a pretty old document. So I think we started this in 2013. Took us a while to understand that we wanted to have SIDs. But parallel to that, it was pretty clear how to use YANG to the people involved. But then the the net mod net conf people came up with NMDA, which is the new data store architecture or something like that. Thank you. And we actively ignored that. And at some point, the review review from from the Yen community asked us, what do you do about NMDA? And, yeah, we said, no idea because none of the experiments that people were running really seem to need that. So Michel went ahead and and wrote a section that explained, oh, we have a unified data store, and and we can do things. And yeah. But that's not the reality that we find in the CORECONF implementations today. And so this this is essentially an attempt to create a low overhead solution to the the problems that we actually might have, And the biggest one is to make for make before break problem that if you have a number of configuration steps where where one step needs to succeed or the next step step will disconnect you from the network, it makes sense to group them like what I described here.
[01:02:03] Wojciech Kozaczynski: You.
[01:02:08] Esko Dijk: Scott, just a question. If, one of the multiple items fails, I think you proposed, then we can skip it. So is there a feedback then back to the clients? So what succeeded, for example, and whatnot?
[01:02:22] Wojciech Kozaczynski: How the response is structured is not yet decided.
[01:02:30] Esko Dijk: Okay.
[01:02:31] Wojciech Kozaczynski: So I I that you fill in the things that you can do and the things where you have an error. You just put none and some kind of tag to describe the reason of of the error.
[01:02:49] Esko Dijk: Okay. Yeah. That sounds good. At least to have the feedback clear in that case. Thanks.
[01:02:59] Karsten Bormann: CoAP- kit, we have two things that we would pull out. And one is RFC eighty seven eighty seven ten, which tells you how to send back multiple responses to to something. So that might be useful. And, yeah, we can use the the, how do you call it, problem details mechanism that we have copied from the HTTP world. Instead, in in COMI, we invented a YANG based variant of the problem details mechanism, which which already has received some some not so happy comments because you probably need problem details anyway in in a server that that is on the Internet. So we now have two different ways of of doing this. So that's maybe some place where we could say, okay, we could take the big hatchet and and throw throw out part of the document because we now have new stuff we can use.
[01:04:22] Alexander Pelov: So thank you very much for the presentation. So mentioned that we've been working on this draft for thirteen years now. And I'm just wondering, can't we try to ship it? Is this is a simple way and then have another document that says, well, actually, doing transactions and M and D and all that, this is how you do it. So here we have a very simple COMI for super simple devices and you should do transactions like that. Do the other.
[01:04:53] Wojciech Kozaczynski: No. But basically, this is the point. I want to strip the current wording. I want to strip out the semantics of transactions because if you look at the text, the patch fails whenever there is error, and you should roll back back to the state before the patch, which we don't want. And so we propose these two simple solutions, no no dependencies whatsoever, and dependencies as in a group. And we then fix the atomicity of the processing of the one request in later document.
[01:05:36] Karsten Bormann: Yeah. So the the atomicity would be an extension that we can think about for some more time, but we do the simple thing first.
[01:05:51] Participant: So do I understand correctly that now with this thing, we can get into inconsistent state, but we trust people will be careful how they develop their models so they don't do that while we fix things.
[01:06:10] Wojciech Kozaczynski: Basically, yes. But I think that the server should not care and the client should create the message so that it shouldn't create inconsistencies. Or if if it does, it should repair it by by the contents of the response to the request.
[01:06:35] Esko Dijk: Just a small addition, If you don't want to apply the patch semantics, then you could also say we're we're going to use a post now, and a future document will define proper patch or something like that. That's an also an option. I
[01:06:58] Wojciech Kozaczynski: think that this is the patch. Like you have several things you want either delete, create, edit. And if you are sending a post, it is connected to the YANG RPCs and YANG actions, which is a type of RPC. So the post is already used for something else.
[01:07:19] Esko Dijk: Okay. Yeah. That's already taken then. Yeah. No. Just to avoid having a patch now and then needing in the future a second patch with another semantics that that would maybe not not be so nice. So
[01:07:33] Wojciech Kozaczynski: I think that you should decode the semantics of the patch from the options in the message in the record. Okay.
[01:07:44] Esko Dijk: Thanks.
[01:07:48] Wojciech Kozaczynski: I want to also respond to the to the Christian comment that the map may be indefinite. So you are not aware of how many things there are. Anything else? So thank you very much.
[01:08:11] Marco Tiloca: Thank you, k. Next should be Ricardo. There you go.
[01:08:36] Rikard Höglund: Right. Thank you. Yes, I would like to present some updates to this draft- or -capable proxies. So what is the scope and content of this document? Well, we're updating RFC 8,613, which is the OSCAR RFC, and also 8,768, which is the hop limit option, RFC. Basically, we're defining the use of OSCORE in a communication leg including a proxy. So this means you can have OSCORE between an origin client or server and a proxy or between two proxies in a chain. So basically, you make the proxy like an OSCORE speaking node, which is something new. We also are defining rules for the escalation of protection of CoAP options. So this means that if possible, you should encrypt an integrity protect an option even if it was originally classified as Class U for OS core. And the point here is that we want to protect options as much as possible and when proxies are involved as OS core speaking nodes, you can actually protect more options such as the proxy URI option can be protected for the proxy. We are also explicitly admitting the nested protection of OSCORE messages, which is needed for the solution. So you may have an end to end protection between the client and the server. Then you have one more layer of OSCORE protection between the client and proxy. Typically, you would have at most two OSCORE layers for the same message, one end to end and one between two adjacent hops. But you can add more layers as you wish. And this is also something new that OSCORE currently does not support. On the hop limit option, we're defining that to be class U for OSCORE just because there was no class defined for it. And the focus here is OSCORE, but all the same logic applies also to a group OSCORE. So updates since version six. This mostly about two points from Christian Amsys, his review of version four, so thank you to him. Other points were already addressed. And we have also a detailed reply on the core mailing list. But the two points are about Section 2.4, processing of an incoming request, where we have improved significantly presentation of the algorithm on how to handle incoming requests. And we also have content now about guidelines for a proxy adjacent to the origin server, but when it should try to establish or use OS core with origin server. So for the processing of an incoming request, this was a major revision of this algorithm, but only the presentation of the algorithm. The actual logic and the outcome of the algorithm has not changed. It's just presenting it in a better way. And we also did a check to make sure that the functionality has not changed by checking the state diagram in Appendix D and seeing that this change has no impact. It's just explaining things in a better way, in a clearer way. And I mean if you want to see the gist, there's a number of points here. But basically I would recommend checking this in the draft to get a full picture of how it works. So another point was about guidance to the proxy. This is a brand new section 5.1. So the question is when should the proxy use OS core with origin server? How would it know? I mean, for DTLS, you can have Co op S, but for OS core, how would it know? So there's three questions here for the proxy. Number one, does the server want to use OS core between itself and an adjacent proxy? Here, you could actually rely on an SVC param key within SVC resource record about the server. Second question, does the server support use of the multiple nested layers of OSCORE, which it may or may not do? And again, you could rely on an SVC parent key to discover information about this. And the third question is, does the server support the key exchange protocol ad hoc? And to discover this, you can rely on the functionality defined in the app profiles draft. And how to answer these questions zero? That comes from how you answer these questions one, two and three. But one open question here is should we actually define and register two SvcParam keys as mentioned above? That would basically be for discovering support of nested OSCORE and discovering the desire for the server to use OSCORE between itself and an adjacent proxy. So just to show an illustration or figure of this, If you see basically top left, you have the question one, does S wish to use OSCORE between itself and another adjacent proxy? Yes or no? Question two, does S support use for multiple nested OSCORE layers? And then question three, does S support the key exchange protocol ad hoc? I mean, for question three, there's a way to discover this question one and two that would be about this SvcParamKey. And we also have in the draft now a new example of a message exchange in Appendix B6 where we are showing an example with two forward proxies in a chain.
[01:19:06] Marco Tiloca: The codes, the algorithms registry already. The pairwise mode is a different thing. It doesn't have signatures. It it's purely symmetric encryption decryption with pairwise keys established between the two exact group members. The catch is that those keys are established through a pairwise key agreement algorithm that right now is only the field mandate is not quantum resistant. And at the moment, there are no equivalent dropping that you can jump into. And there are no standardized equivalent DH Nike that are quantum resistant. So this draft is proposing a way to make the pairwise mode quantum resistant, not really changing the pairwise mode in itself, but focusing on a simple variation of the derivation step where the pairwise keys are derived. So still based on a key agreement algorithm, but not through the field month, through a post quantum chem. For example, ML chem. And the different variants of ML chem are in fact intended to be registered in the COSE algorithms by a document in COSE in the COSE working group. But, again, it's about the derivation of the pairwise keys that they're not supposed to be used as is, so there is no change whatsoever in the pairwise mode as to the message protection and processing. The nice thing is that Group OSCORE relies on a group manager entity that among other things is already responsible for collecting and distributing the public authentication credentials and public keys of the group members. So we can build on the same advantage and concept that have the group manager responsible also for collecting and distributing information such as the chem public keys and the chem ciphertexts that the group members will need to to exchange in pairs to establish the secrets in in this new way instead of with the fieldman. And as we already do for other services provided by the group manager, details don't really belong to this document. We just need to outline the blueprint of what we need from the group manager and the how can be left for totally different documents that describe a specific realization of group manager. Yeah. On the main thing to really define the revision of the pairwise keys, here you can see compared on top the old current way with the and on the bottom, the the new way. And I highlighted in green what is kept as is, and it's it's almost everything essentially. HKDF, info, send the recipient key, sender and recipient authentication credential, and again, the use of the pairwise keys that follow. The only thing that changed is a component of the IKM sender recipient parameter that is not anymore a shared secret produced out of the but a sender shared secret or a recipient shared secret and established with the CAM. And that's it. So, of course, if you assume that you you have exchange through the group manager, the chem public keys and the chem ciphertext, and you can produce the respective share secrets. You you plug that in and everything that follows is as it is already today. Yeah. Looking at this from the perspective of, say, this endpoint that wants to be sender of a message and needs to have a send a sender share secret to produce a per wire sender key. This endpoint would compute the sender share secret using the chem public key of the other endpoint x, and you'd encapsulate that secret into a chem ciphertext intended to x. And that same secret will be the recipient share secret from the point of view of the x endpoint. This endpoint again instead can compute its recipient share secret using its own private key to take away or encapsulate the share secret from the chem ciphertext that the other endpoint x computed for this endpoint. And the idea is to use a given chem public key to compute only one chem ciphertext only for one other endpoint in the group. Again, with the group manager facilitating the exchange of the input information. Speaking of which and with the idea of giving only a blueprint of operations here like we did for other operations, section four is defining what we need more at a high level for a group manager that supports this. At some point, we need a concrete example, a concrete realization of group manager that does this. And well, we have a realization of group manager based on ACE already. It's also with the RFC editor. And what I presented on in the Ace working group on Monday is a new document that extends that exact group manager and extends its interface to provide also these operations needed here that are surprisingly for uploading the chem public key, fetching chem public keys of others, uploading a chem ciphertext, uploading the chem ciphertext produced by someone else for me. Only principles here detailed for the specific group manager. Now ACE can build a concrete case. What's still really missing to me is what I left as pretty much TBD in section three one where I would like to be to give me a bit more details and guidelines when the particular chem use is exactly ML chem. I think this can largely build on the, yeah, the the parlance, the guidance style that I could see about this in the COSE document registering the COSE algorithms. And I can see that in a similar way, a document in, like, defining the new EDHOC post quantum cyber assist is also building around. So I I plan to take inspiration from there to fill in this section. But besides that, its main contribution, the the document has pretty much all that in mind. So please, comments, reviews are very welcome. Thank you. And someone else that I don't see.
[01:25:45] Christian Amsüss: Just a brief question for clarification. An attack on elliptic cryptography in there would just defeat the source authentication within the group and would reduce this confidentiality from pairwise mode to the group, right? So the group secret that is distributed independently is still protecting the group as a whole, right? Yes. Thank you.
[01:26:12] Marco Tiloca: Very good points for the security considerations. Thank you.
[01:26:17] François: Hello, Francois Navas, IMT-twenty. Thank you, Marco. I'm just to say on the mic, I will gladly review this draft-
[01:26:26] Marco Tiloca: Thank you.
[01:26:27] François: Before next ETF.
[01:26:29] Marco Tiloca: So thanks a lot. Yeah. Don't know if there's anything in the chat. I think the queue is done. Okay. Thank you.
[01:26:48] Karsten Bormann: So the next speaker is Lauren. Yes.
[01:26:54] Laurent Toutain: Hello? Do you hear me?
[01:26:56] Marco Tiloca: Yes. Hi, Lauren. Give me just a second to pick up the right slides and give you control. You have control now.
[01:27:05] Laurent Toutain: Yes. Okay. Thank you. So I wanted to to present you a work we have done with Afnik and Alex and I from IMT Atlantic. So the the goal is to to study how we can put seeds into the DNS, and we think it's something very useful because when you receive a core conf data, you have to to understand intent. The DNS may help to to find the information. So just so what we we have done until now is we talk about pycoreconf and all that stuff. So it means that we can transform a CBOAR representation into a JSON one with ASCII identifier that are very useful. But for doing that, you you need the the seed file or an extended seed files that contains the type of each each list. So we think that we can put that on the the DNS. And why is the DNS? Because it's something that exist and is credible and is used to do this kind of of mapping. So what we we propose in in in the draft is a technical way to transform or to store a seed into the DNS, And we will see after that some administrative delegation from the resolution. So we made the experiment in seed.yt. So yt means for us a young tracker, but it's also an island in France that is Mayotte Island that has this this prefix. And it should go to the ARPA if it works. Of course, it's maybe in the ARPA, not Ayana part. So the technical principle to store the seed into the DNS is to take the full representation. So with all the zero you have on the left, and then you invest the notation and you put points between and you add the postfix at the beginning like seed dot y t. And then this way, we you can get make a query for this seed on on the DNS. So we have so is what I say. So we have a different page, different range. So the first mega range is managed by the IETf. The other one will be managed by other SDOs or people that request for a mega range. And we have also some place that are for private enterprise number. It means so if you have a SNMP file, you can take a number an SNMP value. You can use it to create your own pen. So just an example here. So I will skip this one. So here is an example of what we we can do. So on the top, you have your CBOR structure or CBOR file information that you get in in hexadecimal. And, of course, you know that it's COCON, so you can receiver can start finding the structure. But very quickly, it will find a seed and it will not know what to do with it. So what we have we propose is that once you find a SID you don't know, you query the DNS and you get a pointer to SID files. So right now, the implementation is very, very limited. It means that it's just a pointer where you can upload the file, but it could be a pointer to a young library if if needed. And with this information, then you can transform automatically the binary sequence into JSON sequence with identifier that can be understood. So one one important thing in this transformation is that this serialization may be the result of several young models. For example, we can have a a young data model that define the structures, but we identify inside may belongs to a company. Or you can you can augment also the model with other things. So that's why it's very important to, get all this information to understand the the full structure. So on the bottom, you have the DNS queries that has been done. So the first one goes ask for the seed that we want to solve. And what we propose as a structure is that the answer is the entry point of the model. And once you get the entry points of the model, you get information regarding the module. And, for example, the seed file, but it can be also transformations to an ontology, a total file, or something else that helps to understand. And then you have the query for getting the the files. So looking at the structure, so as we say, IETf may run its web server to its DNS server to manage the files that are the seeds that are on the I t f mega ranch. Other SDOs can do that. And maybe there is a problem when we look at private enterprise numbers because this number are located from long, long time ago. And maybe it's very difficult to get when you have an identifier or name here. Maybe it doesn't belong to the company anymore. And so making the link between these two numbers are maybe complex. So PANSS can be used when you want to use internally a young data model or transform into, say, concoct. But if you want to publish it outside, it may be difficult. So that's why what we we propose is, for example, that registrars can also have their mega range and manage this mega range with their customer that will request some numbers and registrars will allow to maintain the integrity of of the younger of the seed files in the in the model. So that's some open question we have to to solve to continue on this work. So do we need really to allocate seed files that doesn't belong to standards like ATF standards? So can we have manufacturers seed files, but maybe are not a pen number? How we can guarantee the consistency of the resolution? Because when a SID is allocated, it cannot be changed. It can just be deprecated. So we'll guarantee these kind of things. And how to secure all the resolution to get this information. For example, can DNS may be used for for that? So that's some question we wanted to to ask to to the group, and we would like after that with Sandash to go to the DNS groups to to discuss about that.
[01:34:43] Maria: Maria from Bert and coincidentally from running quite a big DNS. I have a bunch of questions regarding using DNS for this. Some of these are like, what's gonna happen when the company goes down and the server goes down because running the DNS takes some money? Then I think that the the command definitely needs some actions. Most specifically, there must be complete procedure how to actually register the NS sets for for every pen. Then one would probably have to make another another procedure to checking whether that person who is actually written with the pen as a contact is actually a contact of the company. Because there are companies where I am quite sure that that person is not longer ever working for this company. And I could go on and on. So I would like to ask you whether you were thinking about these problems and whether you are expecting to resolve them because I see them as quite a big roadblock.
[01:36:00] Laurent Toutain: Yeah. You're you're right. It's so if a company goes down and so what happens? So, normally, the seat cannot be allocated anymore, the young data model still exist. That's why maybe a registrar can maintain this allocation. So and that's something we we have study how the registrar can can do that. But when something is allocated, it's for life. So we so the thing cannot disappear from the Internet. And registrar normally are some very stable structure that are here for to last. For ION action, yes, we we have to see. But that's the first version of the draft, and we have to to give more details in the following one.
[01:36:49] Wojciech Kozaczynski: The RFC ninety five ninety five, that is the sit files, already talks about how the registry for the SDOs should look like if they request the mega range. So I am asking, is is this really needed or what is the relationship with the already existing definition.
[01:37:16] Laurent Toutain: So that's that's also a good point. So we we that's what I said right now, we have a link to to the seat file that is not very very secure in this example. So what we maybe one mapping can be between a number and a namespace. So that will be the minimum. And once you have the namespace, you can go to to query for the model. But we have to look also at scalability. And if we have the database that is stored only on one place, maybe it could be a problem.
[01:37:54] Wojciech Kozaczynski: Okay. Thank you.
[01:37:57] Christian Amsüss: Hello, Christian Amsüss. When you especially when you consider delegation in there, this might easily create a privacy situation because all of a sudden, a person opening a file can reveal that they are opening the file just by dereferencing the thing that eventually hits someone else's DNS server, where there might be a canary thing in there. I have a draft into TRG called dereferenceable identifiers that talks about like, we don't have the solutions either, but it talks about many of the concerns that you have here and and adds a few more. So I'm I hope it helps, but it will also raise a few questions that we'd come to either way.
[01:38:39] Karsten Bormann: Okay. Thank you.
[01:38:43] Maria: Maria, again. Sorry. I found out something more. One of those with the delegation and something going down, the registrar would have to be paid for keeping the registry up. And there is, like, nobody to pay if the company is bankrupt. So the the problem the one problem in this is basically there has to be an infrastructure if we are speaking about DNS, and this is about storing information about some data about probably some product which has been sold, like, ten years ago, twenty years ago. Like, if you look into 2070, we are speaking about fifth almost fifty years of of manufactured things. And these things may be, like, long forgotten companies 15 times bought and dissolved. So I don't see that the delegation is actually gonna work. There may be some central authority if we ask very politely, Iona, that they would register everything for us like they are doing with pens. But I am quite sure that this is much more data that they would actually be willing to research to, you know, to to store. So Oh, yeah. My point is, basically, we should mandate the devices to to carry their own SID files inside them. And because if we don't do this, we we have just a black box
[01:40:12] Laurent Toutain: where Yeah. So just for for the last point, if you do that, it means that you have to send the the SID files when you send the information. And when you have a sensor, maybe it's not it's not very easy on the the SID by itself is a pointer to to the information. Regarding the business model, it's something, of course, we we have to to study and we work with AFNIC on on that. It will be different than the DNS the names whereas we use for the DNS. If you don't pay, you lose your name. Here, it's the the file has to remain. Yes.
[01:40:53] Alexander Pelov: Yes. Thank you, Laurent, and thank you, Maria. Just one point actually to all this discussion. So in the SID, in the in the RFC, actually, we just said that, okay, there are registries, and these registries, you know, they need to be registered with the mega range mega of the mega range registers and and so forth and so forth. And the only thing that I mean, it doesn't speak about any type of interface to these mega range registries. So anyone can just say, well, I I I want I want to request to become mega range register, and, you know, maybe I have some HTTP or HTTPS or or any type kind of of of interface. So this draft here just says, there is the DNS interface to that, and it's very under universally understood. And the the problems with that that you're mentioning about, like, someone needs to be paying for that infrastructure for eternity. That's that's a problem for anyone. Right? We tried at the time, asking Ayanna very politely to do that for us. And then he very politely said, okay, we'll do that for the RFCs of IETf and nothing more. So I think that there was also some generic questions about, you know, how that will will run. So just to say that this document is just saying, there is a DNS interface to these registries. And other than that, there is nothing exceptional for the seed registries. But but these are exactly the question that need to be solved by the the people that would like to expose these kind of of interfaces. Right?
[01:42:29] Marco Tiloca: We have a personal line, think. We can't hear you. You're muted.
[01:42:40] Sandoche Balakrichenan: Can you hear me now?
[01:42:41] Marco Tiloca: Better now.
[01:42:42] Sandoche Balakrichenan: Thanks. Yeah. From one
[01:42:45] Karsten Bormann: of
[01:42:45] Sandoche Balakrichenan: the coauthors with Laurent and Alex. So I do agree with the questions raised by Maria. We I we've at AFNIC, we are also hosting the .fr registry, and, we have seen such, use cases before with RFID and IEEE identifiers. So there are certain things to be narrowed down regarding the business case. But as a registry, we do feel that, this is one potential economic viable point for the registry.
[01:43:24] Marco Tiloca: Escob?
[01:43:25] Esko Dijk: Maybe I'm next. Esko Dijk. Yeah. I think I probably agree with the previous speakers, Alex and Maya. So the IETf could basically host this for their registered modules or seats, I think. But as soon as you go into the the mega range space or all the ranges that are managed by other organizations, then can be a bit difficult because one organization might just keep a record on a piece of paper and and doesn't do anything else. And the people building, like like, clients and servers for that and devices, they would, yeah, just know basically know what each sheet means because it's specified in some document that they have access to. Maybe it's not even a public document. So I think that part is going to be, difficult as soon as it, yeah, moves out of the r t ITF. So that means, yeah, you don't have a a general solution to to look up these hits. Maybe for the ITF standardized ones, it could work, but not not generally. And certainly not for private ones because we don't have any requirements for the companies to publish anything about it or expose any interface by design. So it's going to be difficult to make it generally available, I think. And then you get, yeah, kind of a part a solution that covers a part of the whole sit space, and then it might not get used because it's not covering 100%. I was also wondering about the exact use case for this. It's also not not fully clear yet from the presentation, but maybe that I should read the draft for that. Thanks.
[01:45:12] Laurent Toutain: Okay. Yeah. It's the goal is that to when you ask for for example, you have a fetch and you receive your information, so you have to understand everything. And so you need to get all the understand all the seed that are included in into. And they can come from different spaces.
[01:45:36] Esko Dijk: Could could be already in the in with built in the software that basically requests the data from the devices. Right? So it should be based on some specification that might
[01:45:46] Laurent Toutain: But when the device is sent so we had a demo at a cat on where we saw a weather station. So we use a generic representation of the information, and then we add some identifier that were dedicated to some specific measurement. And so when you define define the global structure, it can be viewed from ATF. But the manufacturer may add his own sensors, his own counters, and so you he has also to publish on services this kind of measurement. And and so here, he needs to to publish a SID. We can discuss that. Thanks.
[01:46:27] Marco Tiloca: Thank you. Thanks, Ola.
[01:46:29] Laurent Toutain: Thank you.
[01:46:31] Marco Tiloca: And next is Lindsay. Start the dance again. Give me a second to open the slides.
[01:46:50] Linzhou: Hello everyone. This is Linzhou from Beijing Zhongguan Chen Lab at Chinese research institution in China. Yeah. So this draft is about the code extensions for asynchronous task resources. And then the main goal of this draft is to provide a common way to create, control, and monitor the long running tasks in CoAP. So let's start it with the problem statement, why CoAP needs asynchronous task contract. CoAP request yearly returns the immediately result after the application method has been skewed in, but some operations will continue to run after the request is accepted. For example, the firmware installation, the incident diagnostics, and any other complex tasks. Nowadays, the applications are usually defined by themselves. They define the ID jobs or the job IDs. Sorry. The state name and the control method by themselves. So the pattern we can see that the pattern is common, but the contract is application specific now so that the which makes the client is hard to manage the asynchronous task in a common way. Here is the deployment deployment made by NSFocus, a cybersecurity company in China. And in this project, we customize the task list according to requirements to for task assignment and stipulate the task should be skewed in sequence. The task execution status is observed using private domain definitions. In this project, we found that by monitoring the task, we can diff we we can locate the fault quickly, and also we can know the status the state of every step. It's very useful, but we only can understand this cabinet open information under the customized definition. So that's why we proposed this draft. This document defines a co framework for representing asynchronous and a long running operations as addressable task resources. In this draft, we define the lifecycle including common status and terminal retention and also the interaction interactions including creation, observation, and others. And we want to use the call link format to do the this task discovery. And, also, we propose a request model including the resource content and also the task controls. So in this job, we will also reuse some of the existing mechanism. Here's the task class left cycle we define. First firstly, all the task is start with the state pending. And after that, we have active operation, which means the operation is in progress. And, obviously, we have complete completed. And there are also some status a state to describe the incidents like the failed failed to complete after the execution started, and we have aborted state. The plan can cancel the task before completion. And, also, we have a rejected rejected state. The task results has been created, but the dynamic approval before execution failed. For example, the memory where the capacity is not enough for the task, it will be go to the task will go to rejected state. And also the final stage task should be kept for a sufficient period of time for the client to raid. Here is the task request we define. We use content format six two. We have four parts four parts of payload. The first part is about the resource content format. It register the COP content format for part two. And in the part two, we have the resource representation. This part describe what the task should do, including the target resources, operation other, execute the profile, and the others. In the third part, we have the task content format similar like part one. And in part four, we have task representation. This part described how the task should be executed, including the execution mode and profile specific task parameters. Nowadays, have right now, we have two kinds of execution mode. One is atomic guarantee nothing or all. And another is a screen show. It means the task should be executed in order and it should can it can report the sub results. And here is the workflow for task creation and control. First, the task institute here can make a pause request to create a task before the create before creates, the executor should do some validate, check the operation and the execution control can be supported and do the also the also the reason. After the created, the new task resource UI is to return using location pass. And then they can the client can do the observe, can re register and observe relationship on the task resource. Here is the detail of the task status. We have the task state, obviously, and the progress percentage and estimated seconds to complete, and also the diagnostic text, and also the sub results. Except for the complete one, we also have the lightweight one on the below of the this page. So here is the open issues because it's a new work here. So we welcome feedback. Is this we have some issues here. Is this a useful common abstract for CoAP? Are there any other existing deployments or models we should align with or other exit exit existing code mechanism that we should use in this draft. And, also, are the life cycle status is clear right now? So that's that's my question, and that's all. Any questions or comments?
[01:53:52] Christian Amsüss: Hello, again, and sorry for being so much on the mic. So the pattern does look familiar. What I'm wondering is like, have you At what level are you What are you describing your tasks? Because some of those things look familiar from things like uploading really concrete firmware items that really spawn a process in a real time operating system, where then the introspection would really be like basically get me a back trace of where that task is currently pending. So at which levels? Do you or do you use this on a level of uploading assembly or uploading tasks in a more high level way where percentage of completion then makes more sense than if really binary code? Or is this flexible with respect to that?
[01:54:44] Linzhou: I think it's for service level.
[01:54:47] Christian Amsüss: Sorry, it's for?
[01:54:48] Linzhou: Service level. We have some service over the code. And for the service, we can use this task management.
[01:54:56] Christian Amsüss: I'd hope that it could be generalized, if, of course, if there are show stoppers, they're not. But if sounds sounds to me like this is a useful pattern, especially if it can be generalized.
[01:55:08] Linzhou: Maybe we can propose some use case to clarify that.
[01:55:18] Karsten Bormann: Yes. Just a quick comment, procedural comment on this. You see this is a -one draft. So you showed us the first version of the draft last week, and we had a lot of comments and they are all in there, very satisfactory. So that that's really great work. And I also read that it is it is a good idea to write this up. I mean, it's not a standard in in any way, but it's a good description of what you do when you need this kind of information. The the classical case, of course, always was a coffee machine where you have an action to start making a coffee, and then you want to be able to influence this action because the cup overflows or something like that. And so this seems pretty familiar. Okay. Thank you.
[01:56:09] Linzhou: Many thanks to, yes, Marco, Jamie's, and feedback for this draft so that we can version one here today.
[01:56:17] Marco Tiloca: The draft is already considering access control, pointing to ways, pointing that the permissions to access the real application resource should be one thing and the permissions to access the task resource are another thing. Then we need to find a way to practically make it happen. And I think AIF can be an option to explore in the context of ACE, for example, we did it before in other works. Thank
[01:56:41] Karsten Bormann: you. Okay. So this is another draft that that really is in the informational space. We have been writing up CoAP interactions for, like, fifteen years now, and we're having we have been doing this in a thousand ways all all different. So there are things like UIs in there that are either notated as a number of UI path options or as a complete UI. We have to distinguish header and payload request versus response. We have to put the method code somewhere and the response code. And everybody who does this invents a new variant of that. And, well, that's a welcome variation, except some of us actually have to write CI scripts. And, extracting, information from from such a form of, presentation is is, difficult. And we are seeing a lot of documents out there that that just don't survive CI. So recently, twin 99, 42, and 43 were published. I cared about 99, 40 '2, and now I will write the rater report for '43. Okay. So let's let's try to come up with something that that solves, like, 80% of the situation. That's clear. Sometimes you really have to focus on demonstrating something that is a bit outside the the normal situation. But normally, what we really want is essentially the request line or response code, like in an HTTP message. We want to have options, but we don't want to have all the these little options that create a UI. We can put those into a single composed UI. We probably have to to tell the content format and then the actual payload if that that that is given. And, of course, there's also need to write something about what particular kind of payload is being used there. So the media type may be useful there. But if you actually need to address a validator and then say this is this and not this, then this also needs to be indicated somewhere. The payload, of course, depends on which format it is in. So it's CDN, CTN, whatever that will be called for CBOE. It's obviously JSON for for JSON. Call link format, hex, RFC eighty seven ten application multi card multi part call, we have to cover all these examples. And we probably simply do a blank line as if this were HTTP. So, yeah, nothing is surprising about what you are seeing here. So we immediately understand what's going on. And I think that should be the objective that you can use this even without having read the the RFC. So yeah. Why why does it matter? Because we want to to check our specifications. I just found a a weird place where I had written Boolean instead of bool. Yeah. Somebody is trying to use this code and running into a problem that that they don't understand. That's bad. But the the point is not to to create a big gating point here, but we just want to make sure that the CI will tell you when you have a problem so you you can fix that throughout specifications, little guide web pages, wikis, teaching material, and so on. So we have a few questions that we won't really have much time to discuss anymore, but that I would like to put anyway. So we are right now talking about a way to notate application specifications. So ones where we don't reach into block headers or things like that. It is possible with the current proposal, but it's really focusing on application specifications. So if you have a specific example in mind where you want more from the notation, we would like to know. We would like to know if the current Internet draft is clear enough, and we would be happy if you actually could apply it to examples in your documents so you will immediately know whether it works or not. And once a few people have done that and the next version of this document is out, we will start putting this into tools like kramdown-rfc- so that that much of the CI will actually just happen without a lot of things going on. So Rumble and RFC already takes JSON because that's trivial, but we want to do it at this level as well. And we sure want to do it for HTTP at some point. And then when when we have a little bit of experience with that and and people generally like what they are seeing, we might want to adopt this as a document and publish it ultimately as information. Any comment on that? Oh, I should have said on the first slide that Jaime did all the work. I saw a lot of notes.
[02:02:51] Participant: Okay. So I think that's a really good idea to kind of formalize this in some ways so that all the different variations out there get like a common version. It may also be useful for like some diagnostic tools. I don't know, Wireshark or something like that, but they would you adopt this? One question I have now, if you we we talked about before about the nontraditional responses where you maybe have like several responses. Do you have any thought about how you would represent that? Like, maybe having multiple responses in an observed kind of situation?
[02:03:32] Karsten Bormann: Good question.
[02:03:34] Participant: So, like, the what what comes to my mind is maybe have for risk for request some kind of arrow pointing outwards and response some arrow pointing inwards, you have several responses. You kind of can distinguish.
[02:03:46] Karsten Bormann: We already can distinguish request from responses by the method code. So request has a method code, response is a response code. And so that's a very simple, syntactic way to
[02:03:58] Marco Tiloca: to change it.
[02:04:00] Karsten Bormann: The the the easy answer to your questions, we've just sent one responses, and you're done.
[02:04:17] Marco Tiloca: I locked the queue after, Martine. We are already out time. Please be quick.
[02:04:22] Christian Amsüss: I'm very quick. This makes a lot of sense also as output for actual CoAP clients. Like, AIO CoAP client currently just puts up puts out, like, a made up diagnostic notation, and I should just use this.
[02:04:36] Participant: I will definitely have a look at this document. Just a question without looking at it before. Does this also support like we did in 9953 that the payload is displayed in two different formats?
[02:04:51] Karsten Bormann: It's displayed in two different
[02:04:52] Participant: In two different formats. For example, in 09/09/1953, had hexadecimal and then a human readable form.
[02:04:59] Karsten Bormann: That's actually a very good good comment. Okay. CDN is learning to do that. And so we probably want to see the other face situation different.
[02:05:12] Marco Tiloca: There were also two more thumbs ups in the room from asking the white thing. Count the third one as an individual.
[02:05:19] Karsten Bormann: So please
[02:05:22] Marco Tiloca: Please review.
[02:05:23] Karsten Bormann: On the item three on this page.
[02:05:34] Marco Tiloca: And please follow-up on the list. I think we are at the end of the meeting. Thanks a lot to the presenters, the mere takers. Many thanks. Thank you all for the great work and contributions. See you online.