Session Date/Time: 06 May 2026 14:00
Marco Tiloca: And we are at the top of the hour now, but as usual, let's wait four minutes or so for more people to join including our main speaker today, Esko. Hi, Michael.
Michael Richardson: Hi.
Marco Tiloca: Yes, now it works.
Michael Richardson: It works.
Maria Matějka: But where is he in the participant list? Oh, there he is.
Marco Tiloca: I've just seen him. It wasn't around until three seconds ago. Hi, Esko.
Esko Dijk: Hey everyone.
Marco Tiloca: We are just waiting the usual three or four minutes before starting.
Esko Dijk: Okay.
Marco Tiloca: Okay, it's four past now, so officially welcome everyone again. This is the interim meeting of the CoRE working group. I'm Marco, my co-chairs are Jaime and Carsten. And of course, the Note Well applies. Get familiar with that if you are not already. If you are personally aware of any IPR or patents reading against technical specification, you have to declare that or not participate in the discussion. This is also and especially about our code of conduct, so please be nice and professional with one another. The agenda items for today are three that were all proposed by Esko, if I'm correct. The first two ones are very much related with one another and and also to work ongoing in the ANIMA working group. The third one is about the working group document we have here on draft-ietf-core-coap-pubsub. And if I haven't missed any mail from the datatracker, I think we have no slides from you Esko, right? Just discussion.
Esko Dijk: Right. I can share the screen.
Marco Tiloca: Definitely. The link to the notes is in the chat. I'll try to take notes. You are very welcome to help. There you go.
Esko Dijk: So, which topic should we start first?
Marco Tiloca: I guess the first two ones.
Esko Dijk: Okay, I can do the screen share request. Do you want to share the screen? Yes. There we go. So, I think I'll start with this item here. So, I've opened the GitHub page and made the text a bit larger. So, can you see this?
Marco Tiloca: You could zoom in one or two more.
Esko Dijk: Something like this?
Marco Tiloca: Yeah, much better.
Esko Dijk: Yeah, so these are two items that are related basically. And this also links back to a discussion we had earlier. So, this is for the ANIMA working group. We have a join proxy basically that advertises a service for a new node to join a mesh network. And the new node uses discovery to find join proxies around it and then select one. So, any node that's already part of the mesh network can act as a join proxy typically. And the discovery that we currently describe in the draft, it's called constrained join proxy, that uses now CoAP discovery. So, I've listed here the original example in the draft using CoAP discovery. And this is something we talked about before. So, there is a request for a resource type discovering on .well-known/core using multicast. It's specifically link-local multicast, so only nearby join proxies can be reached of course. The new node is still not using any security because it's not part of the network yet, so it's basically using unsecured CoAP discovery here. And then join proxies can respond with a certain payload, which is a link in this case listed here, which contains the link-local IP address here. And now the thing was that this address here is included because it had to be included according to the rules for link format, while it's not really required because the client that's doing the discovery does not use these characters here. So, it just uses the IP address of the discovery response to talk to a particular join proxy over link-local communication. So, this address is there but it's ignored. So, then the issue here is about, well, can we make this payload shorter by just removing the address that is not being used? So, there I looked at it again and found a method that you could use, which is making a much shorter URL here listed here. So, basically it drops here the scheme and it drops the complete hostname, makes it basically zero length. And the port is still there, and the rest of the link is the same. And yeah, the idea was here you could make it shorter and all the relevant information is still in there. The fact that the scheme is CoAPS, this is what the client already knows. It's actually programmed to use CoAPS to reach on the port so it cannot even do anything else. So, this information is not relevant also, so it's also left out. And that's made possible by this ABNF that's listed here. So, instead of an absolute URI, you basically use the URI reference and this is the form relative-ref. And the authority is here a host basically. So, the idea is that you make that host a registered-name here and then you can make a registered-name zero length, which is done by this expression. So, the end up with this valid link, link format, although it looks rather confusing because most people haven't seen a link like this before most likely. So, it's never has never been used before in any examples as far as I know.
Michael Richardson: And it's it is it is used actually regularly, um, in browsers to, um, refer to something else without changing the scheme so they don't know if you got there by HTTP or HTTPS and so websites actually will use that slash slash to, um, go to a different site whilst keeping the same scheme. So, people don't see it but but um it's become well-known I would say, um, in that space.
Esko Dijk: Yeah, no I mean in CoRE link format I haven't seen it before. Like, um, yeah, the other type of link, so these are completely relative without any hostname and without slash slash and without the port, so just pointing to the resource itself, or you have a full blown URI basically, so this this is kind of in-between form that you don't see very often here for CoRE link format. Yeah, so the question is like would this be a wise thing to do just to shorten the payload or do we risk something here by doing this? So, one thing I already pointed out in the remark here, there is a semantic mismatch in the returned link because formally if you just leave out the scheme it means, as Michael said, the same scheme, I guess, so the scheme that's used to access here which is CoAP, while the link actually means CoAPS. So, there's a CoAPS so there's a you're kind of by doing this you're kind of making a mistake formally basically. For implementation it doesn't matter, but it's formally not the right one. So, that's why I wanted to bring it up for discussion like does this seem like a okay usage or, yeah, do we see some issues here or or do we want to avoid misusing the formalism here?
Carsten Bormann: So basically this is no longer URI, this is a URI reference. And that's fine because we do URI references there, so that's that's not a new thing. And the usage of a slash slash without a scheme in front of it also is canonical as Michael has pointed out. Now the interesting part is the empty hostname. Um, I'm not used to seeing that and I haven't prepared for this meeting looking at the the resolution rules in 3986. So, in 3986 there are rules what you do when particular parts are missing. And I haven't read this in a couple of years or so, so I think it would be a good thing to check the resolution text in 3986 whether it has conflicting instructions. So, if it doesn't say anything, I don't see a big problem here, but if it says you have to do X and we are not doing X that's probably not so good. Now the other thing about mixing up the CoAP scheme and and the CoAPS scheme. We do this with HTTP all the time, so um, this this is maybe something that is not supported by the the written specifications very much but we have lots of client software that sees, oh, somebody is using an HTTP URI and let's do an HTTPS URI instead. Um, so this is not entirely unheard of, even if I don't know if it has been used for CoAP. So I really wonder what an empty hostname with a port number does to your random URI implementation, but then on the other hand these are very specialized clients, so maybe giving them a little bit of leeway is is okay here.
Esko Dijk: Yeah, so my thought was it it would at least not hopefully not contact a random host or the wrong host, but yeah, that might depend on the rules of course what to do in that case.
Carsten Bormann: Yeah, so we we have this weird situation that the context URI for a multicast response is anchored at the the authority that you get by looking at the multicast response. So, that's something that of course HTTP doesn't do because it doesn't have multicast, um, but I think that that's not an abuse here, but but this just fits into the architecture.
Esko Dijk: It's a unicast response by the way. So that...
Carsten Bormann: Yeah, so certainly, but yeah, normally you would think that the authority you have used to contact your peer also is the authority part of the anchor that you are using to resolve relative URIs. And that's not the case here. It's not the request, it's the response that tells you that, and it's the transport address in the response. So we are already making this jump. So making it a little bit further by by composing a different port number in there. Yeah, we haven't said that 10 years ago, but it I think it's it doesn't violate my taste very much, but we should actually still read the the text, the specification text and find out whether they say anything about that.
Esko Dijk: Yeah, that sounds like a good idea. Okay.
Marco Tiloca: Right, so any other people want to say something about this or... Yeah, Marco here. Just a thought. I guess it wasn't part of the discussion and design of link format, but you have a very particular resource type here. So, I wonder if it helps at least from a presentation point of view to say that with that resource type you are essentially implying CoAPS as a scheme and you are implying a particular address from the presence of an empty hostname.
Esko Dijk: Yeah, that's right. So, I think the current idea was that the address you're going to use per this protocol is basically the yeah the source address of that response. So, you basically take that IP address and that avoids having to do any parsing in there. And yeah, this could be made explicit I think if we go for this solution then you basically have this resource type here with some associated semantics like you have to access it via CoAPS for example.
Marco Tiloca: Yeah, so admittedly this is probably stretching the the original intention of the resource type target attribute, but if it can be used somewhat as a label, a tag for what this weird URI reference means, why not.
Esko Dijk: Yeah, that's right. You can basically restrict yeah restrict the scheme that can be used to access for example.
Marco Tiloca: Yeah.
Maria Matějka: So, if if we were using OSCORE, how would the picture change here?
Esko Dijk: Yeah, with OSCORE that uses the normal CoAP scheme, but you still have to yeah, for example, say that it needs to be on a different port if you want if you want to host that at a different port.
Maria Matějka: Well, you use the CoAP scheme if you use OSCORE alone. If you use OSCORE and then around it you further use DTLS, then you are back to the CoAPS scheme.
Esko Dijk: Yeah, this is about OSCORE alone, right?
Maria Matějka: Yeah. So, what the resource type probably really says is use security. And whether that is being done by using OSCORE in with the CoAP scheme or by using DTLS as intended here is maybe not something that the resource type says.
Esko Dijk: Well, here it does say it because the specification only supports DTLS security at this moment.
Maria Matějka: Right, but that could theoretically change. And I'm just trying to to feel my way through what would happen if if we were to change.
Esko Dijk: Yeah, for another security you would also have another resource type here. So, you can basically query with wildcards in that case to to get both security options. Or or you could use another property there are like a custom property or the interface property to to say something more about the resource type, but that's that's probably not the right way. So, yeah, so I think this is really associated to DTLS at the moment and also the resources that you will find behind here. So, it's also kind of summarizing that you will find all the .well-known/bruski and EST resources that you rely on for the onboarding. And you will find it at this port. So, that's basically a sort of a multiple in one discovery. So, it's basically advertising join proxy functionality which is a whole set of resources that yeah that are well-known and that you know are there. And yeah, if you contact another port then it's no guarantee that there will be CoAP or that there will be any of those resources.
Maria Matějka: Okay, so I'm looking forward to see the text for what you just said.
Esko Dijk: Yeah, maybe just have I can do a quick scan of the URI handling at least and propose a text for this I think to clarify that a bit more. Okay. So you want want to be kept in the loop because this is the ANIMA working group and we are now at CoRE, but I can post it to CoRE as well if you're okay with that.
Marco Tiloca: Yeah, I think it's very useful to remain in the loop.
Esko Dijk: Yeah, it's should be a good idea. Yeah, so your regular design team meeting is a little bit unfortunate in that it is in the half hour before the CoRE meeting, but maybe I have to make room for that in some way.
Esko Dijk: Yeah, okay. That's we also discuss other things there, so we can also do it at the CoRE interim of course. I think that the three of us can come to this meeting if we want Carsten.
Carsten Bormann: Thank you.
Esko Dijk: Yeah, okay. So any other comments on this? Otherwise we could move to the next one, which is basically another way to achieve the same goal. So, I will bring that up. I think this is it. So, this is basically a different approach where we say we put this port not on the usual slot of the port, but we put it in an CoRE link format attribute. So here's first the original example again and this is now version that uses the port number in a new attribute which is called JP, a short name just because we can make it short. Um, it still has the resource type here. And basically this now has the semantics like, okay, it is hosted at a port and if you want to know the port you need to to take it from this property. And this has nothing at all in URIs basically an empty thing, which is I think allowed. Um, and then it refers I think formally to the root resource if there's nothing here. Maybe it could be a single slash as well. But I thought actually that completely empty is also allowed. So this is completely different way of doing the same thing. So the client still has all the information that it needs basically protocol and and port. And that's it.
Carsten Bormann: So, if if you write nothing then you have a relative URI that points through to the resource that you did the request at. So, you would still be in .well-known/core. And if you put in a slash then you are at the root of of the host of the server. Um, I don't know where you actually want to come out.
Esko Dijk: Yeah, so the it's at a different port, so the if there's any resource here on this default port, which is 5683, yeah, we we don't need to point at anything actually. So that that's the reason that let's point at the shortest thing that we have, which is empty, which is .well-known/core fine, but that's not where we want to be for those resources. So they those are .well-known/bruski and .well-known/est resources here what hosted at a different scheme and a different port. So it's basically just nothing a dummy.
Carsten Bormann: Okay, so by by not going to the root directory but staying in .well-known/core, you do any damage you may be doing to .well-known/core, which is probably better from a BCP 190 point of view, um, because you potentially localize localized the damage. But do do you need this when you have the other thing?
Esko Dijk: Yeah, I mean these brackets here with with link, yeah, I think you need something there right for link format so it's always these pair of...
Carsten Bormann: Well but do you need the whole thing? Do you need the JP if you can do the slash slash colon?
Esko Dijk: Um, slash slash colon yeah, that's the previous one. So, this is an alternative basically. So if you're doing this one then you don't need the other method basically and vice versa.
Carsten Bormann: Okay. So, at some point you probably want to decide which of the two you do and not support both.
Esko Dijk: Yeah, that that was the goal, let's see to to get some input and then see if any one of those could could work and and if so which is the least the least ugly solution. Yeah. Good. Thank you.
Marco Tiloca: Right, so any other comments on this or things I might have missed? Already explains a bit about the linking to .well-known/core using the CoAP protocol. Oh yeah, the other thing about not doing much harm was that also the client would then probably not recognize the resource type if it if it doesn't know about the join proxy resource type then it's yeah, it could be unlikely that it will start using it. Like, I don't know, it lets let's write some data to it, but well, you never know of course. Okay, so any other final comments? Otherwise I can maybe move to the next one. So, this was the pubsub issue. Okay, nothing I guess. Go ahead with the next Esko. Yeah. Let's go ahead with the next. Let's see, where do we get pubsub? This was constrained voucher. This was other things. I think it was higher up, pubsub, yeah, this one I think was the final thing in thread. So, this was something that was already discussed on the mailing list. Can you zoom in again? Yeah, make it a little bit bigger. I think should be okay like this. You paid you paid for the whole width of the screen. Oh yeah. A lot of white here, right? Yeah, so this was basically about pubsub there was one particular item that there was this core.ps.data resource type. So, the interesting thing about the spec was that this data type was used by default and it had to be there, so there always had to be this type defined and it was also a default and the specification did not really describe, okay, what what happens if there's another data type here or or when could this happen. So, Jaime then basically explained to me what the idea was, was basically that you could have a deployment that that uses pubsub but as maybe some custom extension and that all the players involved there use a different data type or could use an additional resource type. So, something like core.ps.data2 or something .v2. It doesn't matter much what it is, but something else. So, the question was like like do we expect others to use it and is it still compatible in that way? So, I think the resolution was basically that you yeah you can have different values, but we don't expect that clients and servers that use different values for the resource type that they will interoperate. So, if you do it basically someone who makes designs that system will have to make sure that it either everyone uses the new value or there is some interoperation in the sense that clients for example would would recognize both of these resource types and act accordingly.
Carsten Bormann: So let me try to get a little bit of context. The resource type here is not something that you get from discovery, from a link format document, but from the link that is part of the umbrella resource, what's the name of that in pubsub?
Esko Dijk: Yeah, it's actually both. So you can just use link format and go and discover those resources. So you you get those particular resources that are used for the publishing and subscribing of data. So not not for the overall configuration, but just for the purely for the data publishing and subscribing. So they have a very particular resource type which is this and you can do a link format discovery to find those and then access those. That's described in the document. And you also get it from the yeah what's the name again? Sorry I forgot meanwhile, but there is this higher level configuration resource that that is at the top. And that there you also get yeah like the configuration of what is the resource type of your publish subscribe resource, which is then by default this type, but it can be another one. So that's a mandatory thing even if you create a topic then it must also be included what is the resource type of your publish subscribe resource, which is then by default this type, but it can be another one.
Carsten Bormann: Yeah, so I'm trying to to separate in my mind the normal case where you find the pubsub resource and the pubsub resource tells you, oh, by the way, this is my data resource. And this data resource follows a certain protocol, which is identified by having the resource type core.ps.data. Right. Now the same resource may follow other protocols as well. Um, so I think we need to keep open the possibility that it follows other protocols. We cannot forbid having additional resource types here or or even interface types.
Esko Dijk: Yeah, that that's correct. So if you do link format discovery you would also see that that same resource can have multiple RT types that are all listed there. And the only thing is that for pubsub itself it basically does not describe all these types. So, for example, if it has three different ones, it it will only have core.ps.data this one described in the pubsub resource because the idea is that it has yeah it basically defines only a single way in which that resource can be accessed with pubsub operations. And that you can also access it with other protocols in other ways, that's kind of irrelevant for that. So, if you want to know that information you you can't read that from the top-level pubsub resource, you have to do link format discovery to find that basically. So like, okay, give me all the give me this link for example with all the RTs that I can use on that. And one of them will be core.ps.data in that case. So it's basically every topic so to speak supports a single type describing how to access that yeah data resource with with pubsub operations. So that's what we have currently and I think the idea was to try to clarify that with some additional text. And this will also support multiple RTs in general for the resource. Good.
Carsten Bormann: So the the general big picture somebody might have another resource type that it wants to advertise for the data resource. That's one thing. The other thing is the pubsub protocol itself may want to evolve and in 10 years from now we might may have an idea for a better data resource resource type. Um, and this should just fit in. We shouldn't shoot ourselves in the foot make it impossible making it impossible to say that.
Esko Dijk: Yeah, so that would be done by using a new resource type here. So at the moment you create a topic for example and then it's basically required that the the client, so all the clients who will access that, will will know about the new type as well.
Carsten Bormann: Yeah, it could also offer offer both core.ps.data and core.ps.data_new. And then the client could decide whether it it does the access using core.ps.data or using core.ps.data_new.
Esko Dijk: Yeah, well that's an important point I think because currently although the resource can support these multiple RTs, it has to choose one for the configuration of pubsub. So there is currently no no option to say, okay, I support PS1 and PS2 and and have that yeah configured. So it has to support one of them, so that would be PS2 typically. So that means clients that only know about PS1 type then would not be able to recognize that because the resource...
Carsten Bormann: Yeah, but then you have a big deployment problem. Um, so I think being able to do a smooth introduction of of a new resource type is is would be a good thing.
Esko Dijk: Yeah. So so one way to do that would be a change that we allow a string value then with spaces and then have multiple resource type which is space-separated. So that's similar as link format. So I'm not sure if that does that look like the best way because you you could also have other things like arrays or whatever. I'm not even sure what format was used currently was it CBOR? I don't I have to look it up but so you can just...
Carsten Bormann: Yeah, we all hate these space-separated things, but on the other hand since you already need to do it for link format, maybe that is still the best way to do it. But logically it's an array, yes.
Esko Dijk: Mhm. Yeah. So so something like that would need to be introduced then if we want to make that that's yeah evolving possible. Sounds good to me. Yeah, also sounds okay to me. I was also okay with the old approach by the way but yeah. Yeah, maybe we can try to get some text then for this approach see if we can support multiple types.
Marco Tiloca: Yeah, in the chat I've just added not proposed text, I would say, but a proposed direction along what you were discussing. I hope there's especially two spots in the document I think where the resource type is is discussed around this context and it can be mentioned that that particular resource type as used in this document, yeah, is according to what is defined in this document but in general alternative and or additional resource types can be introduced in the future by other specifications.
Carsten Bormann: Right. Yeah, that's. Yeah, so this this would simply be identified as an extension point. So if somebody wants to extend the capabilities of the data object then they would define a new resource type.
Marco Tiloca: Great, the extension point is already there. At the end of the day it's resource type as intended and and to be used in link format. We are more preventing ossification around this particular resource type value. Correct. Good.
Esko Dijk: All right, so yeah, this was the last topic I had at least. So I can maybe stop sharing then.
Marco Tiloca: So I could count at least two other mails from Esko related to pubsub but I don't think you had in mind to cover them today, right?
Esko Dijk: Yeah, I think the idea was to make an update so PR there. So this was only about the resource type, right? So, yeah, we had another discussion about other things but I think Jaime had a plan to clarify that in in a PR with new text. So I didn't see any yeah big discussion there. I was okay with the next version. Yeah, we can you can look at the next version and then evaluate. I was okay with the proposed approach at least. Yeah.
Marco Tiloca: Sounds good. Thanks. Also for the early shepherding. Much appreciate.
Esko Dijk: Yeah, yeah too.
Marco Tiloca: Okay, um, so looks like we are at the end of the planned agenda. Any other topics you want to discuss today? Carsten?
Carsten Bormann: Yeah, we we could spend some time given that we haven't exhausted our slot yet discussing the the NIT thing that started on the mailing list a couple of days ago. Um, so if if people don't mind I would like to respond to the email that Vojtěch sent at 3:22 Central European Time. Sure. So I think this is really interesting because we are not doing exactly the same thing here that we are doing in YANG-XML. And the basic idea of SIDs is to essentially provide everything that that hasn't doesn't have to be put into a predicate. Um, so when we have something like maybe somebody can share that mail? NITs not lits, right Esko. We have some NITs with a NIT. Yeah, I'm still trying to find out the link to the exact mail again. It went to the CoRE mailing list 80 minutes ago. Working on it. Thank you. Yeah, again I think we have paid for the whole screen. Um, so if you can scroll down to the various NITs under quick recap. Yeah, that okay that was mine the other further down, sorry, oh that that yeah exactly that one. So what happens here is if we actually have an RPC or or an action we want to identify that RPC or the point where the action is situated using the SID. And that means that the NIT needs to contain that part of the path. So the decision in XML YANG that that the path is relative to the RPC or the action point um doesn't help because we want to cover as much space as possible with the SID so we can get a good compression result. So box/A/B/bound/input/in is actually the attempt to get both the action point and the details of the action into the same NIT and thus into the same SID. So the question of course is how much architectural pain does that produce? Um, but for YANG-CBOR it's it's definitely a much more efficient way because the we essentially cover the whole spring. We don't need a context somewhere. So right now in fetch in CORECONF for instance we use these instance identifiers to actually point to specific places. Well, okay, these are not RPCs. So in POST I'm trying to remember how how that looks like. Um, so in POST similar considerations will apply but I will have to look up what the details are. So that is the the basic observation here. And that's why I would expect the NITs to actually look essentially the same way with the mod colon with the /mod colon added to what Vojtěch wrote. Is that a meaningful reply?
Marco Tiloca: Sorry, one one more time. I because the the point is that the actions or at least the RPCs like live the RPCs are not themselves data nodes so they don't belong they are not they shouldn't be part of the instance identifiers. It is it is much more similar to choice and cases we also do not include them in the path, in the instance path.
Carsten Bormann: Yeah, so one attempt with YANG-CBOR was to avoid having to string encode everything. Um, so we we don't like those predicates which actually have numbers in them and things like that to be included in some URI path. And that essentially makes them available for encoding in the NIT. Okay, but I need to come up with a full example for what I am talking about. We are breaking the YANG context because the YANG says that the instance identifier path contains only data nodes and the RPC itself is not a data node, the input is a data node. Yeah, that's why we introduced this item identifier thing because we didn't like what data nodes did to us. Which one identifier the SID or the NIT? Both. So the what I'm trying to like show is that firstly I thought that if you are going from the schema path to the NIT and if you are going from the instance identifier path to the NIT this approaches are equivalent and I now I don't think so because the instance identifiers are more constrained.
Carsten Bormann: Right, and maybe we need to clarify that but I still think it's the right design decision.
Marco Tiloca: I don't know, I I would say that it it would be simpler to even more restrict the schema path than to come from the instance identifier path because it is complicated or as you can see the all the protocols use different encoding rules and it is it is a mess.
Carsten Bormann: Yeah, but we already have that situation so we're not going to make it worse. Um, you have to know whether the identifiers you're looking at are JSON identifiers or CBOR identifiers. And basically the idea is to encode as much information as possible into the SID. And to do that we have to have it in the NIT.
Esko Dijk: Yes. I just a question wasn't it the case that every unique NIT basically also has a unique SID associated and vice-versa?
Carsten Bormann: I don't parse sentences with the word unique in them because the word unique doesn't mean anything in practice.
Marco Tiloca: Yes, we are trying to create a perfect mapping between SIDs and NITs. This is the goal but...
Carsten Bormann: It's not a bijection. Ah, okay. Not not in two directions. We like it to be a bijection, but the whole thing still works if somebody assigned their own SID for something. The thing that really has to work is that it's a function from the SID to the NIT. So there is only one NIT that a SID stands for.
Esko Dijk: Okay.
Carsten Bormann: And now you maybe understand why I don't like to use the word unique because it could mean about five different things in this context.
Esko Dijk: Yeah, okay. The direction thing is of course important there. Of course.
Carsten Bormann: Yeah and and it creates a lot of confusion that there is an objective that we know we will not be able to meet always, which is that you only have one SID for a NIT. Um, and there is an objective that really is part of the architecture, that there is only one NIT for a SID.
Esko Dijk: Yeah, okay. That's good point. But but I had another question too. So there is the example on the screen like box/A/B/bound and that gets replaced by /mod:bound. So why why is that replacement made? Is it like we we put the box thing in a yeah what's happening there? Is it a module or something or...?
Marco Tiloca: The box the you can ignore the prefix mod, it is just to be correct. And the box and A and B are containers which or lists which means they are only like just for the tree structure internal node in the tree structure. And the bound is an action and the action is something special. It is basically an RPC bound to some node some node in the in the tree. In the tree. And the input and output are the paths of the RPC.
Esko Dijk: Yeah, okay. So, yeah, I think the right so the box and A and B are containers. Okay, so that... And so based on my reading of the standards, I feel like there should be a split on the path exactly where the action lies. Because if you send an action, based on the wording of the XPath context you just stick the action context in the root of the tree, not in the node that you are working with or you are associated with. Which is weird, but you know.
Esko Dijk: Okay, yeah, actions I don't know much about, so um I will trust whatever you you both say about it.
Carsten Bormann: Yeah, a typical example here might be that you have a number of interfaces on your device and you have an action that makes the LED on the interface blink for a short while. And to do that you first have to have a path that points you to the specific interface. So you probably have a predicate somewhere that says you go to eth15 or something like that. And then you still may have parameters that you want to put in for the action. And we can put in both into the same NIT. So the NIT of course wouldn't have the 15, it would just say it's an interface and the predicate that is added to the NIT to actually have the path to the item that gives you the 15.
Marco Tiloca: And what I'm trying to say is that talking about this as talking about NITs as something derived in similar to instance identifiers is wrong.
Carsten Bormann: Okay, we can always work a little bit more on the terminology gymnastics we did for 9254. Um, but that string is different from everything else we have in YANG universe. That's why I think it's a good idea to give it a name.
Esko Dijk: Yeah, only if it helps of course in doing what we want to do.
Carsten Bormann: Yeah, I think it's important to get this right and maybe have a few useful examples that can go into the CORECONF document. Um, and we should probably work on that in the next couple of days. So that's all I had on on this email and I definitely agree with YANG is weird.
Marco Tiloca: Thank you Carsten. So this can continue on the thread and we'll have examples soon. And please triple review what I tried to capture in the notes for sure there's some mistake there. All right, um, which brings us to the AOB again. Anything else you want to discuss today? Okay, hearing none. Um, thanks a lot everyone for the good discussion. Thanks Michael and Vojtěch for helping with the notes. Appreciate. Talk to you in two weeks. Take care.
Esko Dijk: Hey thanks. See you.
Maria Matějka: Thanks. Bye-bye.
Vojtěch Vilímek: See you on the mailing list, bye.