Automatic IETF Minutes

Markdown Version

Session Date/Time: 20 May 2026 14:00

Marco Tiloca: Oh, go to... This is... Nice to see you. Yeah, we are on top of the hour now, but, as usual, we'll start around four past.

Carsten Bormann: Yeah, maybe we can quickly go through the agenda because there has been some last-minute adjustment, I think.

Marco Tiloca: Yeah, definitely. And, yeah, you kept morphing over the last few days or so, but, as usual, the largest part of it is related to CORECONF. It started with items from Vojtěch, and we have slides from Vojtěch covering all the CORECONF points, I think. But on the third item, so 9595-extension pycoreconf, in addition to the material from Vojtěch, we also have slides from Javier and Laurent, and last-minute slides from Carsten. After that, we leave CORECONF and we have updates from Esko on the zero-length hostname for ANIMA, related to link-format. Welcome, Javier. Oh, and Christian. Hi, Christian, and thanks for chiming in the notes.

Yes, so we actually seem to have some new participants here, so we need to go through the slides a little bit more.

Carsten Bormann: More than ever.

Marco Tiloca: Yeah, and let's get started. I think we have more than a critical mass here. Welcome, everyone. This is the interim meeting of the CoRE working group. I am Marco. My co-chairs are Carsten and Jaime. And, as usual, this is an official IETF meeting, so the Note Well applies. Get familiar with that if you are not already. Here you find details and pointers for even more details. This is largely about our code of conduct, so please be nice and professional with one another, and about IPR, patents, and so on. You have to disclose any personal knowledge of IPRs you may have, or otherwise not participate in the technical discussion. Also, for those who joined the call later, the agenda for today is largely about CORECONF topics. Three points brought up by Vojtěch, from whom we have slides. And on the third point, we also have slides from Javier and Laurent and from Carsten. Then after that, we have a fourth point from Esko as an update to what we discussed two weeks ago, ongoing in the ANIMA working group and related to link-format. Any more items or agenda bashing? I have none. We can start from Vojtěch, and I can take slides and give you control, Vojtěch, which you should have now.

Vojtěch Vilímek: Hi. So, let's start. We will discuss YANG Schema Registry, YANG Constraint Library, Unified Data Store Semantics, which is basically really focused on the CORECONF, and the pycoreconf discussion then. Ended on the, I think it was YANG tooling mailing list, bring up several issues which should be dealt with, dealt with. There are some minor things. Something like the referencing. At the last point, I think they will try to write down the bump of the version, basically of the RFC, which is fixed already. And we have things which is connected to the errata we are trying, we are working on, and also Andy proposed that the SID files publication should be connected with YANG Doctors review. What are you thinking about this?

Carsten Bormann: Can you get a little bit closer to the microphone so you are louder than the background noise that we hear?

Vojtěch Vilímek: Is it better?

Carsten Bormann: What kind of microphone are you using?

Vojtěch Vilímek: A headphone microphone.

Carsten Bormann: Yeah, I'm not sure that's actually true. Can you check on your system whether you're really using your headphone? So, now I made him kill the microphone, sorry about that. Oops.

Vojtěch Vilímek: Is it better?

Carsten Bormann: Not really. I can boost it, but as I said, then the audio... And now your audio is gone. Sorry for trying to debug this just in time. Hello?

Carsten Bormann: Audio back.

Vojtěch Vilímek: Hello.

Carsten Bormann: Hello.

Vojtěch Vilímek: Is it better?

Carsten Bormann: I don't think I changed anything.

Vojtěch Vilímek: No, I don't think either. Okay. Is it better this way?

Carsten Bormann: Well, you are a little bit closer now. That's, I am closer. Yeah, please try to keep this up as much as possible. Thank you.

Vojtěch Vilímek: Okay. Do you think that YANG Doctors review is required for publication of the SID files, Carsten? Or anyone else?

Carsten Bormann: Do I think what is required for publication?

Vojtěch Vilímek: YANG Doctors review.

Carsten Bormann: Can you say that again?

Vojtěch Vilímek: YANG Doctors, YANG Doctors review. Do you think it is required?

Carsten Bormann: Well, the idea is that we have experts doing the SID files that know what they are doing. So they may not be officially YANG Doctors, but they know where to seek help. Okay. So, formally, the designated expert for that registry is running the process. And given how much we pay them, we of course expect excellent service and actually having them talk to people. And what we are doing right now is make sure that the software bases we use for that is actually working well. And thank you for your tons of input for that. But that's essentially what is keeping us from completing that. And I'm sure somebody has the registry open right now and knows who the designated experts actually are. Yes.

Laurent Toutain: Yes, I think I am one of these experts, with Alex and Michel Veillette, I think it is.

Carsten Bormann: Yeah. Okay, so we have one very busy person from industry and two very busy professors. That's going to be fun. Yeah, but I think that's an excellent selection of people, so I am quite confident that the three of you can do that.

Laurent Toutain: Okay, I had a question about the SID file that we provide. Is this SID file has to follow the alphabetical order of YANG, or it can be rearranged? And do we ask for having all the YANG nodes having a SID, or we can skip some values?

Carsten Bormann: Yeah, so your question can be asked for Type 3 modules and for Type 1 or Type 2 modules. And I think the answer will be different. So we, I think we have to consider whether the authors of the spec are actually involved in the SID file generation, which would be Type 1, or Type 2 to a certain extent, or whether this is just done to a YANG model that has been around for a while and we just need SID numbers. So we need to have a reasonable default process that always works. And I think we are sometimes mixing up in our discussion whether we are talking about the default process and what can be done. And so if the author is actually available and is also an expert about YANG CBOR and wants to make sure that their model actually works very well for YANG CBOR, then we can do things like not generate SID numbers for specific strings. But I think that will be a rare case. What was your other question? The sequence. So, the, there is a sequence that is recommended, and we know that you can get better encoding efficiency if you do not follow this sequence. So, again, if the author is involved in the SID file generation, they may suggest a different sequence and maybe leaving gaps at specific places. But if we are doing a run-of-the-mill, default SID file generation, then we probably want to follow the recommended process in the appendix. Does that answer your question?

Laurent Toutain: Yes.

Vojtěch Vilímek: I want to also add that if you are talking about the YANG modules, they are the Type 1, and we most likely want to use as efficient order as possible. Or we can discuss this if this is the point, but...

Carsten Bormann: Yeah, so I think essentially the authors of the specification should help here a little bit and make a judgment call: how much energy do we want to... Esko, thank you for your chat comment. ...whether we want to spend the energy on really going for the most efficient ordering or not. So, maybe at some point we will have a version of pyang that does all this efficient ordering for us, so we can use that efficient version of pyang for Type 3 as well, and essentially ignore Appendix B, was it B? But at the moment, I think we really need to do the hundreds of YANG models in a way that is efficient with respect to expert time, and so they will get slightly worse encoding efficiency.

Vojtěch Vilímek: Yeah, I'm not sure how this should work with the fact that the SIDs should be permanent. We can produce some unpublished, like files that are tagged unpublished, but I don't know how of a value for the industry they will be.

Carsten Bormann: Well, unpublished files are not very useful.

Vojtěch Vilímek: Yes, but then we are really like... Then we are, if we produce the SID files as they go, as they are outputted from the pyang right now, they will be quite inefficient.

Carsten Bormann: Is that true?

Vojtěch Vilímek: I implemented the constraint YANG library and like, to be fair, it is, the saving is around like 3 bytes. But I think if this is the case even in the lists, the cost could be quite larger.

Carsten Bormann: Yeah, I think we need to look at some actual numbers to make that decision. So, it's always possible to invest more energy to get a more efficient encoding, but is it worth it? I think that's what we need to find out, because first of all, it takes time, and second, it increases the risk because something could go wrong during that manual work, and in particular if we don't have a tool to actually check the result. So, let's be a bit frugal in allocating too much work. But if you think the constraint library can be improved, let's talk about that. But we would have to look at an actual example.

Vojtěch Vilímek: Yes, I was thinking about coming up with a more efficient algorithm, but it is, it will work kind of, or it will be really hard and I need more time to understand the problem to produce a better algorithm, basically. For the optimum encoding.

Carsten Bormann: But did you see the rules, the algorithm?

Vojtěch Vilímek: I was thinking about the algorithm, but I could come up with something which is suboptimal, but which should be better in most cases. But the like, optimal-optimal algorithm, I need more time to think about it.

Carsten Bormann: Yeah, we should not try to be optimal, we should just try to be good.

Vojtěch Vilímek: Okay.

Laurent Toutain: I think it depends also on the data model and what you want to do with it. So it's, for example in SCHC, we have some constraint, we want something very compact because we are on a constraint network, and so we will do this effort. For other, we will be happy to have already an existing model, so... But it really depends of what we are doing with the model.

Carsten Bormann: Correct. So we will not have a very efficient default because the default algorithm needs to cover the whole gamut, while there are specific things that can be done efficiently because we know something about the model that is not true for other models. Yeah. But I would be careful spending too much time on optimizing this. Of course, that's always a nice thing to work on, but it can really slow down things and the gain in the end may be limited. For instance, you only interchange the YANG library once during a connection, so that's not something you must optimize.

Vojtěch Vilímek: Okay, moving on. Andy also complained about the SID range for iana-if-type, the allocation being too small. I am not sure about what to do about it. I think it should still fit in the, or no? I'm not sure, but the RFC 9595 suggests a good cushion for the unallocated SID numbers that should be prepared for the future revisions. But I'm not sure if we should like reallocate it, reallocate the range before we assign the SID file, or if we just don't care and we wait until the next revisions.

Carsten Bormann: So the slot behind iana-if-type is open, so we could give iana-if-type some 650, I think. So I think that that would solve part of the problem.

Vojtěch Vilímek: Yes, I also find the 10,000 quite unreasonable, like, unnecessarily big, but...

Carsten Bormann: Yeah, yeah, yeah.

Vojtěch Vilímek: Okay. We talked about this.

Carsten Bormann: Let's, let's take note of that and say we want to give iana-if-types another 250 because we still have that space, and can give it to them.

Vojtěch Vilímek: Okay. I also was thinking about the type-def-only modules because basically, the YANG types and ietf-inet-types are only type-defs, which are not assigned SIDs. And the only one SID which is used is SID for the module, like, basically the module identifier. So, it is a question if we really need 50, 50 SIDs for these modules, but... Because the range around zero is much more valuable than the ranges far away from the zero, because of the delta-deltas.

Carsten Bormann: Yeah, as long as we haven't actually registered a SID file, we can still fuzz with those allocations. But the current process says that you assign at least 50, so... One question, of course, is if we ever get around to a situation where we actually give type-defs SIDs. That depends a lot on how the discussion on model compilation goes in the end. So right now, we have four different things we can put into SID files, yeah.

Laurent Toutain: But the parameter is that the RFC says 50, you know?

Carsten Bormann: I think so.

Laurent Toutain: Yeah, so, hmm.

Vojtěch Vilímek: Okay, if it is by the process, I am okay with that. This is basically the modules list as tracked by the registry. I'm not sure why the ietf-sid-file is in there, because the standard says that the SID files should be encoded only in JSON. But we can have like a new, new, like, 9595-bis, or something like that, or some extension, extension work that would use the CBOR encoding.

Carsten Bormann: Right, and that would benefit a lot from having those SIDs. So I think that's a good idea to have, even if 9595 currently says you interchange these in JSON. So, as you probably know, I'm using a CSV version of those files if I actually have to work on them. And having a CBOR version probably also is useful. So, I think we can get to this at some point. So we shouldn't change anything there.

Vojtěch Vilímek: We should make a note that we want also standardize the CBOR encoding for SID files.

Carsten Bormann: At some point, we may want to do that, yes. So we want to keep that open, but we don't have to do it now.

Vojtěch Vilímek: Okay. I also miss as part of the registry the ietf-constraint-library. ietf-constraint-library.

Carsten Bormann: No, that, that isn't... Okay, yeah. This one. But it is... Okay.

Vojtěch Vilímek: It is only a draft. It was part of the yang-cbor GitHub repo, but it was dropped because it did not find its way into an RFC. It's, it's still dormant in the draft state.

Carsten Bormann: So, right now, the milestones for the working group says we are going to be done with that at some time in 2027. And there have been some comments that this doesn't work because the constraint YANG library needs to be done at the same time CORECONF is done. I think we have to discuss this. But this is on the list, and it needs to be done in a reasonable amount of time from now.

Vojtěch Vilímek: Okay.

Carsten Bormann: So, but we would allocate the SID range for that at the time when we have a good idea of the shape that this draft will take. We don't have to do it now.

Vojtěch Vilímek: Okay, good point. Okay, moving on to the CORECONF. On the next two slides, this one and the previous one, this is direct citation from the CORECONF draft, and I quite, I find it quite not explicit enough for me to be well understood. I think there are a lot of things that are like implicit, which are implied by the RESTful design of the CORECONF, or by the fact that we use YANG. For example, I have some questions here. Are the write, rewrite, for all nodes or just for nodes that are write-rewrite by the YANG? Because config falses are never writeable, should be never writeable because of YANG.

Carsten Bormann: Yeah, so what, what does the text currently say?

Vojtěch Vilímek: That the access read-write. This is all. The next section talks about something different.

Marco Tiloca: Vojtěch, your mic looks still open, but we can't hear you, or at least I can't.

Vojtěch Vilímek: Sorry. Now you can hear me? We lost you for a while. You're back, thanks.

Carsten Bormann: Yeah, I think the, the section 2.4, this is really a comment on section 2.4 of the CORECONF draft, right? And this is a bit simplistic. This is terribly simpler than it can be. So let's just make an issue and see how we are going to handle this. Because, yeah, it doesn't make sense to have read-write access to the number of packets that your interface has sent. The question is how much of this do we actually have to define here. That's probably something that real YANG people need to decide. I don't have an opinion on that.

Vojtěch Vilímek: Okay. And also when I have read the RFC about YANG data stores, I understand it the way, the operational data store have two things: it has the complete configuration that is used by the device, as well as all the config false run-state data. And I understand it in a way that is layered, like, you can query both the config as well as the runtime, runtime state. But I was corrected because as there is no such layering, the data store only contains one flat value. I want to make sure I understand it correctly, or if I'm, if I'm corrected, if this is how it should work.

Carsten Bormann: Yeah, I'm not sure we have the people in the room who have an opinion on that, but what do the other people think?

Vojtěch Vilímek: Okay, I will ask on the NETMOD working group. Never mind.

Carsten Bormann: Yeah, but there are several CORECONF implementers in this, in this room, so maybe we should try to get an opinion from Javier or Laurent. I must admit I haven't met Laurent yet. So do you have an opinion on this, Javier, go ahead.

Javier Fernandez: Yeah, so I don't have a strong opinion on this, just... but we actually implemented a data store in pycoreconf. Maybe we can just check it out, either later or during the week, and see what's missing. Honestly, I hadn't seen the, the data store definition in the RFC. Is this an RFC or a draft?

Carsten Bormann: It's a draft currently.

Javier Fernandez: Okay. No, I...

Vojtěch Vilímek: It is, it is an RFC, but basically, the CORECONF does not use it because the CORECONF defined its own data store, which is for both configuration and the runtime state. Basically, if you use the NETCONF with the data stores, you are not able to write to the data store that contains the operational data. You have different places for that.

Carsten Bormann: Right. I see. I think, I mean, maybe I'm mistaken, but maybe we look at depending on application and things like this. Honestly, we didn't really enforce any type of read and write permissions in our implementation yet, so I'm not sure. I mean, just rather say this than nothing.

Carsten Bormann: So, Vojtěch, when you say it's an RFC, which specific RFC are you... Ah, the data store, thank you. Thank you. Okay, so we, those of us interested in the CORECONF draft have to reread 8342 and see what's, what's going on there. So I think that's another issue that we need to take down.

Vojtěch Vilímek: I think it could work either way, but I think based on the current version of the text from both the RFC and what is written in the CORECONF draft, there should not, there should not be two values, there always should be only one. And there is a follow-up question, which is like, if you write a configuration and it has a minimal delay, and query it, it should have the in-use value until it is ready. So it is like a bit, like, it could lead to misunderstanding because you write something, you query it back, and you read the previous version because the configuration is on the way. Do I understand it correctly, or is maybe more of a discussion? Maybe different question: how do you think this should work?

Javier Fernandez: I'm not sure I understood fully, but do you mean, are you talking about querying data that does not yet exist?

Vojtěch Vilímek: No, let's say I have configuration node A. The configuration node A has value 1. I write value 2 into it, but the system takes like 30 seconds to update its configuration. So, I query the A, and should I get 2, or should I get 1 because it has not been yet put in in the in-operation, like, it is not used by the system for the thing it should, it is configuring?

Javier Fernandez: I think, you know, honestly, I think there's like, there should be some extra contexts to this, I'm not sure. But maybe just like not be straightforward, like, I mean if you write something and the instruction doesn't yet fully execute, and you read the actual written value, right? I mean if you write something that you know takes like 30 seconds, maybe read it 30 seconds later. Sorry, not sure if this is like kind of stuff with answering.

Laurent Toutain: Is it really the problem is coming from the, the CORECONF, or it's because we are using CoAP, and on CoAP you have some atomicity requests that you don't have in RESTCONF or in CORECONF?

Vojtěch Vilímek: No, I am currently only thinking about the CORECONF. I am not interested in the RESTCONF or NETCONF right now.

Laurent Toutain: So, I don't know if we need consistency in CORECONF with the simple protocol we have.

Vojtěch Vilímek: This is not really about the consistency. It is basically if I have two values, if I can distinguish the what I have written, if I can query the node with the parameter config and I should get the written 2, or if I should... There is no distinction between something that is prepared to be the configuration and the configuration that is really in use. And if I query the A, I will get 1 until the system is ready to use the value 2.

Carsten Bormann: So, it seems to me that the concurrency that you have in mind isn't really supported very well by the Unified Data Store. So maybe we have to say you can use CORECONF with a Unified Data Store, but you can use it with a different data store as well. That would be one that supports what you are trying to do.

Vojtěch Vilímek: I am trying to, I am trying to discuss... We are talking about the Unified Data Store, and if you read the how apply, changes applied in-place immediately or with minimal delay, I'm talking about the minimal delay. What is happening, what should happen in the meantime before the delay is, like, the time... Do you understand me?

Carsten Bormann: Yeah, I'm not sure what Section 2.4 says can actually be done. So, I think we need a real-life example of how this delay would look like before we can understand how to handle it.

Laurent Toutain: I don't know if it's the same problem, but in SCHC, for example, we have to synchronize rules between two endpoints, and we say that a rule can, if you send a management rule, then you can apply it only, use it only when you receive the acknowledgment. So that's something we, we mandate in SCHC.

Christian Amsüss: Clarify, clarify this. Receive the acknowledgment as in CoAP ACK, or receive the response as in CoAP... So you mean the CoAP response?

Laurent Toutain: It's a CoAP ACK. In what we are proposing right now.

Christian Amsüss: So, there doesn't, if, if there's a response later, that's fine, but the ACK suffices. Are you aware that this means that a proxy could, that this, the ACK could be from a proxy, and that the origin server doesn't necessarily has seen it?

Laurent Toutain: No, discovering that, but maybe we can discuss about that, but it's, normally we are in a point-to-point architecture where we, we have the two endpoints that can discuss each other directly.

Christian Amsüss: Yeah, that might be a point for, for offline discussion, but please do consider here.

Carsten Bormann: Yeah, so CoAP has this idea of having separate responses for certain cases where, where processing takes longer, so you send the ACK immediately but send the response only later. So the ACK is essentially empty because it doesn't tell you yet whether that even actually worked, just means you have, the server has received the request. So I'm not sure you can give CoAP ACKs this semantic. Yeah, but Maria's example is actually useful, and we need to understand how, how this could be supported by a Unified Data Store. I don't have an immediate answer to that.

Vojtěch Vilímek: Maria came up with, came up with an example. She has a switch, or let's, let's consider a switch. It is on-off, and the change takes 5 seconds, and the default, the starting point is off, and I write value on. And I'm asking basically, how should the CoAP behave? And is it specific to the Unified Data Store? I am not sure if it should, if I query the value, it should tell me the new one that is like being prepared, or if the old one, which is in use still, should be responded. Any opinions for, for this?

Christian Amsüss: I, I don't have, like, I don't have all the YANG context, but from a, just from a general REST point of view, my expectation would be that if you, if a value is put somewhere, and that put is, is um... that put is successful, then that, that state representation has been updated. Of course, an application such as CORECONF can have a like, more complex state, which is not fully expressed in the representations. But, I think it's a sensible baseline to expect that after, after completion, it's going to the... But maybe YANG does more, maybe, maybe CORECONF needs more.

Carsten Bormann: Yeah, so the reality is that, that people who use YANG use different data stores to handle that kind of concurrency, and I think we need to understand what cases we can cover reasonably with a Unified Data Store, and where we need additional specification to handle the case. Yeah, so I don't think we can fix this, and I think we are running out of time a little bit at the moment, because we still have quite a few points to go through.

Vojtěch Vilímek: Let's move to the consistency. The problem is that CORECONF, the RESTCONF enables only a single resource to be transmitted. It could be like container resource, but it only has to be a one resource. And the CORECONF enables us to send multiple things in, in parallel, in one message, and I'm asking about the consistency mode we are expecting, because the things still changes, and I don't think that we should require the application to lock the state if we are processing the requests. Basically because the... I think the, the draft says in current wording that the consistency block, what, which action is considered atomic is the whole message.

Carsten Bormann: Yeah, that's, that's what I would have thought too, but, yeah, so this requires a little bit of a transactional approach to implementing this. So, that, that may be more work than a constrained server may be ready to invest.

Vojtěch Vilímek: I also, because, I, I think, I am proposing that the constrained environment node, or the constrained node should not be required to be able to roll back to the previous state if something in the request goes, goes wrong. Because if we, if we do this this way, we enable the streaming of the, stream processing of the requests, which may be much faster. I, I, this is also one of my issues for the NETCONF, because based on this model, I need to parse the, parse the response, check that everything is okay, and after that, apply it if it, if it can be applied. And I could not, could not just stream-parse it in single pass.

Carsten Bormann: Yeah, so the, the question would be what does a server send back when it gets three pieces that need to be updated, and the first and the second work fine, and the third fails.

Vojtěch Vilímek: Yes, exactly.

Carsten Bormann: Okay.

Vojtěch Vilímek: Christian, you wanted to say something, or?

Christian Amsüss: No, I just misclicked, sorry.

Carsten Bormann: Yeah, so there are several things we could decide to do. One would be to require some atomicity here, so that, that puts a lot of onus on the server. The second would be to, to completely disallow updating more than one thing at the same time, but I think that's pretty inefficient. And the third one would be to say, oh, you can do that, but you are not going to get a perfectly unambiguous response from a server that runs into a problem while processing your request. I think all three answers, and there are probably more than the three I just said, have specific benefits and, and drawbacks, and we need to understand that before we come up with a clear answer.

Christian Amsüss: Why is, why is you don't get an unambiguous response even an option, because we, I don't know what the typical CORECONF error responses are. But unless there are any, um... defined already, CoAP problem details would be perfectly capable of reporting, "Yes, there was an error, but out of, um... but before this error occurred, N items of this update have been applied."

Carsten Bormann: Yeah, that, that might be another good answer. It just means that the implementation has to do things in a particular order, and, yeah, these are maps, so... fun.

Christian Amsüss: Oh, yeah. These are not really maps because there are CBOR sequence. You should apply it one, one sequence element at a time.

Carsten Bormann: Okay, the, the entire patch is a sequence, right?

Vojtěch Vilímek: Yes.

Carsten Bormann: But the components of that patch may actually be updating several items at the same time.

Vojtěch Vilímek: Correct.

Carsten Bormann: So, we have even more fun when, when doing this, because we have both, both the sequence situation, which is, is very nicely ordered, and the fact that we are just throwing data at the server in, in what might be a random order. Okay. This probably works better when we have, uh... an example that is extremely simple, just to be a simple example. But if we take some real-life situation and try to understand what happens in that real-life situation, like Maria's relay, we just had. That's an example, I think, we all can, can understand. So, let's try to come up with good examples to discuss this.

Vojtěch Vilímek: Okay. And next is the pycoreconf discussion, and I think my slides are not really that much interesting, and we should move on to the next slides.

Carsten Bormann: Okay. Javier, you're in the queue.

Javier Fernandez: Yeah, yeah, so I just wanted to say that for SCHC, for example, we looked at, like, when doing multiple i-patch etcetera, we explored RPCs, and so there you can define like a very specific output to each operation, so maybe look into that as well. When it could be interesting to solve that.

Laurent Toutain: Yeah, and another point is that we say that a rule cannot be modified. So, if you want to do something else, you have to duplicate the rule with a new number, and here you apply the change. So, it's like a version number, and we, we have consistency in, for the rule. It cannot be view at different state.

Carsten Bormann: Right. So, we will not have a very efficient default because the default algorithm needs to cover the whole gamut, while there are specific things that can be done efficiently because we know something about the model that is not true for other models. Yeah. But I would be careful spending too much time on optimizing this. Of course, that's always a nice thing to work on, but it can really slow down things, and the gain in the end may be limited. For instance, you only interchange the YANG library once during a connection, so that's not something you must optimize.

Vojtěch Vilímek: Okay, moving on...

Marco Tiloca: Vojtěch, is control of the slides right now, is that good, or is it Laurent?

Javier Fernandez: Okay, okay, yeah, sure, sure. We were not sure actually which of us should present, but I think we can both go at the same time. Okay, let's keep my mic. As a time check, it is good if we conclude with this item in 15, 20 minutes top, so that we are sure to have enough time for the next agenda item.

Javier Fernandez: Yeah, sure, I will try to hurry up. I think it's not that, not that very long. Yes. Okay, so we've been working a bit on CORECONF, like this came to light a couple of years ago, I think, even maybe three years ago. And back then, we explored the SID extension, and then it wasn't really like, I think people wasn't, weren't really interested in it. So now it comes very useful. And we would like to take up these discussions. So, the main thing that we added to SID files was the types, and... Oh, these are very specific to Laurent, so can you maybe...

Laurent Toutain: Okay, so I can, I can do it. So, here it's just to show you, so, the, the two versions: one in CORECONF lore, the other one in RESTCONF. And in the next slide, you... So, when we have to mapping, to transform numbers, integers, so, we have different solutions. For example, the first one will be an identityref, and the second one is a number, and we don't have to change it. So, that's why we need to know the type of, of the leaf. And in another, it's on the next slide, it's also the case in the other direction. For example, here we have both in JSON two strings, and these strings are not transformed the same way into the CBOR. So, that's why the type was important for the, to do the conversion. So, next slide. So, that's what I say, so, we, so we include the type in the SID file, and so we, we have different possibility. There is no type on a SID element, so it means that this is not a leaf, it's a node. And if we are in a leaf, so we have different possibility: it can be a regular YANG type, so we put it; it can be an identityref, so we don't go into details, we just say identityref, because we have the number, and normally we, we have the information in, in the SID file to do the conversion; we can have enumeration, so for enumeration, we do, we put the mapping between number and names for each values, because this way it's ease the process; and we also talk about bits, and we, we have to do it, we forget about this one; and we have also union, so union are not very useful in, in this, because CBOR disambiguates union, so we have no problem of conversion when we, we have an union, but we put it. So, currently, it's by a lift inside the JSON. Next slide. So, of course, if you have questions, you can interrupt me. So, next slide, so it's...

Vojtěch Vilímek: Sorry, don't you have an issues with union when you go from the JSON to CBOR, or you go always from CBOR to JSON?

Laurent Toutain: We go the both directions. And... So, you... I think the unions are then pretty hard, aren't they? No, because you, you have a, you have a... That's a good point, but we, in SCHC, we have one union with identityref and, and, uint, and it works, so...

Vojtěch Vilímek: So, so the thing is, it depends, I think, in the complexity of your YANG model, so, obviously, or maybe unfortunately, we only have experience with our current, like, existing use cases, the ones that we've been working on. And with this use case, we haven't had a problem. So, the thing is, for example, when it becomes tricky, it's, if you have custom, like, defines, type defines, type-defined types, and then we had to like look into the base type, like, for example, if you have something like, like we had, SCHC variable length or whatever, and it's really an identityref, and we have to put union as a first option in the, sorry, identityref as a first option in the union. So that was, we have less, yeah, less ambiguity.

Laurent Toutain: But maybe we will have problems if you have a union between a string and an identityref, and in JSON we can disambiguate it, but I don't know how it's solved usually.

Javier Fernandez: Yeah, exactly. So, so, actually, both are right, like it could be, it could be hard or not. I think it all depends.

Laurent Toutain: So, yeah, we need to, we need to check this together. I think it's, it will be good to, we can continue. So, to, to add this information, type information and key mapping, so we modify the pyang distribution, so here it's a way to run it from my repo, and we have to add the sid-extension flag to, to add this information. So, here is some example where you, we had things, so, first one is, something is a node, is not a leaf, and then we have a uint, identityref, and, for example, an enumeration. So, we know that it's an enumeration because the type is dictionary, or it's an object, and so it's, it's a way to differentiate it. But it will not work if we, we have to add bits in, in this format. So, this format was absolutely not here to be compatible with, I don't remember the name, RFC number, that defines the SID file. It was just a hack to prove that it works. And that's why maybe next slide says that... Okay, so here is an example with pycoreconf, so, how it runs. So, you, you run pycoreconf, you create the core-model and core-conf-model, sorry, and here you give the list of SID files that you need. And then, for example, if you have a JSON file that represents your JSON, then you do encode-json and you have in, CBOR data, and if you do, decode, then you, you can take the CBOR and put it into JSON. There is also parameters that allows you to store it as Python structure, so you can manipulate it directly. So, just as I say, right now, we put new stuff in the SID file without data model, so maybe we need to extend, the SID file to, to put it. So, here is a proposal to have, different, so, the base type, the identityref, the enumeration, and bits, and we put what we found, and if we have an union, we put several of them, but as you say before, maybe it's a problem because we are losing the order in the YANG file. So, that's the first thing. So, the second one is key mapping, that is added also at the end of the SID file. So, it's something that can be, I thought it was, it will be complex, but it's not so difficult to modelize in, in YANG. So, you have the, the key of the key mapping is the SID of a list in YANG, and what you have as value of the JSON is an array of SIDs that are the keys in YANG. So, this way, when you parse your, you go through your YANG data model, when you arrive to, to an array, for example, you look if this array is, a list or not, so it's the key in the key mapping. And if it's the key in the key mapping, then you look at the value of the two SIDs that are pointed, and you compare with what you get, for example, from your, your fetch or, any request, and so what is quite magic is that you don't need to know, you send a fetch with lot of parameters, and lot of keys, and you know how many keys you need to take each time, and so this way you can go through the YANG data model without anything else. And so, we put all this in action in pycoreconf data store, so we had the first one, what was the model, and we introduced also a data store, and the idea is to manipulate, the data store not using SID, but continue to use YANG identifier, because it's easier. For example, here I create a data store from CBOR data, and then we have the, so, it's view as an, an array, and so when I do, DS and, so, the data store, and I put a path, Xpath, so I can get, for example, the full, information that are is under this, Xpath. We can put also predicates inside the, the Xpath, and so this way here we, we are filtering information and get only the one we need. And we can do this way very simple operation in Python, for example, to add plus one to a value. We can also create a new entry into the data store, so that's the second example. So, here we have the Xpath, and the Xpath is new compared to the previous one because ID is equal to 1, and we add precision 3 in, the data store, and in the data store, we will have three values, the two keys and precision 3. And we can delete it also easily. And we introduce also a function that is predicates, and predicates returns a list of predicates we can have, and we can loop on them, for example, in this example, to add, plus one to all the, to all the simple count leaves that we have under. So, this is, something that can be done to manipulate, the data store only with YANG identifier. And sometimes, we need to make the mapping between YANG identifier and SIDs, is, for example, when we have to interact with CoAP. So, here is some example that we, we have in, with aiocoap. So, in the first one is a fetch, where we, get the information, and then we, so we, sorry, we get a list of, of keys, and so we call the data store, we get the value, and we returned it into, CBOR, and the other one, it's a little bit more complex for the i-patch, so, the next slide. It's, here, for example, it's, I'm very impressed with, with that. So, we, we get the, the key, the value from the request we, we have. So, we have a something that is called create-Xpaths, so we put the, the SID and the keys, and this way we create the string, we get the incoming, so we call again the database with, sorry, with incoming, and then we merge them, and we, store it, the merged things in the database, and that's all. So, it's quite easy to, to manipulate this way, and I think that's all for the representation.

Javier Fernandez: Okay, so, for a few discussion points, so, Carsten said in the chat that this information might not necessarily be in the SID file, it's just very convenient, and that's how we did it, so, it's true. Other than that, there's the union things. Yeah, Carsten?

Carsten Bormann: Yeah, I actually have a couple of slides that I've prepared that I can run through very quickly, just to, to create a different framing of the information that is in your presentation. So if you allow me, I could go through those quickly now.

Javier Fernandez: Sure, yeah, sure. And just for the record, there's Adit in the meeting who has been using pycoreconf as well. I'm not sure if, which features he has been used and what has been very useful, what has not been very useful, etc. would be good to know, but...

Adit Sahasrabudhe: Yeah, um... so I've been using it mostly, uh... to configure and get data from a vendor network switch that is implemented a CORECONF server, um... and so I've been using it to generate, to convert JSON to CBOR and vice versa, to interact with it. Um, the SID extension has been quite useful, so that's kind of why I've been, I've been involved with, uh... you know, some feature requests and stuff like that with you guys. My, my hope is that the, currently the vendor does not use the SID extension, um... and my hope is that this does get into the standard, and so it forces the vendor to hopefully, uh... utilize that SID extension in their YANG models that they, or in their SID files that they publish.

Carsten Bormann: Yeah, so first of all, welcome to, to the working group, Adit. It's, it's interesting to see that, that this stuff is actually used in some probably rather, elevated applications, so, welcome.

Adit Sahasrabudhe: Thank you.

Carsten Bormann: So, let, let me just quickly go through my slides. I only have three, and the first one is kind of empty. So, I, I want to, bring up a term that we might use for this, this kind of thinking, this kind of working, and the term is actually model compilation. So, we do something to the YANG data model, and we, we compile it into something that is useful for a constrained, implementation. So, just as a reminder, there are schema-independent versus schema-informed representation mechanisms. So, there are things like, like XDR, the, the NFS data representation scheme, where you actually have to have the data model available, otherwise you cannot even decode the data. And for, all three of XML, JSON, and CBOR, that's not how we work. We try to be model-independent, we can decode the data without, actually having the model at hand. Now, that's of course not necessarily true of the application. The application may still need information from the model to properly process something. So, you, you have a SID and, and you have to translate this into, an identity or something to be able to do something useful, with that. So, the processing may be model-dependent, even if the, the representation language below that is model-independent. So, how do we get this information fed into a constrained implementation? Of course, we can always, really code-generate and, and, turn the information that is in the model into code that actually processes the data, but that's probably too expensive actually for a constrained, implementation. So, maybe it's, it's better to actually think about compiling model information to a very simple data structure, like, like the ones key mapping, data structure or the type information that, that sits on SIDs. the point is this information needs to be generated authoritatively. So, an implementation that uses compiled model information needs to have it available, and, and, be sure that it is the right information for, for the model. So, what is useful model language, and model knowledge, and, um... I think we have seen three things here: the base type. You essentially need the base type to, to work with YANG CBOR, because what, what you have in the CBOR is not necessarily qualified as to what YANG type is actually meant. So if you have a number 10,000, you just don't know whether that's an actual number, or whether that's an, identity. So, you have to have that available, and it's a pretty smart idea to actually put this into the same place where you have the SID information, so you have that available right away when you actually process the SID. When we want to do something like stand-ins, we may want to look at derived types as well. Because for instance, an IP address is a string in YANG. So, the base type of an IP address is a string, and that's really not useful at all. So, you have to have the derived type, and the specific derived type, not just the restrictions that are applied, but actually what that derived type is. And that's why I said, "Ah, I'm not so sure that type-defs actually never will be in SID files." So, yeah, interesting. Anyway, we, we need the derived types to do stand-ins, and I'm sure we need the derived types to do other kinds of, processing. So I have even if I'm not using stand-ins, having to parse the IP address is something that I, that I can only learn from the derived type, or write special code per item in, in the, YANG model, which of course is more expensive. And finally, we have, a number of cases where we need child information. So, you may have noticed that the YANG, CORECONF, YANG CBOR, excuse me, uses maps for something completely different, because there are no maps in YANG. There are just lists that, where some of the leaves are keys, and that's what the key mapping information in Laurent's, SID extension does. So, that's another piece of really useful compiled model information, and we may identify two, three, four more, more, other things that we want to do in a model compilation. So, I just wanted to plant in, in your minds that we should think about model compilation as a concept that is very versatile and can be used for, for many things. That's all I wanted to say. I think I'm done with my slides.

Javier Fernandez: Yes, thank you very much, that's very interesting, this model compilation perspective. Um, yeah, we definitely need to have more discussions about, YANG types, etc. So how to represent them in the SID file or other compiled artifacts properly.

Marco Tiloca: Thank you, Carsten, and, okay, and we have still some time to fairly check also the last point in the agenda, from Esko. I think it all boils down to that issue 87, linked in the agenda that I can also paste in the chat. And, I guess you have no slides, Esko, so maybe you want to share your screen again, like last time.

Esko Dijk: Yep, I'll share the screen. Let's see. I think I requested it. Yeah. And I'm seeing a screen, so that's very good. So, um... just as an introduction, I'll show the same issue we talked about in the last interim meeting, so, this is basically the concept of using an empty host name in link-format link. So, this is something that I see potentially as, as usable for constrained Bruce key onboarding protocol. So, here you see basically the first example that's originally in a draft right now. So, there's basically, the multicast discovery of a certain functionality, indicated by resource type here, RT. And there's basically one response here, and that includes a link, CoAP S link with a specific link-local address and port, and type. And the second version was made to, basically, be more compact and also skip the link-local address generation, which is not being used, so, it's was not so very useful to actually include it here. So, this is just, showing well only the, the port, basically, here and the type. So, this is kind of including the information we need, here. So, this, this was what I proposed last time. Maybe we'll just move along here, so, I did a little bit of investigation, I think, based on the discussion last time. So, we found that it's okay to do it, according to the ABNF model for URIs. And then I went to look in the RFC 3986 here, if there are any rules related to the host name. Um, let me see, what are the rules here? Zero length, basically, was mentioned there, so specifically here. Yeah, so it basically says that if zero length is in there, then the URI scheme might define a default for that, and has some examples here, and it also mentions that HTTP considers basically a missing authority or empty host name invalid. So, we need to look at what does the CoAP scheme define. So, went there looking in 7252 for that, and there were these rules here, so, basically for the host, that it must not be empty, and if you receive one with an empty host, it must be considered invalid. So, you can basically interpret this in two ways: kind of the positive or the negative way, I think. So, the first one is great. Okay, because it's actually an invalid URI, you can say, still available for any new purposes that we might define here, so we can use the zero-length host name, because other hosts that don't know about this new standard, and they will see the URI and they will just discard it as invalid in any way. So, there won't be an accidental attempt to resolve it. And the second view was like the opposite, so, like, oh, no, we cannot use zero-length host name because it's invalid, and we don't want to use anything that is in-invalid, in this draft or in new RFCs. so, that would be a reason not to use it. So, it can go either way, the argument here. And I'm also noting here that maybe for number one, if we want to use that, it would require maybe some update or, or at least change to the requirements that are in 7252. And this is something I added today about this, yeah, maybe this requirements are not, not as strict as I thought, because, well, actually, the URI is considered as invalid here by the client who parses it, so, it's not being used as a valid CoAP URI. It's, in-invalid, but it still takes the port number and the link-format attributes from this invalid URI, that's how you could also see it. Okay, so this is just my, my findings, so, not sure if there are, based on this explanation of using an invalid URI, CoAP URI, if there are any people who kind of change their mind on this. One way we could go ahead is just include that in the draft, and then get it into the working group last call review and further reviews, and see what people have to say about this. So, that's it, what I wanted to basically talk about here.

Christian Amsüss: RFC 6690 is already a bit weird and complicated around resolving URI references, so I would recommend that we don't do anything too funny unless we find a way to make it like, work for general URIs and that like, we find out, or probably not update 3986, but find, find out that this works for every case of a URI, but just doing something special here, and then making it mean something without being valid for URI references in general, I think that makes the whole 6690 situation that's already a bit complicated, even worse.

Esko Dijk: Right, so, would be a reason not, not to do it, basically, or not to use it that way, right? I'm, I'm a bit surprised this is like, because we've been through this time and again, and I'm a bit surprised that those few bytes make so much of a difference, because this is about the, basically, a DTLS join proxy and not on an OSCORE ad-hoc join proxy, so, it's already, like, taking a bit of penalty in terms of, of message sizes, so, why do the bytes matter here? But if it turns out that this really needs to be so small, it might be worth considering just to say that, yeah, we are jumping out a bit of link-format, we don't try to actually express this as a link because doing because getting to that URI is just too expensive in terms of bytes, and just annotate this target attributes on the, the empty link, and give those targets attributes a very, very kind of comprehensive meaning for target attribute, rather than trying to smash it into the, into the target. So, I think my, in, in my, preferred, my, suggestion for resolving this in decreasing order of preference is, just put the full URI in there, you can afford it because you're using a DTLS. Second being, make it a target attribute that just is a numeric port number, and when it, that shows up, then the, the consumer will know what to do with the URI, being take the host component, set this as the port out of the scheme and what not. And three being doing this here.

Esko Dijk: Yeah, so that's basically argument for doing what's already in the draft, which is also a good solution, I think. The payload is basically small enough that it still fits in a single radio frame, and that's not an absolute requirement, but that's just a nice to have for discovery. And as you say, we are already using DTLS, so, the, yeah, kind of the overhead of lots of traffic, that, that definitely follows, so, there's no strict reason to be really minimal on the bytes here. It's just that the, I think the main idea was that you don't need to have the encoding component that basically takes the IP address, generates ASCII for it, and puts that in the document without basically anyone ever going to use it. But, yeah, I think it's still...

Marco Tiloca: Thank you. So, it's one more round in the ANIMA design team meeting, I guess.

Esko Dijk: I think so, yeah.

Marco Tiloca: Okay, thank you. And there's an AOB point in the, in the minutes, I think, coming from the, from the chat. Laurent, if you can please point Christian to the document you were referring to before where CoAP ACK is used and it can be problematic in some setups.

Laurent Toutain: Okay, I have to find it because it's work in progress inside the, the group, but, I, maybe Javier, we have some documentation about that. I, I don't remember.

Javier Fernandez: Yeah, we'll check, we'll check this together. I think it's...

Laurent Toutain: Thank you.

Marco Tiloca: Thanks. And, just to mention, Carsten cannot attend the interim meeting in two weeks. He's away. So, of course, we can still have this meeting. Yeah, if you are really hoping for hardcore feedback about CORECONF from Carsten, just be aware he's not going to be around. Okay, that'd say thank you very much for the discussion. Talk to you in two weeks, and on the mailing list.

Carsten Bormann: Thank you all. Great.

Marco Tiloca: Thank you. Bye-bye.

Carsten Bormann: Bye-bye.

Esko Dijk: Bye.