Session Date/Time: 22 Apr 2026 14:00
This is the verbatim transcript of the CoAP Interim Meeting held on April 22, 2026.
Marco Tiloca: Hello, Maria and Vojtěch. We are waiting for Bill, mostly to be sure we can productively start the meeting. But let's give a couple of minutes.
Marco Tiloca: Vojtěch, if you are trying to say something, no audio came. Could you try again?
Marco Tiloca: Same, at least I cannot hear you, Vojtěch, although it looks like you are speaking.
Michael Richardson: Yeah, I can't hear anything either.
Marco Tiloca: And Bill has just written me that he has trouble joining.
Carsten Bormann: Hello, audio test?
Marco Tiloca: Works for me. And now we have Bill, great. Hi, Bill.
Bill Silverajan: Hi, Marco.
Marco Tiloca: Hi, Bill. Bill, could you try your audio just to be sure before we start?
Bill Silverajan: I can hear you, Marco.
Marco Tiloca: Great. Hi. Hello. Okay, then I think we can start. Welcome, everyone. This is an interim meeting of the CoRE Working Group. I'm Marco Tiloca, co-chair along with Carsten Bormann. Of course, the Note Well applies. Get familiar with that if you're not already. Please be professional and kind to one another. If you have any personal knowledge of IPR, you have to disclose about that as soon as possible or refrain from participating in the technical discussion. Link to the notes is in the chat. Thanks, Christian, already for helping out.
Marco Tiloca: The agenda for today is splittable into two parts. First, on the document [draft-ietf-core-conditional-attributes], led by Bill. And then several points related to [draft-ietf-core-comi] that Vojtěch would lead. We have one slide per main topic. I know from Bill that he has a time constraint and he has to leave around half the hour. So let's keep that in mind during the discussion. Is that still true, Bill?
Bill Silverajan: Sorry, I briefly dropped out of the call just now. I heard that I'm first and then I'm not completely sure what happened after that, so do you mind repeating, Marco?
Marco Tiloca: Yeah, sure. I remember you have a time constraint and you have to leave the call at about half the hour.
Bill Silverajan: Yes, yes. I have a hard limit. Sorry. Yeah.
Marco Tiloca: No worries. Then we can just switch to the next deck and I can give you control. And there you go, floor is yours.
Bill Silverajan: Thank you. Thank you very much. Okay, hello everyone. This is a very short presentation about the conditional attributes draft, which is called "conditional attributes" but the title of the draft does not reflect the actual title of the document. So we're going to call it "Conditional Query Parameters for CoAP Observe" [draft-ietf-core-conditional-attributes]. So if you wish to know the history, then please refer to earlier versions and you'll understand why we don't call it conditional attributes anymore.
Bill Silverajan: But anyway, this is just a short update. And firstly, I'd like to thank everyone who has been reviewing this draft until this point. It has been very, very beneficial for progressing this work. So now we're at conditional attributes version 12 and the status of the draft is, I guess, it's already working group last call. It has been for a while. We're still getting some minor comments here and there, and then there are some additional things that we probably need to address as well today.
Bill Silverajan: Anyway, the change log of number 12 is based on review comments from the document shepherd, Jaime, and as well as the comments given by Esko and there's one more that is coming today, so we'll discuss that. But essentially, terminology section has been changed to add a couple of types. There was some discussion about how complex data structures are going to be handled and then after two meetings, we've decided that perhaps it's best to avoid complex data structures. And there was some extra text regarding our resource state projection that we didn't actually find a better place to include or another document, so it's there in Section 3.1. And there is some text about implementation considerations, considering SenML as well as the usage of the interface type descriptions. And that's all that was done for conditional attributes version 12.
Bill Silverajan: I'm fairly confident we're going to have a version 13 because there is still one issue open and I think that's pretty much why we decided that maybe today would be a good day to do that. And I'm sorry that I didn't—well, there is a link there for you if you are able to—I don't think you can click this, but if you go to get the slides down, then you probably can see what's happening there. But I think there has been some discussion already previously about adding an interface description to conditional query parameters, and this was a discussion that was, I think, Esko and Christian started this and then I think it has gone on for a while. I'm sorry that I wasn't around at that point to actually contribute to the discussion. I think Carsten also wrote something here.
Bill Silverajan: But the gist of this is about whether conditional query parameters should actually have an interface description that allows them to be discoverable. I actually did not include anything regarding that in the number 12, but I did mention that at least at this stage, the specification does not require resources to advertise explicitly support for conditional parameters through resource discovery and it does not define a new calling format. And I also put a placeholder there that future specification may define a link format interface type or other discovery mechanisms. And so these are all the slides I have for today. Just this is basically where we are. And I wanted to raise this point whether to—I'm trying to raise the point that at least I feel that this specific draft is perhaps not the best place to do this, but I'd like to hear your opinion on this because I think that there has been quite some discussion taking place already. So I feel that this might be something that the—it might actually encompass a wider discussion about whether query parameters should be discoverable, not just conditional query parameters but query parameters as a whole. And I'm thinking that if we are doing this, then of course interface definition should be added. And if so, whether we could actually do this in, for example, the interfaces draft [draft-ietf-core-uri-path-abbrev] that could be perhaps a better place to discuss these things. But please, yeah, I'm just yielding the floor to whoever wants to discuss next.
Christian Amsüss: Hi, Bill.
Bill Silverajan: Hi, Christian.
Christian Amsüss: Hey. Thanks for the update. I'll just briefly summarize why I think that this should be in here, and that is this document defines query parameters that can alter—kind of create those views, which is fine. But there is no well-known for query parameters. And unless there is some way by which the server opts in, this would conflict with general URI practices. So I think this document should define an if. It doesn't need to mandate it. If people use it without having it explicitly in well-known/core, that's fine. If they have another way of finding out that the server isn't using anything conflicting, that's fine. But this is not usable or treading on the URI namespace without having this.
Carsten Bormann: Yeah, I was not going to make a comment citing the BCP, the number of which I forget—the "don't tread on my lawn" BCP. But generally, I think it would be good to have a way to indicate this behavior. And I also think it should be optional to indicate this behavior because LwM2M systems don't need that indication and it would create a backwards compatibility issue if it was needed to put this down. But yeah, so we have a kind of different view on cause versus effect. I don't think that the fact that you can announce it in any way causes a requirement to announce it. But I still think it is good to be able to announce it if you are advertising resources into a space where it's not implicit that these conditional query parameters exist.
Bill Silverajan: So my question here is that I do not want to create a situation where conditional query parameters are actually defined differently from regular query parameters. Because the idea of the conditional query parameters is that they are basically constraining the way we are using observe, right? So if we are using observe—if we are defining a resource with an interface type and providing all these parameters, and then somebody does not announce that the resource is observable, what is the implication of that? That's the first thing. And the second thing is also that we actually have this situation whereby a server has the option of silently dropping any requests that come in. So I'm just wondering whether it's worth doing this. But my concern here is that I think this is a very valid point that query parameters could actually be described with an interface type description. And I'm just thinking that whether we should treat all query parameters the same way instead of having this special behavior only for conditional query parameters. So that's my point here.
Christian Amsüss: But query parameters are already treated that way. This is not making it special. This is just—we are in a situation that we don't have another document where an internet draft specifies query parameters for general resources. If you look, for example, at the resource directory, the resource directory also describes—it has a registry for query parameters and that those apply follows from following the resource type. The kind of only new thing is here that we are not about a resource type because everything—those could apply to everything—but about an interface. But the distinction between resource type and interface is very wobbly at best anyway, so it's not—we are not doing anything new for query parameters. Just everyone, in most situations, this is implicit and here it can't really be.
Bill Silverajan: Okay. So let's project this forward. Now if we define a new calling format like interface type, talking about conditional query parameters, would that also require now that we set up an additional registry or sub-registry for registering these types? Or are we registering this to an existing registry already?
Christian Amsüss: Sorry, please say again. I'm sorry, I didn't—
Bill Silverajan: No, I'm sorry. I just meant that if we're now looking at this—at these conditional query parameters and allowing an interface description to these, are we going to register these interface description types, firstly, to an existing registry or are we setting up a new registry for specifically conditional query parameters?
Christian Amsüss: This is really up to this document. The only thing that the if says is that if this interface applies, then those query parameters have a meaning. Whether that's in a registry or not, I don't care so much. And yeah, as Carsten points out, the value for if, just for the interface type, that has a registry already.
Bill Silverajan: Yes. Yes, exactly. Which means that now—would it then mean that okay, we are going to register a different interface type for each individual conditional query parameter?
Christian Amsüss: No. It would just be a single interface type that says everything that is within this—probably, what's the current prefix, p.?
Bill Silverajan: c.
Christian Amsüss: c., yeah. Everything that is in the c.—so the meaning of if= probably core.cond-attr means that every c.-prefixed query parameter means what this document says.
Bill Silverajan: Okay. Okay, I'll think about this a little bit more and then see how we can do this. But if you think that this is valid and this is important, then of course we go ahead with it. I choose to differ on my opinion here, though, but well anyway, I'll look into it and see what we can do.
Marco Tiloca: Yeah. Another point that was raised also in previous discussion was, building on announcing the interface or not, what is the server supposed to do if it receives a query parameter that it doesn't support? And the idea was simply to go for a no-op. That's probably something to write down explicitly.
Bill Silverajan: Yes, I think this is exactly what I meant, that we will have to think of these error conditions.
Marco Tiloca: And Carsten says no-op already is the behavior, by the way.
Carsten Bormann: Yeah, so what I mean by that is normally if you put something in the URI that the server doesn't understand, the server is going to send you a client error because the client should not be using things in URIs that the server doesn't understand. So here we would— the interface announcement would say the server promises to ignore things that it doesn't understand that have a specific shape. And I think we had discussed whether we would capitalize the query parameter to indicate that it's an ignorable query parameter.
Bill Silverajan: Sure, yes.
Marco Tiloca: But Bill, basically the single interface value would just say, "This server for this resource supports at least one of the conditional query parameters." And yeah, then possibly a no-op follows if something not understood is used.
Bill Silverajan: Well, yeah, that's exactly my point that if it is just one value, then I'm not entirely certain whether it's that descriptive that the client then has to go through the entire list anyway to figure out what is supported and what is not. So, yeah. But I'll have to check this further and see what happens. Christian had something to say. Sorry, Christian.
Christian Amsüss: Yeah. I think if there's need for more discovery, I think that's an orthogonal issue. This is not about what works. This is about violating other people's contradicting expectations. So I'd probably even say that the presence of this parameter likely implies that you support at least one of the attributes, but if you don't support any attributes, it's still sensible to set this because then the client knows that it can try and the fail-over behaviors that are described in the document follow from that.
Bill Silverajan: Sure, sure. Yeah. Okay. Yeah. Thank you. I'll take this on board. Any other comments? And please also be reminded that the discussion is taking place in the GitHub issue too, so...
Marco Tiloca: Yeah, but procedurally in two points: Bill, please have a look to the minutes of those two past interim meetings where this discussion basically happened and that seemed to be kind of the direction that already ended in a section of [draft-ietf-core-corr-clar] already. And the second point, we passed what was set as a milestone to request publication some time ago. The chairs had in mind to update the milestone to say October this year. We wanted to check with you, would that work for you as a tentative milestone for publication?
Bill Silverajan: Yes, I think this would be good. Let's go for that. Yes.
Marco Tiloca: October this year. Oh, thank you. Thank you very much. So looking forward to, yeah, addressing this and eventually the next version. Then for Jaime to wrap up the write-up.
Bill Silverajan: Sounds good.
Carsten Bormann: Yeah, I'm not sure that Bill actually sees the comments I'm typing into the chat.
Bill Silverajan: I just saw it. Sorry because somehow my screen doesn't show the chat but I just saw it and thank you for the comments. You're welcome anyway, and thank you for the comments. Yes.
Marco Tiloca: Okay, any more questions or comments now live? That can't wait for the list or GitHub? Anyone? Hear nothing, see nothing. Then we are done with this topic. Thank you, Bill. Thanks a lot.
Bill Silverajan: Thank you.
Marco Tiloca: And next to be Vojtěch and I can give you control in a sec. So you should have control of the slides. Vojtěch, do you have audio working now? At least I don't hear Vojtěch. Technical issues. Yeah, you can try with a different browser if you have an alternative available.
Vojtěch Vilímek: Is it fixed?
Marco Tiloca: Almost.
Vojtěch Vilímek: Almost?
Marco Tiloca: Yeah, yeah. There's a bit of noise in the background but it's doable, I guess.
Vojtěch Vilímek: Yes. So sorry for the noise then.
Marco Tiloca: You may want to reduce the gain on your microphone because your system is clipping.
Vojtěch Vilímek: Okay. Is it better?
Marco Tiloca: Yes. Nice. So let's start. What do we have on the menu? SID issues, YANG-CBOR [draft-ietf-core-yang-metadata], the draft regarding the instance identifier missing rules, YANG stand-ins, bit-YANG maintenance and CoRECONF [draft-ietf-core-comi]. Now I want to say that if you have anything to say, say it whenever it comes to your mind. Don't feel shame to interrupt me.
Vojtěch Vilímek: So SID issues. Bill writes something to the chat which is unrelated. SID issues, the choice and case related issues are mostly resolved. The third item is non-issue as we discussed with the ND Bearman on the mailing list. In the SID file example, Marco linked the PR on the CoRE repo for the RFC 9595 which did go under my radar and I didn't know about it, but it is still—even with the changes from the PR—the SID file still misses some assignments for the input and output nodes. So I want to say this. Andy has several comments. I think this was on the YANG-to-link mailing list but yes. Do you have anything to say to that? It is just—I think it is more like more nits if we don't consider the IANA registry. The IANA registry will take some time but we need to firstly resolve the issues, the other issues with the RFC. I also—I did not find any conventions for the SID file names and I think everyone uses the same convention as for YANG files, but this convention does not cover the IETF SID file version in the SID file. There is a field for the versions of the assignments, not following the versioning of the YANG modules. And we don't have any convention for that. So do you have any suggestions?
Carsten Bormann: Yeah, we need different names for different SID file revisions if we actually need to address them. Do we have a need to address an old SID file?
Vojtěch Vilímek: I think it is needed because now all the files should have the same name which is like colliding if you have a registry or if you have some history of the previous assignments.
Carsten Bormann: Yeah, so you replace the old SID file with a new SID file. That's not exactly a collision, it's a replacement. Is that wrong? Does it hurt us that we can't get to old SID files because we don't have a name for them?
Vojtěch Vilímek: Okay, so we just tell it is non-issue.
Carsten Bormann: I'm asking. I'm trying to find out whether it's a problem. So if I get a SID file from somewhere and it has a higher revision number than the one I already have, then apparently I have something new and I should be using that and not the old version.
Vojtěch Vilímek: It depends on what the server uses because the newer revision of the SID file might tag some of the assignments as obsolete and you should not use them.
Carsten Bormann: Well, yeah, what does that mean, an assignment is obsolete? Is the actual resource at that place, is that data item obsoleted? In that case, it doesn't hurt to have old entries in the SID file.
Vojtěch Vilímek: So the thing is—okay. Michael wants to say something.
Michael Richardson: Yeah, pushed the wrong button here. I was confused by your comment that the file doesn't have a—the SID file doesn't have a revision in its name, that it overwrites each other. Is that what you said?
Vojtěch Vilímek: No, no. The problem is that the SID file is associated with some YANG module. This is one axis of versions. And the SID file itself has a field in it which says "I am version 2" of the SID file, which is orthogonal to the YANG version. And we have no way of for the same YANG version, we have no way of referring having a file that has different—that refers to that different SID version. Yes, I get your point. Okay. Yes. All the SID files should be named with the same—
Michael Richardson: I think that that only happens for developers of the spec. Okay. So when if I, as the developer of the spec, revise the—revise my YANG module such that I would now produce a new SID file and I don't update my YANG module version—and now we also have semver coming for YANG, so that's more—I don't know how that's going to—I don't actually understand how that's going to interact with the dated YANG module version, I don't have any knowledge about it, I just don't know. But the point is that if I do that, I think that's only going to happen effectively on my desktop and so now if I need to know the previous version of the SID file, well that's what source code control is for. That I should never effectively be—well, if I am publishing internet drafts on that, they are internet drafts and then it's tough luck, right? Things change. But if I ever published that YANG module with a revision number, then effectively you should never have a SID file with more than one version unless we actually have an error in tooling that means our SID numbers were omitted. Like we suddenly decide we're going to do SID numbers for RPCs and we have to go back to old versions. So then I think that happens. But I don't think that happens in an otherwise—that's my experience, but...
Vojtěch Vilímek: Well, I am quite sure—I hope you that you can hear me—I am quite sure that we are going to botch some release of bird in the future. We're going to botch some SIDs and then we're going to release a patch version which is going to be like, "Well, we botched the SID file so here is the new SID file which is actually the right one" and it will actually be that version. So 3.5.1 is going to use one SID file and 3.5.2 is going to use the second SID file and these will be actually incompatible.
Michael Richardson: So my claim is that if they're actually incompatible then you and you didn't change your YANG module version then you did—that's the problem. That you should have revised the YANG module version as well and not just, you know, oh I if you say "Oh, the I used the wrong SID number in the old version of bird for created-on and it should have been expires-on," that's a bug. But the SID number for created-on isn't fixed, it's just the old version got it wrong. Well that's a different problem almost, right? It may be still a problem but it's a different problem.
Vojtěch Vilímek: If I do bad tooling so that I generate the SID file and then the SID file is applied in the build so that the old build for like 3.5.1 is using a wrong SID file so and for 3.5.2 I fix it, it becomes effectively incompatible. My conclusion basically is that whenever a SID file has to make an incompatible change, we should actually revise the YANG even if there is no note change inside the YANG.
Michael Richardson: Yeah, that's what I'm saying. And in your case, if the scenario that you say you published, you know, 2026-01-01 YANG module bird version whatever you said 3.5 or whatever, and you shipped that and it's wrong and that YANG module actually does not reflect what you implemented, then actually you should issue YANG module 2026-01-02, right, with the corrected thing. Sorry, with the wrong thing, the one that you actually implemented and then in bird 3.6, maybe you go back to the original YANG module with the correct SID allocation. But now actually you have to give it them both get new numbers, I think.
Vojtěch Vilímek: It's basically the right approach is screw it and make a new YANG.
Michael Richardson: I think that's the right answer because you want to express, "Well, actually I'm using, in this case, maybe it's not an IETF standard BGP module, it's a bird-specific one." And I gather that doing BGP with YANG is now is still a very vendor-specific because of your internal modeling, that's what David told me. Yeah, but the point is that yeah, I think that's the answer is that you just got to make sure you have a YANG module that reflects whatever code you shipped with whatever bugs it has in it, right?
Vojtěch Vilímek: Yep, makes sense. Thank you.
Marco Tiloca: Carsten?
Carsten Bormann: Yeah, so I would like to agree with what you just said but only as one of several options. What we wanted to avoid when doing YANG-CBOR [draft-ietf-core-yang-metadata] was doing a "tail wags the dog" situation. So if the YANG module actually is the dog and we just happen to have a YANG-CBOR representation of that in use somewhere, we shouldn't have to change the YANG module to fix something in the YANG-CBOR representation. I think that's already true for XML and JSON, so this is not a new thing. But of course there may very well be YANG changes that were necessary just for JSON. So I don't know about that. But essentially what I'm trying to say is we should be able to fix mistakes that are just on the .sid side without impacting the .yang. Of course if you have both under control, it's much easier to just change both and we're done. But yeah, if you're talking about something like bird where everybody is aware that there is a CBOR access using SIDs, that's fine. You can do that. But if we are talking about something like IF-types, we don't want to change the IF-types YANG just because we messed up the .sid file. And that's what SID revisions are good for.
Michael Richardson: And I think in some cases we would actually wind up with a SID file that had a SID number allocated for the wrong one marked as obsolete and new SID numbers for the corrected possibly more than one entry if we had a confusion back and forth, right? So if someone ever saw a wrong one, they would know, "Oh, that's the broken one where we some people implemented it wrong and we hope no one has it."
Carsten Bormann: Yeah, I'm not so sure about the exact path of things when we obsolete SID file entries because I simply haven't had a case where that was necessary, so I'd rather discuss this with an example where I understand the implications.
Vojtěch Vilímek: Yes, the SID allocation have like lifetime, have three phases: it is unstable, then is stable, then is obsolete. And I think—so and the SIDs try to do perfect mapping. They say we want to have only one SID for given YANG path. And I don't know—I am not sure how it is worded exactly, but we could consider it as we have only one stable or unstable SID for given path. That we can just like cycle more SIDs for given path or is it wrong? Carsten?
Carsten Bormann: I think your sentence had a very interesting component which was "we want." And I think we have to be very clear in our minds whether we want something to happen or "I'm sorry, everything is going to break if you don't do that." That's a different kind of "we want" and we have to be careful separating these two types of "we want." So we want a perfect mapping in the sense this is what we are trying to get. We are going to have a big problem if we have one SID that stands for multiple nids. We definitely want to avoid that and we are prepared to expend additional SIDs to avoid that situation. But as soon as we expend additional SIDs, then we no longer can guarantee that there is only one SID for a given nid. So there's no way here to have our cake and eat it too. So in case of a problem, we'd rather spend another SID and break our "we'd like to have" requirement that there is only one SID for a nid, then break the "must have" requirement that there is only one nid for a SID.
Vojtěch Vilímek: Okay, understood. Thank you. So I think this slide is exhausted. Let's continue. Yes. So I imagine—I propose the plan that we finalize the erratum which should contain the omission of the choice and case options from the paths and from the assignment. Christian? I don't understand what you mean.
Christian Amsüss: I'm just taking minutes, didn't get some things so no need to do that on audio but maybe Carsten can help a bit filling out the minutes, that would be appreciated.
Carsten Bormann: Yeah. So yeah, when you say finalize, is there anything that needs to be changed there?
Vojtěch Vilímek: I want to add the changes to the example JSON because it lacks the input and output nodes. And the document says every node must be assigned a SID.
Carsten Bormann: But that would be a different errata report.
Vojtěch Vilímek: No, this one is the one that I filled back in the day and it was I just replaced the whole JSON because the paths were wrong in the previous wording. But we come to the conclusion because there was inconsistency between the text and the SID file, the example file, so I changed the example file but it turns out that the text was wrong.
Carsten Bormann: So we have this one errata report that is sitting in the repository waiting for it to be submitted. So this is not the one but that's this is a different one. And where does that live?
Vojtěch Vilímek: This one lives in the IETF system, report system, what is Errata system.
Carsten Bormann: Yeah, but we cannot edit things in the errata system in a convenient manner. That's why we actually created a branch in the repository for YANG-CBOR [draft-ietf-core-yang-metadata] that has the other errata report. And I was just confusing the two, I'm sorry about that.
Vojtěch Vilímek: Yeah, okay. I think the all because the errata talks about similar thing, the inconsistency between the text and the example. I think it could we may ask—I don't know if the AD is the wrong right person or not or we can just close this one or create new one or change the it doesn't matter but you know what I say.
Carsten Bormann: What I'm trying to get is before an errata report is submitted, let's have a discussion in the group what we actually want to have in there. And that discussion works best if we have that errata report, the draft errata report, somewhere on GitHub. And that's why we did this with the case-choice errata where the description is wrong and nothing else. And we could have another errata report for the input-output thing because that's similar but ultimately unrelated. So we are not changing the YANG, we are changing the example. Right?
Vojtěch Vilímek: Okay, right.
Carsten Bormann: Okay, so let's figure out how to put this into the repository. I forget how I actually did this with this errata report and let's—
Vojtěch Vilímek: Sorry, this one link is to the IETF system tracker, errata tracker. The blue text basically is a link. And there is a on the core-wg user, core-wg user has repo named yang-cbor, I think, and part of the this repo contains the text of the YANG-CBOR RFC, now RFC 9254, and also the RFC 9595. And there is one PR which contains your fix to the problem.
Carsten Bormann: Yeah. So if you have the pointer to the PR, then we can discuss this and have a resolution with all the help GitHub gives us in resolving things before we submit a replacement for 8629.
Vojtěch Vilímek: Okay. Yes, basically I fixed the PR so that it created the paths with choice and case because in current time it is the way it should how it should work. And there is a work of the—I hope I didn't butcher the main name that much but his name is Laurent Toutain, or something like that. Which his code, the ltn22/pyang, has some start of the work with the fixes, but...
Carsten Bormann: Yeah, right now we have several different repositories in which there are different threads of fixing things and we will need to sit down and merge all these conflicts in the next couple of days and then we have a slightly more palatable situation again.
Vojtěch Vilímek: Yes, I have a good picture about that because I have I myself have a pyang fork and I have basically branch for every change I did and it contains changes from the upstream, changes that are only on my repository, changes that are done for the IETF CoRE fork and also some of this like staging or experimental code, so it is quite a mess.
Carsten Bormann: Yeah, sorry for herding the cats incorrectly here and we need to fix this so we can make progress again. Nice. Okay, so we wait with submitting the errata report until we have cleaned up the pyang situation. That's what you are saying here.
Vojtěch Vilímek: No, I think we should fix the text and then do the implementation.
Carsten Bormann: We can fix the text. But when do we actually submit the errata report?
Vojtěch Vilímek: When we think the we have no comments and it is like finalized. We think it is it works again. And I will have the comment, "Is this implemented?" as always, as long as we haven't implemented it in pyang. Okay. So you would wait to the one working implementation. I think ND Bearman has the code working but I'm not here and I'm not sure if it works.
Carsten Bormann: So we just need to work together and do some merges, get everyone else to look at those merges and the conflict resolution in those merges and make sure we have a single branch. And it was probably my mistake to call the branch core in the CoRE working group fork because I didn't want to impinge on the master branch that used in the original. Anyway, so let's fix that offline and this should not hold us up for very long. Nice.
Vojtěch Vilímek: Okay. As you have been right, Carsten, I will jump to the 14th slide because it has the text about the pyang maintenance. I basically there are some issues with the current implementation, I fixed it and I basically there was no discussion about that on the YANG-to-link mailing list so I asked the guy who runs the upstream pyang to merge it. So it is already in upstream. It has not yet had a new revision but it the code is ready, the tests are written, everything passes and it is basically when the next revision of pyang will be will be created the code is there.
Carsten Bormann: Okay, so it is in what's the name of MB?
Vojtěch Vilímek: mbj4668.
Carsten Bormann: Right. It is in that repository already.
Vojtěch Vilímek: Yes, yes.
Carsten Bormann: Okay, what branch is it under?
Vojtěch Vilímek: master.
Carsten Bormann: master. Okay, good. So if we merge master at some point then we we should be good.
Vojtěch Vilímek: Yes. I also so there are three changes basically, they are listed there. I created a PR about all of them at once, then Michael around the time the IETF hackathon was taking place, he said it is a lot of code, I should split it, so I split it in the pieces as I implemented it and it resulted in these three PRs. I can talk about them quickly but it is not that important. Most of them are bug fixes because so the SID file description is like optional field and we now previously the pyang just didn't use it, now it generates a message it was the SID file was generated with pyang. The sub-module name fixes paths with that are with that have pieces contributed from the sub-modules. So the sub-module have have name and the name is not important but the pyang generated paths with the sub-module names which is wrong, so it is this is fixed. And also Michael Richardson when playing with it or reported bug that dependency revision contains duplicities so I fixed it.
Carsten Bormann: Okay, so we will talk about these in a few other slides, right?
Vojtěch Vilímek: This is only the one slide for pyang.
Carsten Bormann: Right, but we will talk about dependency revision.
Vojtěch Vilímek: We can talk about it now but I don't have the slides prepared. The other slides are about different things.
Carsten Bormann: Yeah, so maybe we should actually do this in the next interim then when we have had an offline discussion what exactly goes there. There are some messages on the YANG-to-link mailing list I think that we have to consume. Ah, and Andy just adds another one.
Vojtěch Vilímek: Yes, I found another bug and I also it prompted me into writing the new message on the YANG-to-link list because I was not sure.
Carsten Bormann: Good. Let's complete that discussion before we merge number 23.
Vojtěch Vilímek: Sorry?
Carsten Bormann: Let's complete that discussion before we merge number 23 because this sub-module thing is really ugly and we're kind of carrying around a vestigial part of YANG here and trying to accommodate it in some way and creating a lot of complexity and I think we need to understand how to manage that complexity.
Vojtěch Vilímek: Yes, I agree because I think the YANG sometimes face like sub-module is module and in other context it is not, so it is it is complicated.
Carsten Bormann: Yeah, and the document uses two words, "import" and "include," which really already indicates that there is a lot of confusion here and yeah, let's do this discussion off-list and report in the next interim.
Vojtěch Vilímek: Okay. Then I want to present you the my draft about the missing rules for the YANG-CBOR [draft-ietf-core-yang-metadata]. So I have a simple example YANG module is indirect reference for for the YANG and we have a few—Michael—I also think it is not—sorry, we should firstly finish the previous talk and to that I want to say only only time I know about using sub-module is the IETF SNMP module.
Michael Richardson: Okay, I like never even knew it was there, so I'd like "Oh yeah," so I mean clearly that it's a problem. Yeah. Okay. Anyway, sorry.
Vojtěch Vilímek: My point is it does not work. Current state of the pyang does not work correctly. So okay, back to the identifiers. This is like very simple example of YANG module and every possible instance of this module is addressable by the current wording. I have the examples of the identifiers here. And the YANG-CBOR talks about single instance nodes which are basically any node that has clean path from the root to the given node that is either container or leaf. So if you have container SSH, it is referenced as only the SID, bare SID, or the integer, but it is from the context it is known it is SID. Or if it is a leaf, it is just just a SID. If it is not a single instance node, like an entry in a list, it must contain alongside the SID also the keys. And Carsten already figured it out: as you see, every every key is put into the string format in both in the XML and in the JSON. As so the port has integer type but is encoded as string 80, not 80 in the identifier. This has some drawbacks but also it works it is it works simply because you everything—So also I want to talk about the nits. I want to ask Carsten if he can provides a definition what what an nit is, because there are some corner cases which might not work with the naive definition.
Carsten Bormann: Yeah, so we have instance identifiers. And instance identifiers use as long as we are talking about SIDs, use one SID and then the path of keys that let us go through the tree. So those are the instance identifiers. Now we have SIDs and we have nids. SIDs are simple numbers and the point of a SID file is to map a SID to a nid. We didn't use that name and that was a big mistake. So a nid looks like a name-based instance identifier, except that it leaves out the stuff that is in brackets here.
Vojtěch Vilímek: So in other words, maybe for me it is more simple to approach it that you have the schema path and you leave out the choice and case nodes and you have a nid, right?
Carsten Bormann: With luck, yes. I'm not sure that's true always, but that's the idea, yes.
Vojtěch Vilímek: The problem is that you have the RPCs and actions. RPC is a top-level thing which is like remote procedure call, very simple. And it has name and it is rooted in a basically it has no parent. So—
Carsten Bormann: Right.
Vojtěch Vilímek: And it has two types of branches: input nodes and output nodes. And the do you think the yes. In an in the SID file, the input and output nodes—okay, it is simple definition, like the thing you use in the identifier field.
Carsten Bormann: Yeah, there are some examples in 9254 that I think are mostly correct. And if we have problems in those examples, then we have to identify them and generate errata reports. If 9595 doesn't say you need to create SIDs for the name-based identifiers that you get for RPCs and actions, then that may be lacking discussion in 9595. But 9595 doesn't define these things, 9254 does. 9595 only tells you how you manage this. So if there is an example in 9254 and no discussion in 9595, we don't necessarily have a problem.
Vojtěch Vilímek: Okay. Continuing, moving on, there are some cases which are not covered by the YANG-CBOR [draft-ietf-core-yang-metadata]. And this there are two such constructs: lists that don't have keys, which is only possible for the config-false list, and the leaf-list. And the problem is that the text goes like something like, "When you have list identifier, when you want to identify something in a list, you just go from the root to the node and from the key statement has the keys sorted, so you put the keys one after the other." If there is multiple levels, which I don't have example for now, there are put all from from the—okay, Carsten.
Carsten Bormann: Yeah, so I think this is a really important observation here. The question that comes up in my mind is we only need instance identifiers if we are actually able to make use of them. So how would accessing one of these things work in RESTCONF [RFC 8040] and CoRECONF [draft-ietf-core-comi]? That's really the part that I need to understand before fully making up my mind about this. So if we don't have a way to get at these things, we don't need a name either.
Vojtěch Vilímek: You can have some just you can have like a list of users, for example, and you have you can have a leaf on entire other place in the model that has type instance identifier and you want to store a user identified by the identifier. So you just the leaf would have would be typed instance identifier and the content in the in the runtime would be pointer to the some of the users available in the in the list.
Carsten Bormann: Yes, but you only can use an array index in this particular case, right?
Vojtěch Vilímek: Yes. So moving on the next slide. Yes. It is also interesting that the config-false lists may have duplicities, which is nice because the YANG then says it is not defined which which instance is targeted, or which one, so it is great, you know.
Carsten Bormann: Yeah, so I think the interesting observation here about this particular slide is that we are using additional components of XPath to generate the name-based side of this. Yeah, we don't have array indexes normally. We don't have .=.
Vojtěch Vilímek: We have. If the list don't have a keys, the XML and JSON identifier would look like this.
Carsten Bormann: Yes, but we never use something like this in YANG-CBOR. So you can call that a gap. I can call it a deliberate omission. Okay. We can find out who of us two is doing the bigger damage. I mean both viewpoints essentially don't make sense. But one of them is maybe worse than the other, and that's the one I would like to avoid. So I'm looking at this from a slightly different angle than just trying to fill in the gap because I'm not sure that the gap needs to be filled in.
Vojtěch Vilímek: I think it will be better to fill it because we want to have a complete YANG parity, you know. If if it can be done in JSON, why shouldn't it be done, couldn't it be done in CBOR? You are just telling also you are if we don't include this, you are telling that it is nice that you have this shiny shiny YANG model but it is not useful in in CBOR because you cannot access the some of some parts of the model.
Christian Amsüss: It it might help if we um to just use an example where array indices make sense in the model, which they don't do here but there might be YANG models where this is actually the case.
Carsten Bormann: Yeah, Christian makes an important point that whenever we discuss something like this, it would be really good to have a live example where a live example is one that is in use in some YANG module that actually is in use and so on. And I totally agree with your argument. I'm just saying it's not the only argument. And therefore I'd like to understand what what the damage will be. And yes, what you're saying is the damage will be there are YANG modules out there that that don't have CBOR representations and that's actually pretty bad, yes.
Vojtěch Vilímek: Yes. So basically to summary the rules, the rules are meant that the list without keys are indexed-based and the instance identifiers, which is weird, are based on the real stored value. So if the measurements has integer type and the value is 1440, we just use the rule for the target type. So we would put an integer there not the string. As also it it is a similar case as the previous example in the string representation, everything is put is represented as string with all its drawbacks. And on the previous interim before before the IETF, we discussed that no not all instance identifiers are valid and here is an example. When you have a list schema node, you must specify all the keys. If you don't specify the keys, the instance identifier is not valid. Which is I think this come it is a remedy of XML encoding, but it is what it is. Yes, exactly. And also we might come to this back when we talk about CoRECONF because if the list is top-level, you don't have any enclosing enclosing container that you would you can address only by the SID. Yes, yes, we might we might introduce a new type of identifier.
Carsten Bormann: Yeah, so this is really important because when we finish CoRECONF [draft-ietf-core-comi], which should happen any day now, we need to make sure that we have the identifiers in there that actually need it. So CoRECONF is the the document that actually uses the various media types that describe these identifiers and yeah, if there is a collection identifier, we probably need to identify it in CoRECONF and ultimately in RESTCONF as well.
Vojtěch Vilímek: Yes, but I am saying that basically the way the instance identifier is defined by YANG is that the array array things is not addressable. You must you must target only the instance, not the whole list.
Carsten Bormann: I think Christian has summarized it nicely in the chat.
Vojtěch Vilímek: Okay. It is what it is. I think this comes from the fact that if you have list users, you in the XML you just put a lot of XML users tag on the same level. You have you have no enclosing tag. We can jump to the CoRECONF but there is also a we can I want to present the work on the YANG stand-ins. I don't know how many slides I have, three? Yes. So basically the problem with the YANG is it comes from XML and almost everything is based on string type. So IP addresses are strings with restrictions, MAC addresses are strings with restrictions, dates are strings, everything is string basically. And in CBOR we have better representation for all some of those, so the YANG stand-in is basically a patch to the YANG type definitions. Stringly typed languages, yes. And yes, it was present I think we can also—so the problem is that we want to have the the group the set of possible stand-in types or the encoding rules for given type that is replacing the string type, the previous YANG string type, with the CBOR better alternative, more efficient one. We want this set to be extensible. So the YANG stand-in file is exactly for that. And we can see a nice example of a config-false list here. Basically we want to create a mapping between the stand-in which is identity leaf—so obviously the module is simplified to fit it on the slide—and the identity-ref type would have a base that is stand-in rule or encoding rule or something like that. And if you want to define a new stand-in encoding rule, you just derive the identity and define in the description define what it how it it should be encoded. And the types means that you always replace type—oh—you always replace given type with the stand-in rule, or SIDs if you want to do it only for given elements or nodes schema nodes in the in the data model. Is it clear? May I continue?
Vojtěch Vilímek: Okay. And I want to propose a new change. The problem with unions is that YANG unions are weird. And Carsten also I think asked about it. Is that when you have a enumeration inside a union, you must use the string names because the union may contain multiple enumerations and the each enumeration can contain the same same enum and it is valid. It is it was designed to be that way. Maria is asking if the stand-ins should be part of the CoRECONF [draft-ietf-core-comi] and I would say yes. I think we should say it is a must.
Carsten Bormann: Yeah, so the the the way I read this fledgling agreement here is that we will have a stand-in file that will be in the CoRECONF specification.
Vojtěch Vilímek: I thought this stand-in file could be a standalone RFC and the CoRECONF would reference it. But either way, it is I am okay with that.
Carsten Bormann: So defining what a stand-in file is is part of the stand-in document. Defining the actual value for the stand-in file that is applicable to CoRECONF could be something we could do in CoRECONF. And I would consider it a major achievement if we actually have a static, a single static stand-in file that describes CoRECONF. Of course static things never really stay static, but for the first five years or so of using CoRECONF, we could use a constant static stand-in file.
Vojtěch Vilímek: In the end it looks like I'll have or somebody else would have to walk over most of the major major existing YANG files already defined for RFCs. At least RFC 9911 needs a thorough walk-through. Today I have found dotted-quad which is also string which encodes normally integer 32 bits, and this is another thing which should be, I think, inside the inside the SID file for CoRECONF. Basically everything covered by 9911 should, I think, be inside that SID file. And yeah, that's it. Also another part of this is probably adoption of the of the stand-in of the stand-in draft into the working group so that we can we can move it together forward with with the CoRECONF, because I think we can't make CoRECONF an RFC without making stand-ins an RFC. Am I right?
Carsten Bormann: I agree.
Vojtěch Vilímek: To the dotted-quad, it is already included in the current revision of the draft. I pushed it pushed it there because it is used by the OSPF model quite heavily.
Carsten Bormann: So just to parameterize the previous discussion, I just looked at the YANG modules that are provided by IANA and there are 3,836 occurrences of the word "union" there.
Vojtěch Vilímek: So we can make a bet how many of them are right.
Carsten Bormann: Yeah, we could help get some help from an LLM. I think this would be an allowed thing at this point because we have no chance actually managing all those 3,836—well, this includes multiple revisions of things and so on, but it's a large number.
Vojtěch Vilímek: Okay, Maria? Maria is in the queue, please? Not? Okay. And also I want to add we have with Maria and I have a some talks about the BGP-YANG and basically the unions are pretty funny in the YANG, to say it politely.
Carsten Bormann: I think there is general agreement about that.
Vojtěch Vilímek: Yeah, with the BGP-YANG, there is another funny thing. Well, there are multiple funny things. There are things like there are BGP large communities and BGP extended communities and such, and these are heavily specified as string representations in a specific in a specific way and the working group is like, "Well, we want the string and we don't we don't want these 8 bytes." And also there is the key of the whole of the whole structure which is probably going to become a union because I was so heavily complaining that indexing BGP neighbors just by remote addresses is wrong. So it's going to become something something weird. And there will be the string string dichotomy, the whole the string collision problem inside the BGP-YANG probably standardized. It's going to be very funny. Lost audio? I also I don't know if it was by design or if she meant to do that. So back to the PR. Are you okay with my proposal? Because basically I I hope that this way the most of the string usage usage of union bits and enumerations could have a nice binary representation.
Carsten Bormann: Yeah, I haven't fully analyzed this, but you are expressing a really strong desire that many of us have. So whatever we can do to get there would be worth the effort, would be worth the effort.
Vojtěch Vilímek: Okay. And closing with CoRECONF [draft-ietf-core-comi]. I read the CoRECONF. I think I have almost complete implementation in Python and the only thing I stumbled at upon is that when you create an event subscription, you send a GET with observe option and Maria, the "do it in binary," it does not work. It does not work because it is ambiguous and the server have no way to distinguish the unions enumerations or bits if there are more than one or or if the values values collide. Well, I say if the values collide then the then the YANG is bad and we should redefine the YANG. It's it's more like if somebody does things wrong, it should break and we should not try to we should not like appease everybody who wants to put their strings without without caring. I I like your proposal but I think it is such a change that we would need a bis draft for that, not just erratum, because it like changes the encoding in a really breaking way. Okay, if it's it I didn't I missed that it's about erratum. If it's if it's erratum, let's do it the least intrusive way and let's push for a bis sometime later. The thing is that the YANG stand-in is an RFC, so such like an extension when you implement it, you have the better better types and so on, and if you don't, you just use the bare YANG-CBOR and you are good. So we could possibly do it in the YANG stand-ins but I don't know. I'm I am I have don't have a strong opinion about that.
Carsten Bormann: Yeah, so I would just was starting to type that we could require stand-ins in CoRECONF. I think that's what we kind of agreed about stand-ins. But then we would have to be somewhat careful of not putting the whole kitchen thing in there but really the things like date-times and IP addresses but not everything else. I mean dotted-quads is kind of on the line but probably belongs into the same class as IP addresses, but we should try to limit this a little bit. And then we have to go ahead and look at these 3,800-something cases and filter them by what actually will be impacted by that and we have to understand the criteria of what will be impacted before we do that.
Vojtěch Vilímek: Do we really want to do that? Do we want to change I think that like saying that the CBOR encoding is different way that the string the YANG YANG designers imagined it to be. I think it is okay and I don't think it should break anywhere because if you restrict the string, you should restrict only the existing values, and if you restrict the existing values—okay, nice. So we are running out of time. Do you have time to continue or should we postpone it to the next interim? No comment, okay, so I will continue.
Michael Richardson: I'm going at the bottom of the hour, but I have three or four minutes, but yeah.
Vojtěch Vilímek: Okay. So only bug I found or is it only bug? So when you want to subscribe to event stream in CoAP in CoRECONF, you send a GET with observe option and the text says each response carries a one or multiple notifications. And I thought about it and if I have a constrained node which creates an event notification once a day and I just booted the device and I want to subscribe it, it could happen that the device don't have any notifications, so it could not fulfill this restriction, this rule, and so it will just wait for the—hi Carsten. Okay, Christian.
Christian Amsüss: That that sounds like something that should just say any any number of notifications because if there's none there, like CoAP Observe [RFC 7641] can delay indefinitely until there's a response, but I think it's a way more compatible option to allow sending something empty. And if there is any legal empty option there, I don't know CoRECONF that well, if if this is a list, sending an empty list is probably something worth considering.
Vojtěch Vilímek: I think there is a good reason why there is one or multiple. And I think the only exception for having the possibility of sending empty list is when you creating the subscription because why would you then send the empty list or you could try to test the connection? Hmm.
Carsten Bormann: Well normally you get the the current value of the resource if you do a GET with an observe option, so you know where to start.
Vojtěch Vilímek: Yes, but when you have a constrained device which creates notification once a day and you just boot it, you don't have any notifications that you could send, you could put in the response for for the GET. So you you cannot fulfill the rule, "carries one or multiple notifications."
Carsten Bormann: Ah, the value of the resource is the notification.
Christian Amsüss: This is about YANG notifications, not about notifications as in observe responses, right?
Carsten Bormann: Oh, okay. Sorry about that. Oh, sorry. It is implicit, yes. Everything in the CoRECONF is YANG modeled. So if we talk about notifications, they are basically YANG notifications.
Carsten Bormann: Every word has at least two meanings here. Yes.
Vojtěch Vilímek: So my fix to that is I propose that it is fixed by saying if if this request is the subscription initiator, you can respond with empty notification list, otherwise you reply the reply must carry carry at least one notification.
Christian Amsüss: I'd be careful about being the initial one because you can update an observation and then you should really get something back and it's not this I think observations are deliberately open a bit to not require that this is a continuous stream or that it could just be like restarting the observation. So I think it's really fine to not have any notifications as a response no matter whether it's the first notification or whether there's for example Max-Age that says once in an hour I should really make some noise or just check whether the subscriber is active. And if the latest representation of the resource is this is an empty list of of YANG notifications, then that's real I think that should be fine as well.
Vojtěch Vilímek: Okay. Also I want to add to you said that CoAP don't can wait indefinitely. I am not sure if it is true, because there are some time time-outs, aren't they?
Christian Amsüss: That that depends on which precise transport and which reliability setting in that transport. So it's it's complicated. In some situations it can it can wait indefinitely but that's something for which the CoAP abstraction is there. From the application point of view, you kind of just start the observation and yeah, it's good practice to send something soon-ish just so that the client doesn't get completely confused.
Vojtěch Vilímek: Okay. I think we come to nice solution. So this is just like an idea. The problem is that the TCP the CoAP messages has like six I think Maria has more info about that, but basically the throughput of the CoAP over UDP is pretty much limited because of some time-outs and restrictions about reusing IDs and number of the other space of the IDs. Okay, Maria.
Maria Matějka: Yeah, it's it's basically that CoAP over UDP needs some time-outs on reusing message IDs and message IDs are only 16 bits, which means I can't send more than like 2 megabits per second or something like that if I if I do the most most bulky stuff ever. Yeah, and one variant is allow TCP CoAP over TCP [RFC 8323] for CoRECONF. Another variant is extend and add an extension for CoAP over UDP to add an option saying this is actually an extension to the message ID. I have no idea whether this or that is is good. The only thing is if I'd like to see just like several paragraphs in the CoRECONF draft saying that if UDP has bad throughput, use TCP or something like if or use it or resolve it with the other way with extending the CoAP over UDP. I don't have an issue with any of that, just noting this.
Carsten Bormann: Yeah, so the current text says CoRECONF uses UDP. And I think that's not exactly what we should do but we should actually say something about transport options and say that it's the the usual way of using CoRECONF in constrained environments to use the UDP version for many reasons, but that we also support other transports. And we probably have to think about that a little bit more, how do we actually do this? But I think it's a normal thing to do that and we we turn the the question of "What is CoRECONF?" into the question of "What are the transport options?"
Vojtěch Vilímek: Okay, sounds reasonable. Carsten, you also was partly against the the high-performing high-performance text in the document because the I think even though the goals are a bit different, the choices made along the way are pretty much the same. And I think if if we want to use Maria have definitely say any something about QUIC.
Carsten Bormann: Yeah, we probably should avoid the term "high performance computing" because it's not the computing that's the problem here. We have implementations that require high performance and in the CoRE environment, we are no foreigners to high performance. So for several years, the Californium CoAP server was the fastest web server you could get. So we can do high performance and we want to be able to do high performance. But we we need to be careful not mixing the the requirements.
Vojtěch Vilímek: Okay. So you would rather have it in a in a separate extension or something like that than in the I just would like to have a section in the document that talks about transport options that kind of says the normal way to do to use CoRECONF in a constrained environment is UDP, and here are the transport selections if your reason for using CoRECONF isn't that you live in a constrained environment but that you want to have high performance. Okay. This sounds like a good solution, so one section about the other options and why one why the implementation should should choose one of them.
Vojtěch Vilímek: And the last two slides are—the CoRECONF has like right now two ways of schema data schema nodes discovery and it is one of them is the link format in on the well-known path and the other is the YANG library [RFC 8525] which has draft to have constrained YANG library that is not that much of an resource footprint. And the problem is that you if you have so the thing is that we come from the bird which will have a lot of data in the in the data model, and the lists can get quite large easily. And the problem with the CoAP right now the CoRECONF right now, sorry, is that when you trying to trying to get a resource of a list, you can get the parent of the list to get the whole package or you can get one instance or several instance when you list them list them when you list the instances you want. But you need to know which instances you want to get and when you don't know what interfaces are available on the system, you have to get larger piece which is inefficient. So this this is the reason rational about why I want to put the the list pagination inside the CoRECONF as a soft requirement. Do you have some comments to that?
Carsten Bormann: I think the it's pretty obvious that something like pagination is needed if you have non-trivial servers. The the way CoRECONF was developed was we always were assuming that the servers are the constrained systems and the clients have more capabilities. So if you don't have a light bulb with 300 nodes, then this is not a problem. You don't need pagination. But being able for a server to declare that it is not able to process a response with 10,000 entries is I think pretty important. And we have something similar in the block-wise document [RFC 7959] where a client can essentially say there is a limit to the size of of the package you can throw at me. And that that option, that CoAP option, can be sent at essentially at any point in time and the server can essentially ignore it as long as it stays under the limit. And I think that's maybe a model for for designing a pagination that is a little bit less intrusive than the various pagination mechanisms we have.
Vojtěch Vilímek: I think that the iterator pattern is a good fit because when you have the ability to restrict the number of nodes that is sent in the packet, you can reuse the message size basically as an request. And I also think if you have simple model, if you are are lazy and you have simple model which has like one list and you put everything in there, it gets quite painful when you don't know the the instantiated entries.
Carsten Bormann: Yeah, I think that's a great subject for a dedicated interim and or off-list discussion. We have something called the "Series Transfer Pattern" [draft-ietf-core-responses] and I think it makes sense to think about this in the context of the Series Transfer Pattern, but I don't know what that exactly means at this point. So let's have a separate discussion about that.
Vojtěch Vilímek: Okay, okay. I have no idea what it what it is, so I will have to have a look at that. Have a look at that. And this is the end. Here I want to discuss several things. I want to talk about working group adoptions of the mentioned drafts and also I want to comment on Carsten's comments. Carsten commented on the YANG-to-link repo. The YANG-to-link repo is repo of the NetMod working group. It was so I I listened to the session of IETF 125 of both NetConf and NetMod and I am not happy that the inter-working group cooperation in what state the inter-working group cooperation is.
Carsten Bormann: Yeah, so the the actual backbone of inter-working group cooperation is of course people who are in both working groups. So given that essentially you are, you might be the new flag bearer of the cooperation between the working groups. And yes, I agree we need to get better than we are at the moment.
Vojtěch Vilímek: Because on the meeting the Ken Watsen said something like, "We are creating new version of YANG and we should not talk too much loudly about it because Carsten will come and he will say that he also wants a CBOR examples in the document and so on." So I of course.
Carsten Bormann: But there is no doubt that this yeah, you cannot keep it quiet, you cannot have a new version of YANG and not talk about it, so there's nothing that can protect here.
Vojtěch Vilímek: So I should write the PR, you say?
Carsten Bormann: Well there are several several levels of escalation, so let's be careful about that. But we can always write drafts that are parallel to any drafts that NetMod does that provide the CBOR answers. So that's one way of doing this without wagging the dog.
Vojtěch Vilímek: Okay, I just feel like it could I can imagine a world where the NetMod working group just like before they publish a before they put the document in the last call, they just ask us, "Hey, we have a document here, are you okay with that? Do you have some comments or so or what not?" but I feel like they are like independent groups and they don't look much around and it's sad.
Carsten Bormann: Yeah, as I said, the actual cooperation is happening through people who are in both working groups. Okay.
Vojtěch Vilímek: Not a really happy message, but I understand. I think that's just reality. Okay, this is all from my side.
Marco Tiloca: Thank you, Vojtěch, for preparing all this, leading all this and the great discussion, even over time. Just one point of complement, I put in the chat a link to a draft that was mentioned before on the series transfer pattern [draft-ietf-core-responses] if you're interested in having a look and it's also captured in the minutes. Right now the note is the fifth from the last comment. And to conclude, I just wanted to remind that we do have one working group document right now in working group last call until May the 4th, that is [draft-ietf-core-oscore-key-limits]. The fourth be with you. So please have a look and provide your feedback. Link in the chat. Okay. I guess we are done for today. Thanks a lot for your time. Talk to you latest in two weeks.
Carsten Bormann: Bye.
Marco Tiloca: Thank you, bye-bye.