IETF Meeting Minutes

Markdown Version

Session Date/Time: 17 Jun 2026 14:00

Marco Tiloca: Could anyone hear Laurent?

Esko Dijk: I couldn't.

Marco Tiloca: Right. As usual we start at four past or so. So we are into the sound check mode now.

Laurent Toutain: Hi, hi.

Laurent Toutain: Hello, do you hear me now?

Marco Tiloca: Hi Laurent. Now it works. Thank you.

Laurent Toutain: Okay, good.

Marco Tiloca: And Vojtěch, I could hear you, you have a very boosted mic.

Vojtěch Vilímek: For the love of game.

Esko Dijk: Okay, maybe we'll check my mic as well then, Marco.

Marco Tiloca: Perfect. Hi Esko.

Esko Dijk: Hi. Thanks.

Vojtěch Vilímek: Am I too loud?

Marco Tiloca: It's good now, I think.

Vojtěch Vilímek: Nice. Thank you.

Marco Tiloca: Hello. Okay, it's four past, so let's start. Welcome everyone, this is an interim of the CoRE Working Group. I'm Marco, my co-chair is... Hi, Jaime and Carsten. And this is an official IETF meeting, so the Note Well applies. Get familiar with it if you're not already. It's about disclosing your personal knowledge of IPR or refraining from participating in the technical discussion, and it's even more about our Code of Conduct, so please be nice and professional with one another.

And a piece of advertisement: we could notice on the hackathon mailing list an advertised hackathon project for Vienna from some usual suspects. Almost all of them are here, I think. Yeah, trying to summarize from the project description: the goal is to work on completing and standardizing CBOR extension support for the YANG-to-CBOR toolchain. You can find more information on a thread on the mailing list and in the wiki collecting the hackathon projects for Vienna. This is good, hope to see more. So thank you to the champions.

The agenda for today has three items. The first one was proposed by Laurent some time ago, related to a cross-COSE-CBOR document about private SID translation for CORECONF. Vojtěch also proposed some slides related to CORECONF a few hours ago, and then I expect to be the longest slot today, one proposed by Esko on the pubsub document that passed working group last call, and we still have some points to triple check.

Any more items or any agenda bashing, any reordering? This is just following the original order plus Vojtěch in the middle just to stay in the CORECONF ballpark.

Esko Dijk: Joi, just to check what people see on the screen. So I see hackathon projects.

Marco Tiloca: Yeah, it's still there. I'll take it out now.

Esko Dijk: Okay, thanks.

Marco Tiloca: Okay, if there is no agenda bashing, the first one is Laurent, then. I can take and give control of the slides, one second. There you go.

Laurent Toutain: Perfect. Okay, hello. So thank you for allowing me to present this. So the idea is something that looks strange: it's the private SID translation, but I will explain why I think it's very important, especially using CORECONF with SCHC to manage well the rule. So the draft has been published one week ago.

So the idea is the following: is to reduce the transmission size during serialization. So the goal is not to change the SID allocation, but to be able to transmit something that is smaller on the link. So here, for example, I represent a SCHC rule where you have the number, you have so in orange, you have the official SCHC number, and in yellow, you have the delta encoded SID that you find in every in every keys.

So we can think that this representation with delta is optimal, but in fact, in some YANG data model, you have the identity ref, and the identity ref refers to a SID, and here, this SID is coded normally, so integrally. And so here, it takes three bytes to code these values. So this is one one goal. So it's in the data model itself. And also, during queries, you may have also the same thing where you see SIDs without any delta encoding, for example, in a fetch. So here is a fetch from the CORECONF M2M data model I've submitted in the CoAP-to-CoAP research group.

So here you see that you have two SIDs: the first one is what we are looking for, and the second one is a key in the YANG data model, and they are not delta encoded, and if you make several fetches one after the other, you repeat these numbers. And of course, when the number is high, it takes a lot of time and space, and the answer can be just an integer, so the ratio between the query and the value you are sending is very, very bad.

So that's why we propose this to have an encoding on the wire that makes that you can transform or translate the SID space into something smaller, using the property of CBOR that shorter numbers have shorter length in the representation. So this is just for transmission, and you can so the processing of information may remain the same. So I saw the comment on the mailing list this afternoon that says that applications may use these compressed SID spaces, but in fact, it's maybe an optimization, but it can be risky, for example, if you have just these compressed numbers, they can be they are not non-ambiguous, and it can lead to some problems. But anyways, an application may do it if it feels free to, safe to do it.

So the goal, for example, in a SCHC rule is to have a compression rule for the payload where we will say that this payload, we know it's a CORECONF representation, a CBOR representation, so we can apply on it SID translation. And since it's something symmetric, on the other side, you do SID decompression. So it's quite important for the data plane, where if we are sending YANG serialization using CBOR, we want to compress it. But it's very, very important for the management, because in SCHC, the rules are represented in CORECONF or in YANG, and we have the CORECONF serialization. And so if we do this kind of things, we can gain a lot of space on what we are sending.

So the main idea of this translation is that here, you this axis represents all the SID values that are officially can be officially allocated from 0 to 2^64. And so when you have a YANG data model, it has an entry point, and then all the SIDs follow this entry point. So what we do for the translation, in fact, it's more a rotation or a symmetry, is that we go and use the negative space, which I don't think has been allocated for SIDs. And what we do, we do a very simple transformation: we take the entry point and we subtract the official SID number. So this way, we have negative values that can be used, and it's almost the same position. And of course, at the reception, you do the opposite operation, and this way, we can have smaller numbers, because negative numbers, if they are close to 0, are very small, and so we gain in space.

And what we propose also in the draft is that we can apply this transformation to several YANG data models, and in that case, we had also the notion of offset, that can say, "Okay, now I do the same translation, but I have a translation of offset value to be after the first one."

So if we look at numbers, so here we have the same SCHC rules we had at the beginning. So the official, the normal one is about 4,000 bytes. And when we do the SID translation, we are about 3,000 bytes. So we have a gain of 1,000 bytes for or 25, almost 25% in reduction in space, which is quite important for SCHC.

And so the point is that this proposal reduces the size of CORECONF serialization, so it's very important on constrained networks, and especially if the model is using intensively identity ref. And it's something that is I think will become more and more common in the Internet of Things, because it's a way to have unique identifiers in what we are sending. So this is for the data representation. It's also a way, as I say, to reduce the query size when you send a request, for example, we are working on some networks, on underwater networks, where we have a very few bytes, very, very limited bandwidth, and if we can reduce the size of what we are sending, a query we are sending, it's also a big gain.

And so this is so IETF is very lucky because it has the first mega range, so it can have very small representation. But other SDOs will have other mega ranges where we have no small values. So I think it can be also a good opportunity for other SDOs. For example, ETSI is working on vehicle communication, and when they want to exchange data, if they want to use CORECONF to do that, they don't have this compact representation. So this is true for this space, and it's also much more true for the PEN values that are much, much bigger.

So to do that, you cannot do the translation just by reducing the entry point from every integer you have in the CBOR representation. So you have to know where are allocated the identity ref, and this is possible with the extended SID files that allows us to identify the identity ref for the payload, and also the keys and where we have identity ref in keys, to do the same reductions. So that's why I put this draft more in the CBOR area than in the SCHC working group: is that we have to request negative values for SIDs. So if I have well seen in the IANA repository, for the moment, negative values are not present in the SID registry, and what I propose in the draft is to use the first thousand, like the one allocated to IETF for positive numbers.

And that's all for that. So just one point: is that I preferred to have a very simple translation, just subtraction. But it means that if you want to have something optimal, you have to reorganize your SIDs in a good way. So it's what I have done for SCHC: is that the first 24 values are for the very, very frequent identity ref you are using. Then, the frequent one can be in the first 2-byte range. And after that, you can have your data that are delta encoded. So if you use a value close to 255, your first key is on 2 bits, and then you have deltas, and deltas can also be very small, and at the end, you put the least frequent identity.

So that's the proposal. I wanted to have feedbacks, and if you think it's something that can be is possible to do.

Marco Tiloca: Thank you, Laurent. Carsten.

Carsten Bormann: Yeah, thank you for this proposal, Laurent. So, let me not discuss the proposal at the moment, but talk about the context of this. So when we try to find out what is a good way to have a compact representation of places in the model, in a general sense, we came up with this SID concept, and people didn't like the SID concept because the numbers were likely going to be large. So we came up with the delta encoding to reduce the size. So this is what is described in 9254. And at that point, we stopped because the general perception was this was good enough. And I actually do believe that this is going to be good enough for the majority of applications of YANG-CBOR.

But then, the pesky SCHC people came in and said, "No, we want to save more bytes." And that's where we are. So how do we get the context information that is useful for further deflating the redundancy in the encoded YANG data item? And this is really a very interesting way to do this. Of course, we need to, as always in header compression, we need to make sure that the encoding party and the decoding party agree on the context. And some of that context is going to be in the SID extension part of the SID file, as far as I understand this proposal.

Laurent Toutain: Yes.

Carsten Bormann: But I'm not entirely sure I understand where the entry point comes from.

Laurent Toutain: Entry point is the value that you have at the beginning of the SID files that tell you when it starts.

Carsten Bormann: Okay, so the decoder takes the value, if you look at your slide 2, I think. This is 2,700. Oh, that was good enough.

Laurent Toutain: Yeah, okay, this one, yeah.

Carsten Bormann: Yeah.

Laurent Toutain: So we have the comparison.

Carsten Bormann: Yeah, so there is essentially this number.

Laurent Toutain: Yes, so the entry point for SCHC is 2,550. So the first values are used by identity ref, and then we have the position of the container that contains the rules, that is at 2,700.

Carsten Bormann: Yeah, this is going to be quite confusing without additional graphics. But so you're saying the entry point is 2,550 in this example, right? How do you know that?

Laurent Toutain: It's in the SID file.

Carsten Bormann: This is allocated range for SCHC. Ah, so we are defining special media types for SCHC that say, "Oh, you use this kind of concise representation"?

Laurent Toutain: No, it's in the rule that you say that. So let me here, so I simplify things compared to what you have in a draft. So in the draft, you have a CDA, and that say: do SID translation, and one parameter is the extended SID file, and the other parameter is the offset that by default is 0.

Carsten Bormann: So offset is the same thing as entry point, or?

Laurent Toutain: Offset is the thing that if so, we can simplify and say we have only one rule, and we do only one translation like this one. But if we want to apply it because, for example, we can expect that you extend a YANG data model with another YANG data model. For example, you can have the YANG data model that is something official by the IETF, and then a company say, "Okay, I need this, and so I extend this YANG data model with my own SIDs," and these SIDs, for example, come from the PEN number, because it's what we have.

Carsten Bormann: Yep.

Laurent Toutain: In that case, you have the purple part that is the official SID, and the orange is the PEN part, and so you can move them together in the compressed part.

Carsten Bormann: So the context essentially tells you the ranges that will be mirrored to the left side of the zero.

Laurent Toutain: Yeah.

Carsten Bormann: So this is this is the context information I was trying to find here. Okay.

Laurent Toutain: So the context needs the SID files, because we need to know which value we translate. We don't do it blindly and say, "Okay, each integer has to be subtracted by this." We say, "Okay, this integer is really an integer in the YANG data model." Just to take an example here, for example, you see this one here is the position. So I cannot do the subtraction on the 1, for example, in the column where you have 8, I cannot make a translation, because if I do a subtraction here, I will have a larger value in the negative place. So what we want really to translate is only the identity ref, and that's the SID extension that gives that.

Carsten Bormann: So the SID extension tells me the type of thing there, and from the type, I derive whether this is a SID, I have to apply this piece of work, or whether I have to leave it alone.

Laurent Toutain: Yeah. Same thing in this example, you have the first, if you have a fetch here, the first value is a SID, so that's well known, and the other are keys. So you will need also the extension to say this key, the second one, so 100, is an identity ref, so I do the transformation, and this 0 is an integer, so I don't do the translation.

Carsten Bormann: Okay, so the essential thing is that both sides have the same SID file, which identifies the types in the YANG. I mean, they could work from the information in the YANG module, but we consider that to be too much for a constrained implementation, right?

Laurent Toutain: Yes and no. It's then, I will say, as you say in the mailing list, that's an implementation issue. You can simplify a lot this from this SID file. You can maybe right now, we have a JSON representation of the SID file. I think we can go to something more compact. But it's something we have not discussed right now.

Carsten Bormann: Yeah, but whether the representation is compact is different question from whether the information set that is in there is complicated. And of course, the YANG module has a lot more information in it than we actually need to apply this concise representation, right?

Laurent Toutain: Yeah, but it's yeah, so you have to make the difference between the YANG that is the full information and it's very, very rich. You have the SID that is very, very small because you have just the translation, and what we trying to push with SID extension is just to add a type, but is not used as a YANG to make to validate a model, but to help the transformation.

Carsten Bormann: But theoretically, I could get this information out of the YANG module in a deterministic way.

Laurent Toutain: Yeah.

Carsten Bormann: Yes, that's true. So I think that's pretty important to distinguish. It's information that is extracted from the YANG module, which is different from the way we assign SIDs. That's a deliberate act of giving a number to something. And you can do this in different ways, so this is not deterministic.

Laurent Toutain: Yeah.

Carsten Bormann: But extracting the type information from the YANG module is deterministic, and therefore, an implementation that only has the YANG module could play.

Laurent Toutain: Yep.

Carsten Bormann: But also, an implementation that has the SID extension information could play.

Laurent Toutain: Yeah, you can have a regular SID and the YANG module just on side.

Carsten Bormann: Good. Okay, so the context that is established is on one hand, the information whether a particular place in the tree is an identity ref or not.

Laurent Toutain: Yeah.

Carsten Bormann: And the information, which ranges from the normal SID space are mapped into the negative SID space.

Laurent Toutain: Yeah, if you you don't do offset, you just need the SID with extension or the SID normal SID plus YANG. If you want to do offset, you have to add the offset.

Carsten Bormann: Yeah, but to add anything, to compute anything, I need to know whether the thing is an identity ref or not.

Laurent Toutain: Here, yeah, but here, it's, I will say, it's the SCHC business. It's to have to represent that inside the YANG data model of the rule, to say, "Okay, I have this CDA, so this CDA is composed of a file and an integer," for example. And it's and then, normally, the SID file will be distributed, and will never will be the same. So there is no change that you expect in the in the SID file. So this is also the problem of repository and all that that thing. And but normally, SCHC, the goal is that the rules are identical on both sides, so they agree on this context.

Carsten Bormann: Sure. So Christian has a question that he probably wants to put, or somebody has locked the queue. Okay.

Carsten Bormann: Yeah, so I think the answer to Christian's question is, you need some way to transport this context. And so this only applies to SCHC or similar ways to transport the context. That's why I'm talking about the context all the time, I'm sorry.

Laurent Toutain: So yeah, so yes, you so for this proposal is right now for SCHC, and it can be extend, for example, I don't know, if ETSI decide to use that in his own with his own protocol, it's possible. So it's just that both ends needs to to do the translation.

Carsten Bormann: Yeah, so I'll shut up because there are two more people in the queue.

Marco Tiloca: Christian was in the queue when I locked it, so do you want to say what you wrote in the chat, Christian, or something more?

Christian Amsüss: Ah, yeah, I dropped out of the queue before because I thought it was not too relevant. Yeah, I'd appreciate if things that are done to make things smaller don't rely on having some SCHC header outside. So if we do this and we find a way to express it in a way that works even without SCHC, and then SCHC can say, "Okay, this kind of five bytes that, for example, are a tag around that CBOR item, we compress away." I think that's more useful than if it's the SCHC rule says how to do it anyway, so we don't need to explicitly do it.

Laurent Toutain: Yes, in fact, when I say SCHC, it's in pySCHC, so in an experimental version of pySCHC. And so it's a function to to do the translation. So and SCHC will call it.

Christian Amsüss: Yeah, but that's that's the implementation, not the way where it could be transported if no SCHC is in play.

Laurent Toutain: I I you can do it without SCHC, you just need to to follow this very simple algorithm on both sides. The only complex thing is that you have to identify if a value is an identity identity ref or not.

Christian Amsüss: Okay, but maybe I have to read the full draft. But I think it's like that context information still should be carriable outside of SCHC.

Laurent Toutain: Yeah.

Laurent Toutain: Yeah, yeah, yeah, we will use it in SCHC, but it's not mandatory to use SCHC.

Christian Amsüss: Right, yes, so I also didn't completely catch the relation to SCHC except that this method makes your payload shorter, so whatever you compress in SCHC will also get shorter naturally. But okay, let's not let's not go into that. So I wanted to look at slide 7 actually. One thing that confused me in the discussion was that we talk about SID files, we talk about extended SID files and both sides need to have it, and I think that what both sides need to have is a sort of a configuration that's very private to these two sides, right? Because one in one application, you might have purple being well, some YANG module 1 and orange being YANG module 2, and in other side or implementation or system, might have completely different YANG modules that they want to compress, 3 and 4, for example. So in that case, they will both want to map to the same negative space. So it's really highly private you'd say how the mapping is done. So it sounds like it's not something that's similar to SID file because that defines numbers that everyone needs to use, and now we have something that defines a number that only you and your peer need to use for communication. But other people might use totally different numbers there. Or standards like ETSI could use specific numbers if they only use these two colored modules, for example. But somebody else who uses three modules needs new numbers to map to the negative space. So should we use different terminology for that then? I think it's a bit confusing to call them SID files or extended SID files.

Laurent Toutain: Okay, so you're right. So here, in fact, in this slide, you have all the formula for translation. So entry point is something that is in so in the SID file, but it's something that is a definition of is what has been assigned to YANG data model, and then the SID is the current value, so it's if you know that this SID is an identity ref, so you apply the formula.

Christian Amsüss: So basically you are proposing that the context, the parameters are established based on the SCHC protocol, or how I can get the parameters for the transformation?

Laurent Toutain: So the param so by default, the transformation can be if you have a SID file, the transformation is direct. And the opposite also. So you what will carry a SID rule is just the fact that you you are applying this to a certain part of you can send plenty of things on the on the link, so let me find it here. So it's what is written in the middle, so you can use regular SID space, so if you have not configured things to do transformation, so here you don't do transformation, you send the regular values. And if you have defined things to be compressed, then you send the compressed things. So and it can be the vector can be SCHC or can be on any other protocol if needed.

Christian Amsüss: Yes, okay. I think that the way the parameters are established by both parties should be part of the document, because I think it is the hardest part of of all of this.

Laurent Toutain: Okay. So my question is do you think it's possible to get negative values?

Vojtěch Vilímek: Yes, it is. It is quite a low-hanging fruit. But I'm still not sure if, basically, as I read the text, I didn't find the way how the parameters for each model is found by the parties. You say, "If the parameters are established, you can send the negative SIDs which are smaller," but I'm asking how you are establishing the parameters.

Laurent Toutain: Okay. So what I say is that in fact we need two drafts: one for the translation by itself, and another one that will go to the SCHC working group to see how to use it with SCHC, it will be clearer.

Vojtěch Vilímek: So, I would say that I like the negative SIDs, but I don't think this this transformation is quite simple, but I think it would be even better if we could just pick and choose what negative SIDs are mapped to what real SIDs. And I think it could be solved in a way that we take a SID file, change it so that it permits negative SIDs, and then you can list the things you need to have efficient encoding for. And I think this way we could then use the SID file as part of the YANG library and have the the whole thing discoverable for CORECONF, or have it some kind of extension for CORECONF if we don't come to the conclusion that it shouldn't it should be a part of the CORECONF itself. The question is if it should be extension or if it should be the part of CORECONF that is mandatory. But I think not just linear transformation for some parts of the space, but direct one-to-one mapping would be better.

Laurent Toutain: Okay. So in that case, it means that we the only thing you cannot guess is the offset, because it really depends of your context, so of your environment, what you are really doing. So it can be viewed as an external parameter. Or we remove the offset and we focus on on a single model.

Vojtěch Vilímek: Okay, I'm lost, so I'll let someone else have a question. You are free to ask.

Marco Tiloca: Thank you. And probably most of the points raised on the list were just covered, but yeah, there's also a thread there, Laurent, if you want to continue replying to Vojtěch and Carsten so far, I think.

Laurent Toutain: Okay, thank you.

Marco Tiloca: Thank you for bringing this. So next is Vojtěch, I think, we have a few slides. So you have control now.

Vojtěch Vilímek: So let us go through the slides quickly. This is an example from CORECONF. It is a full GET message, which is simple variant of the fetch because you always transfer the whole data store. And my proposition, which is an alternative to the negative SID files, is that we can just encode the root SID number as a context in the message. So and this would not be taken only for the root nodes, but also for the other things that are identified by absolute SIDs, like the identities. We can go back and forth to see the difference. This is not a good example because the numbers are largely apart from each other, and so the deltas are not that much better. Sorry. I also, while we discussed this today, it came to my mind that we could put the number that shifts the whole root as a CoAP option, so it wouldn't be a part of the CoAP payload, and therefore, it would work also for the CBOR sequences better. But this is basically an alternative for saving bytes in the message that is not negative SID. Have anyone any question?

Laurent Toutain: Yes, Vojtěch. If you extend one, augment one model with another one, is it you have confusion or it's because you have deltas, and know which SID range you are using.

Vojtěch Vilímek: If you have two modules, they must have a non-overlapping SID ranges, and so one would naturally have small deltas, and the other would have a bigger deltas. So it largely depends on the size of the YANG modules.

Vojtěch Vilímek: Yes, okay, I think that the way the parameters are established by both parties should be part of the document, because I think it is the hardest part of of all of this.

Vojtěch Vilímek: Okay, I'm lost, so I'll let someone else have a question. You are free to ask.

Marco Tiloca: Okay, thanks again, and hopefully we should have a new revision capturing these these last things before moving on.

Laurent Toutain: Okay, thank you.

Marco Tiloca: Thank you for bringing this. So next is Vojtěch, I think, we have a few slides. So you have control now.

Laurent Toutain: Yes, Vojtěch. If you extend one, augment one model with another one, is it you have confusion or it's because you have deltas, and know which SID range you are using.

Vojtěch Vilímek: Okay, thank you.

Marco Tiloca: Okay, thanks again. If we close this cluster of topics we move to the next and last agenda item for today: the open points on pubsub. Esko, I don't think you have slides, but I guess you just wanted to go through your and Jaime's mail.

Esko Dijk: Yeah, sure. Can I share the screen?

Marco Tiloca: There's an additional resource actually. It's in the minutes and I put it in the chat now. There was a commit yesterday from Jaime on the main branch, addressing some of the points as mentioned in his mail. The commit itself wasn't mentioned, so we may want to have a look at that here and there.

Esko Dijk: Okay, I asked for the screen share so I'm not sure if it already is up or if I can see that. Okay, this is coming up. Yeah, that works. So maybe just start with a bit of context here. So I was doing the kind of checkpoint for the shepherd's review and write-up, and there is this point about working group last call consensus check. And then I looked into the messages and found that not all the remarks or questions have been addressed yet. So that's the mail here that I sent on Monday with basically two quoting two threads. So both were from Christian with like open questions and I think for all the items, there have been improvements made on the draft. But part of it is also not yet addressed, and I could not find any answers to why not do this improvement or change. And then I think it would be good to check for the consensus on that, so what do we think that needs to happen. These are ten points and Jaime already made a reply, I think, to these points. So what we could do is maybe I don't know if Christian already had a chance to go through these these items because I think because you raised these points, you might have some yeah, idea of whether you think that needs more to be addressed of your review or whether you think it's okay now.

Christian Amsüss: I think it's largely okay. There is one item where I think that the kind of where the resolution technically allows the things that I think should be allowed, but practically but it's a bit of questionable phrasing and I've just put up a pull request and linked it in the also in the notes. On on that, it's on issue 2. And something similar on issue 3. So everything else, from my point of view, is good enough.

Esko Dijk: Okay, so you said you have made a PR and that relates to 2 and 3 here. The ones that I'm showing on screen now. So this is...

Christian Amsüss: Yeah, the first one.

Esko Dijk: Yeah, so this one was about max subscribers. Yeah, so so that, I also provided my comment to that. So it seemed like a perfectly okay way to to define it. So you have a pubsub topic and you allow the creator of the topic to reserve some set of resources for that, so that you you ask maybe for for 200 subscribers and you get back 200 and then the broker decide make the final say what number to assign.

Christian Amsüss: I don't think that's what the that's what the document says. It says um, it just says limits how many are allowed. It It does not say that they necessarily need to be pre-allocated resources for this and that many subscribers.

Esko Dijk: Ah, okay, mm-hmm. So that would limit its usefulness in in that case. So you just put a maximum without even knowing if you can even get two subscribers, for example.

Christian Amsüss: It's I think it's like it's like putting a quota on a user on a file system, um, but like what you actually want to manage is um, but that doesn't tell you whether um, for all the users that are there, are there's really enough disk space for for everyone of them to fill to fill this up. And when that gets full, um, kind of that the quota itself that is put might not necessarily be helpful. Um, yeah.

Esko Dijk: Yeah, but okay, I think it's maybe a matter of interpretation then, because I clearly interpreted this differently, because if if it's just a maximum and yeah, then there might not even be a reason for the broker to actually modify the request, so it can always grant the request, no matter how much you ask in principle, because it can always say at any point in time, "Oh, I don't want to serve more subscribers so I'll just stop it here." But okay, that that seems less useful than... So what would be the way to go forward with this? So what did you propose in the PR?

Christian Amsüss: So, um, if if I understood correctly what what Jaime was saying was that like he also understands it like just as kind of, "Yep, there's a rough limit that the server can still use or not use." The current text says "The server might modify that limit," but it doesn't say in which direction. So it already implies that it could um, allow 64-bit of users there, which is like completely empty anyway. Um, so rather than saying, "It can set any value," it could say, "It can set any value or none," in which case which means there is no limit. Um, and that allows the server to say, "Yep, like, I've understood your hint but I don't do it this way," um, and still be compliant without having to go through a workaround that isn't helping anyone.

Esko Dijk: Okay, so the the idea was that the server could even say there is no limit, basically, based on the broker could say that based on its own determination.

Christian Amsüss: My expectation is that if servers really do um, precise management of who might observe what, that will rather depend on client authorizations than on properties of the topic. Um, which is something we can at any time add in later in extensions or however servers are configured. But then, the things that are in the basic specification, that I think Jaime has stronger ideas about like he wants this in, um, won't get in the way because the server is at leisure to say, "Understood, but um, I won't do it that way."

Esko Dijk: Okay, yeah, so so my idea was also that the broker could basically decide that limit also based on the identification of the client, basically. So some maybe authorization level that that the client has. But that still is compatible with with this idea of letting that client request some number and then basically letting the broker decide, make the final say what number to assign.

Christian Amsüss: Right.

Esko Dijk: Okay. Oh, then that is good because this sounds good to me as well. So it will be kept in in that case, but have some extra text saying what the broker can can do with the request, be bit more flexible about that. And then the other point you mentioned was number 3, I think.

Christian Amsüss: Yeah, there there that was a bit of by-catch of going over the topic again. Um, I think it's good that they have that it just that it basically now says that um, kind of, "Yep, there it's I'm fine with that being a per-resource stuff, I think." Um, and it is phrased as a maximum time, and I think people will people who implement this might have a tendency to say, "Okay, it's a maximum, but we don't have any other indications so we'll use that." Rather than taking the point to RFC 7252 and 9175, where there is another concrete rule about how often you have to check because you otherwise do traffic amplification. Okay. Um, and and that might come in handy. So also having having some reference there. But maybe that also needs checking from someone who knows observation better than me.

Esko Dijk: Yeah, so so what you want is maybe keep the observer check but not let it get in the way with the existing rules that are there.

Christian Amsüss: Yes, point to just point to existing rules, um, that you have to check before. Yep. Maximum is one day, I don't have any other good ideas, so I'll do it once every day.

Esko Dijk: Yeah, so the maximum is not, yeah, not per se the value that you need to pick, of course. Yeah. That's the point, yeah. And the idea that it's now basically configurable per topic, yeah, I thought it was maybe a good idea because you have different applications on the broker, which might have wildly different delivery requirements and liveness check requirements as well. So is that still okay then, that we have it per per topic?

Christian Amsüss: It's okay with me. I'm not sure if I'll implement it because I don't I'm not sure it's helping the reliability aspect. Um, but yeah, if if people want to have it in there, fine with me.

Esko Dijk: Okay. Also Jaime's proposal, I think. Right, I can also check that again. Let's see then, were there any other comments here on... I'll stop my screen share. On the document. So there are quite a lot of points in this questionnaire for the shepherd to go through, so I think this this was one of the main ones: so do we have a working group consensus on that, and did we have sufficient people chime in there, or just a few with the majority silent? Well, in my interpretation at least if we make these changes now, and we here agree on that, at least the people who who participated in the discussion, then the consensus should be okay. In that case, and then I can just continue with the other points in the big questionnaire. So as a next step, I'll check the comments that Marco made and also the yeah, the commit that Jaime added.

Marco Tiloca: Thank you, Esko, and all. Any more questions or comments for Vojtěch? Laurent.

Laurent Toutain: Yes, sorry. Is there a draft on this proposal?

Vojtěch Vilímek: No, no, I just proposed it on the mailing list as a reply to your to your draft. There is no no draft existing for this this one. I I I looked forward to this meeting to sort the things out and discuss how we are wanting to go further. I wanted also to explore the possibilities more and see which one is the preferred one and go with with it.

Laurent Toutain: Okay, thank you.

Marco Tiloca: Okay, thanks again, and hopefully we should have a new revision capturing these these last things before moving on.

Esko Dijk: Thank you again.

Marco Tiloca: Thank you for bringing this. So next is Vojtěch, I think, we have a few slides. So you have control now.

Laurent Toutain: Yes, Vojtěch. If you extend one, augment one model with another one, is it you have confusion or it's because you have deltas, and know which SID range you are using.

Vojtěch Vilímek: Yes, okay, I think that the way the parameters are established by both parties should be part of the document, because I think it is the hardest part of of all of this.

Vojtěch Vilímek: Okay, thank you.

Esko Dijk: Yeah, sure. Can I share the screen?

Esko Dijk: Okay, so you said you have made a PR and that relates to 2 and 3 here. The ones that I'm showing on screen now. So this is...

Christian Amsüss: Yeah, the first one.

Christian Amsüss: I don't think that's what the document says. It says um, it just says limits how many are allowed. It It does not say that they necessarily need to be pre-allocated resources for this and that many subscribers.

Esko Dijk: Ah, okay, mm-hmm. So that would limit its usefulness in in that case. So you just put a maximum without even knowing if you can even get two subscribers, for example.

Esko Dijk: Okay, so the the idea was that the server could even say there is no limit, basically, based on the broker could say that based on its own determination.

Christian Amsüss: Right.

Esko Dijk: Let's see then, any more items for today in the last few minutes left?

Vojtěch Vilímek: I have a few simple questions. First is if I can ask Laurent or Mr. Fernandez if someone could do a Python review for the code on pySCHC repo. It would be great, because I feel like the code is ready to get on master. Basically. This is first point.

Laurent Toutain: Uh, yes, on which project are you talking about exactly?

Vojtěch Vilímek: I sent a link on the PR in the chat right now. So I have I want to do one small change, but it shouldn't stop you. It is a minor thing, so you can go ahead and start or start review of the PR.

Laurent Toutain: Okay, I'll take a look, but I don't manage the core core pySCHC repo.

Vojtěch Vilímek: Oh, just say as a message to the PR if it if it if it if it looks good to you or if some changes would you have taken. We can also give you the permissions.

Carsten Bormann: Well, I can definitely answer it does not look good. It changes 214 files, which is a bit hard to review.

Vojtěch Vilímek: Okay, the problem is that I also merged again the upstream inside the changes. So basically if you if you focus only on the SCHC plugin and the tests related to that, it should be enough. The rest is the the state which is on upstream.

Carsten Bormann: Yeah, so we need some some Git hygiene here. And I think we need to make sure that the branch that is called "master" tracks Marco's branch, and then if we have a pull request that wants to change master, that's not quite the right way to do this because we don't change master, Vojtěch changes master. So that's the technical problem we're having here, and of course then somebody has to read the difference, but we're not going to look at 214 files to find that out. So it may be... If you have that many changes, then you're you're basing it on the wrong thing, that's the issue.

Mike Bishop: Yes.

Carsten Bormann: So maybe it's it's worthwhile resubmitting this pull request with a different base.

Mike Bishop: You can actually usually edit the base in GitHub.

Carsten Bormann: Oh, can you? Oh, now I definitely...

Mike Bishop: It depends on it depends on it depends on some details about how you're pulling and yeah, but sometimes you can. Like, if you have a pull request, you can change the target. But then the things that are in the basic specification, that I think Jaime has stronger ideas about like he wants this in, won't get in the way because the server is at leisure to say, "Understood, but um, I won't do it that way."

Esko Dijk: Okay, yeah. So, I will check that and write on the mailing list what are the results.

Vojtěch Vilímek: Okay, thank you.

Laurent Toutain: Yes, of course.

Marco Tiloca: Okay, thanks again, if we close this cluster of topics we move to the next and last agenda item for today. Any more questions or comments for Vojtěch?

Laurent Toutain: No.

Marco Tiloca: Okay, thank you. So next is Vojtěch, I think, we have a few slides.

Vojtěch Vilímek: So we are actually going to modify this probably, so it might change.

Laurent Toutain: Okay, thank you.

Marco Tiloca: Thank you again. Okay, thank you all. We are at the end of the meeting. Is there any AOB anyone wants to raise? Vojtěch.

Laurent Toutain: Uh, yes, on which project are you talking about exactly?

Laurent Toutain: Okay, I'll take a look, but I don't manage the core core pySCHC repo.

Vojtěch Vilímek: Oh, just say as a message to the PR if it if it if it if it looks good to you or if some changes would you have taken. We can also give you the permissions.

Carsten Bormann: Well, I can definitely answer it does not look good. It changes 214 files, which is a bit hard to review.

Vojtěch Vilímek: Okay, sorry for that. This this is on my part. The second question is, if we are building the agenda for IETF 126 meeting already, or if I'm late or something?

Marco Tiloca: In principle yes, please send any request for agenda items to the chairs or on the list. We usually come close to the cut-off with the list of usual suspects in terms of people and topics to build the draft agenda, but of course you are welcome to send requests.

Vojtěch Vilímek: And at what time?

Marco Tiloca: The sooner the better, of course, but please try to do that before the cut-off, way before the cut-off.

Vojtěch Vilímek: Okay. And the last last question is if we want to pre-allocate CoAP media types for the content CORECONF media types? Sorry. CoAP has content formats which have numeric IDs which maps to media types, and CORECONF defines some media types, I think two. And if we can pre-allocate the numbers, or if I should use the numbers from the experiment range?

Carsten Bormann: Depends. Well, I would say yes. So, we have to look exactly at the list of pre-conditions for an early allocation. And if we meet those pre-conditions, we should go for it.

Vojtěch Vilímek: Okay, so I will check that and write on the mailing list what are the results.

Carsten Bormann: Yeah, so the questions involved the chairs, so at some point, the chairs will have to say something about this, I think. I'm a co-author on this document, so I can delegate that to the other chairs.

Marco Tiloca: Plural, I suppose. I don't mind a second brain to think about it.

Esko Dijk: I think one was on holiday, one of the chairs, right?

Marco Tiloca: Yeah. So Vojtěch, you help if you write it down also as a separate mail to the chairs, and we take it from there.

Vojtěch Vilímek: Okay, thanks, that's all all from me.

Marco Tiloca: Thank you. Okay, any more items for today in the last few minutes left?

Michael Richardson: I just took look at the pyYANG CORE working group pyYANG and it looks like it looks like that pull request is against the local copy of master, which is at least which has diverged from the other one. So I think Carsten needs to do the there's a sync button now that will sync that up, that I think you can use. It's newish, well, last yearish.

Marco Tiloca: Thank you Michael. Javier.

Javier FERNANDEZ: Yeah, sorry, just to join here, like on pyYANG that we're discussing this, who is MBJ 4668? Because there's there are these two repos of pyYANG and I don't know which one is the official one.

Michael Richardson: MBJ, it's Martin Björklund, who is, you know, still the official maintainer owner. Um, but has, I would say, not that much time, and we're trying we've been trying to kind of gently get him to delegate, um, but I don't think we're successful yet. Um, and we have a fork, yes, which, you know, we would like to not have the fork. We would like to not be forked in a significant way.

Javier FERNANDEZ: I see, so I will rephrase and tell me if I understood correctly, there are kind of two official repos, only the CORE group one is truly the official one, because only only because...

Michael Richardson: No, that is not yet true. That would be a nice outcome, but that is not yet a consensus position. The MBJ one is the one that goes upstream to if you do a pip blah, blah, blah, install, you're going to get his version, that's what's in the Martin template, Martin Thompson sandboxes and templates and stuff. Um, and the version in CoRE is, I would say, very SID-specific. Um, and we need to make sure that we are tracking it the other one better.

Javier FERNANDEZ: Okay, I think I understand, thank you.

Michael Richardson: So unless you are doing something that is SID-specific, you're probably with much better with Martin's code, um, but um, we should always be a superset of it, but we apparently are not right now, for except for Vojtěch has probably pulled from both, and I probably have too.

Javier FERNANDEZ: Yeah, Laurent also have been working on on SID stuff on an MBJ fork.

Carsten Bormann: So the the branch that actually contains the CoRE stuff is called "core". To distinguish it from master, which is supposed to be Martin Björklund's.

Javier FERNANDEZ: Okay, it's super clear now, thank you, and yes, then I plus one to synchronizing master with core. Thanks.

Carsten Bormann: Vojtěch points out that the on our core branch, there is the stable stuff, which is getting SID files done, and then there is the unstable stuff, which is the SID extension work. And I am to blame for putting these two eggs into one basket, and and that's definitely not the right thing to do.

Javier FERNANDEZ: Okay, yeah, we're actually going to modify this, probably, so it might change.

Carsten Bormann: So the the cheap way out is to simply say those SID extension things are experimental, and they can very well be in the official pyYANG distribution, but they are going to change.

Javier FERNANDEZ: Definitely.

Marco Tiloca: Thanks. Anything more, now that we are in overtime?

Marco Tiloca: Okay, thank you all really. And thanks a million, Christian, for helping with the notes.

Christian Amsüss: Talk to you in two weeks.

Esko Dijk: Okay, thank you.

Marco Tiloca: Thank you, bye bye.

Esko Dijk: Thank you, bye bye.

Christian Amsüss: Bye, thank you, bye.

Esko Dijk: Bye.