 Good morning. Hello. We'll give it five minutes before we. Get the working group started as. Let people join. All right. How are you going to join? Hey, good. Hey, Nikolai. Give it a few minutes for folks to join usually start at five after. If you drop the meeting notes in the zoom chat, you can add your name. And if you've got a topic specifically like to go over. Add it there. Greetings, Victor. And you say no, we'll get started here in a couple of minutes. Hello, bro. Hello. We'll get started. And about one minute, five after. Meeting notes are in the zoom chat. You can. Add your name and any topic you'd like to discuss today. All right. Okay. So this is the CNF working group. This call is being recorded and the recordings are currently uploaded to CNCS. YouTube playlist for this working group. And. The name of the group may change and locations for recordings and stuff in the future. As we're. In the process of merging things with elephant and creating. The new program for the. Lot of telecom initiative. But in the meantime, we'll continue to meet here until. We've decided on any new change. Is there anyone. Not familiar with this group. What we've been doing in general. For you new. So either of the programs. Let's just get started. I'm going to share my screen. Let's see, we got Gerga and Nikolai. Let's just drop everybody on. Some. Couple of announcements for upcoming events. We have interest for all of us. The. Cloud native. Cube con days. And Guadalajara. It's coming up. And in February. CPS are currently open. I think the next. Well, that'll be the next one. I think North America. There's another one. That'll be happening in. Maybe central US. After that. The cube con club. Native con EU. We currently don't have a collocated event. We've had four cloud native telco days in the past. Trying to see if that one. If we're going to have something like that. It seems like there's an interest for it. But it hadn't. materialized yet. If you do want to see something like that. Then please reach out to. LFN. And the LF event team and express your interest so that they're hearing it. And if there's a demand. And we'll try to work something out. And beyond that's one summit. The CFPs. We're going to close on Friday, but they've been extended to. December 17th. So if you haven't got one in, but did want to, then. Now's the time. Sorry, two questions about the. The. Will you. Stand notification to the fan or like, do you expect that everybody. Separately. To do that. For the. Are you referring to the cloud native telco day? Yes. I think it's a better idea. The more voices they hear. I mean it, you know, if there's some specific thing that we, you think we can do to. Organize, you know, I'm like signing off on something. That's fine. Please put that forward. But for now it's. As many organizations and individuals that are requesting. That we do it. I think it's going to help. Beyond that. Anyone. That's willing to sponsor an event like that. Then I think that helps. You know, get people encouraged that are making those decisions to have it. I know that at least a few companies were looking at sponsoring. The EU event because they were EU companies. So. Okay. Thanks. And about the one summit CFP. Extension where, where was this communicated? I didn't get any. Mail or anything about it. Um, I think. I heard. From Ranny at. Last week, but. Did the website looks like. Uh, listening to just type in the website was updated. So it looks like it's finally updated. I don't know if any. Any type of message or announcement went out. Probably be good to drop it on the. LF. Tech. Slack and other places. Okay. Maybe I missed it. It wasn't. It wasn't updated on the website. Early. And Friday. So I. I didn't even know that it had yet. I think we're still waiting on it to get updated. So yeah. I'm not sure if they actually send out any communication, but if you're not in the right place, you never saw it. But anyways. There's more time. All right. I'll jump into the PRs. If someone has a topic they want to go over, then please add it. Um, guess the one thing I'd like to do is the. Maybe go over. The list of tools and challenges that we're looking at for the. This program that. New program that we're looking at. There's two wiki pages. Does anyone have anything else I'd like to add? You can either write it in or verbalize it. I'll pull up the PR review and then we'll get to some of those topics. So right now, we only have two things. They're both related to this. White paper. And. This newest one. And I don't remember if Nikolai, if this had anything that you had on it. It seems like there's a few different items, but this was trying to address some final pieces in the, the white paper. And. Actually, I need to check some. I tried to mark it. I don't remember if Nikolai, if this had anything that you had on it. I need to check something. I tried to merge. December 2nd. Why is that so old? Oh, that was the problem. Okay. This is a simple change. Linus foundation to Linux foundation. Which I think is what we have in the. In the newest version of this request. Yep. It's there. All right. So the ask on this. Is there anyone not familiar with this white paper? Give a quick overview before I do this one Ted, but. I am not completely familiar with the time. Right. Some pieces. But is it still in a branch, right? Yes. It's still on a branch. All right. So. The, the. Just of it is, it's a follow-up to. Clodinated manifesto. Which was published a couple of months ago now. And this is a follow-up trying to get more specific on the ask. From CSPs. And some of the. Other than maybe particulars on. Removing and be ambiguity or spelling or. Just trying to do some things like that. Some of the more explicit things that were added were. A mutual. Effort between CSPs and vendors to. Take on the responsibility of the change. One of the things pointed out by several people was. What happens if. People creating. CNS platforms, that sort of thing. Or, or I'll say integration pieces for platforms. They're trying to. Make the change to have native components, but. CSPs don't. Change their model for deployment. Their operations management or. Their internal environments to actually match those things. And then. They're held then the creators of CNS are held accountable for. Things not working. Then that would be a problem. So that was one of the major changes. It was already. Understood by the CSPs that were involved, but it wasn't explicit. So. The wording for that's been put through several places, including the introduction. And. Some other stuff around like. Business models and other things to communicate that. This is. The intent is to be mutually beneficial. While. Moving towards this. Different model of. Running the networks. And then the latest change, which I was showing. This one was about. Adding. Pretty straightforward. This white paper and what it's asking is. Is talking about Kubernetes. So not saying that there's other environments that may be used, but. This paper isn't trying to cover all things. It's. That the focus here is a Kubernetes based environments. Is it, is it sort of defined like which flavor of. We're talking about. Like every, every. This throw is different. They are using different run times. Different. Different storage. So the. You'll have to go through the, the individual pieces on the requirements that break out architecture and other pieces, but the. The, the main focus is on being. The vendor, neutral interoperability between. Platforms and trying to support multi cloud, which means. One of the things I think. You've seen in the past. If there's a requirement for. Specific SLAs. That are end up being tied into performance aspects of. A specific flavor or distribution. And then you're trying to also do multi cloud and that can be problematic and that's partly where the. Mutual effort to support. Each other. CSP is trying to meet. Partway to adjust those SLAs or anything else. So the very first thing would be vendor neutral. On the distribution. So first starting there. And. There's my problem here. There is no vendor neutral. Yeah. It was, you know, you might have seen itself cannot even start the continent. You have to have a continent and you have to have a senior plugin. And all of these are making the, like the end result. Vendor specific. It's not, it's a dream to have vendor. So you can have a goal. And you try to meet it as close as you can. And then you have the exceptions. So yes, you can, you can say it's a dream, but that doesn't mean that you can't aim for it. Yes, that's true. All right, I'm going to, I, so I just merged that one pull request from Philippe from orange. That was related to the request from ill deco and a few other folks. So we have. At this point, like, there's enough approvals from everyone that we're going to move forward on this, but I'm trying to check to see if there's what's left as far as resolved or unresolved. All right, I'm going to close this one out. This is about terms cloud infrastructure and other things, but this paper is about. The idea of the operation, the, the practices use this, the technology, how it's how you build your environment with the technology. And ideally how the technology responds in that environment that it's following cloud native principles. What we're really saying is it's designed to run in these environments and it behaves with the expectations or environment that when we say native, that's what that's about. So this just terminology and teaching it to be more generic go ahead. Do you think that we need to clarify that in the document or like what we have is enough to what you're already explained it. I feel like it's been said over and over it's kind of frustrating to have to say when you say native, you don't actually mean native to that environment. You can do something else. Cloud native doesn't mean cloud computing. You can do cloud computing but not try to design something to be native to the cloud. But you can still have technology that you would just say it's called computing. As far as like adding it to this. I mean, we could, it could be put somewhere. Probably it should be like a, there's a whole section that's a reference and append and the appendix. I'm trying to get down there. Looks like there's some other annex. So this annex would probably be if we want it like inserted rather than a reference to something external. Then I would put it in the annex. Like this 12 factors for CNS and tell us that. Put a lot of this part in here. And then other people added to this, but so this section goes into more details on related to 12 factor apps. But trying to relate it to CNS. And this didn't feel central to what the white paper was trying to communicate. So that's why it's an annex. So I think if we're going to put in like what do we mean when we say cloud native it should be an annex. The cloud native infrastructure I guess that was the term which was referring to the code. Yeah. Um, yeah. That's not the same. Is it here. Or was that here. Yeah. So here we go this part. So this is, you know, kind of what you're gay was saying as far as there's different distributions or opinionated infrastructure from different vendors. And then. What does that mean so now there's a problem with adoption. CSPs are. Wanting a unified cloud native structure. So what they're saying is they're wanting that dream that Greg is saying is. Not, not here or harder to reach. If I make it lighter. And you know the point of silver and stuff is to try to get closer. Yeah, because from my perspective, cloud native means the workload that you run on the cloud computing infrastructure. So, so maybe. Yeah, just like the additional native there. Probably. Yeah. I agree with the lego is not. Yeah. On top of this thing. Yeah, I agree with this differentiation that cloud native is more about the workload and if you are talking about cloud. infrastructure, then we might have such a thing, but that is implementing a cloud infrastructure using the cloud native principles. That's literally what. That's what, yes, exactly. I think on Vook are talking about implementing the infrastructure or really what they want is the entire environment to be designed. So the entire stack, which I think we keep getting away from. And trying to think there is a platform and there are applications, but then every time we get into that we start getting down. Is this application that has an operator and oh, it actually has a, you know, some type of management piece that talks directly with CNI. Is that still a CNF because it's running in the same space that cuba training. Now, oh, it's an extension. So we're talking the full stack. If we don't try to split them. And the ask here is let's build the whole environment. So if we take Deutsche telecom as an example. They're doing deployments of their Kubernetes on onto their, you know, bare metal area with get ops practices. And then they're having applications. Use similar practices, which could be like you could use something like Nephia. And now you have the workload. So the deployment of the workload and then the actual workload that's running following. Native to the cloud computing. So they're wanting the whole thing. So it sounds like in from what y'all are saying. And then maybe what Ildeco is saying is this is not communicating that Philippe was trying to say that here. And I think. Yeah, Jeffrey salons understood. Understood what he's saying, but if y'all are not understanding it, then maybe the wording needs to be changed to communicate that we're saying we want the entire environment to be designed to be native for cloud computing or native to the whole concept of cloud computing. So when you say cloud native, that's what we mean. Everything is designed. When, when they're saying it, they're applying it to everything. Yeah. Yeah, for me. Oh, here's what we're missing on the next line. See this, I have a unified cloud native infrastructure layer, which are few to choose. Okay. So this is they get into more and more layers and stuff, but I guess maybe this gives back to the comment earlier that maybe we need the definitions and terms. What are we saying there. No, no, no, I mean, for me, it's like, I mean, based on the history, the first thing that was came was the cloud computing infrastructure, right? I mean, we decide the cloud and eventually we start like modifying the applications to adopt and and use all the cloud native or the cloud computing benefits. So that's why we deliver the new term like cloud native because those new applications were designed for that new thing like the cloud computing. So, like, like using that term is like, like, going back to the origins, like the same cloud native infrastructure means like essentially the same like things cloud computing. I mean, from my perspective, because it is, it was the first thing which triggers the revolution with changing the application. So, so that's, that's quite for me, I guess, a little more agree with it because when you're saying cloud infrastructure, like, it doesn't change anything like that because we have the traditional infrastructure, which is, you know, it is not self service, it is not we could use is not API driven all these benefits of the cloud has. So, so the infrastructure when when the infrastructure evolved from the traditional infrastructure to adopting the cloud technologies. Yeah, we have to redesign the application that we have to start adopting them. And that's why we create like the cloud native principle for like the guidelines, but we try to reflect, okay, well, you have to modify your application to use all these things. I mean, the terms, I mean, if I read it, that's like, I can understand if you're referring to the same thing but for me it's like kind of redundant probably. I mean, it doesn't hurt to keep it as it is as the original is like by using cloud native infrastructure. But, but usually I prefer to refer cloud computing, the infrastructure on cloud native to the workload that's my, probably my, my own personal way to distinguish things. I mean, this unified part of this definition, because I think there is a contradiction here so usually CNF vendors are validating their CNF against the infrastructures where we have to run so we are not really dating against random stuff. We are really dating against infrastructures what our customers to have. In a sense, it's not really true that they're unified cloud native you such layers different from where we are validating by for CNF. So I don't see that I think this sentence is not getting the problem right. It looks like from this sentence it looks like that CNF vendors are validating against random stuff, which is not true. That's, that's true. We are validating to a number of open-ended infrastructure flavors because our customers are using open-ended infrastructure flavors. Yeah, we are validating against what our customers require from us. So Gurgi, that's the, I don't, I'm not going to modify this based on reading a single small context. What you just talked about is related to another portion that was added in the last two weeks addressing asking a vendor to make a change when the CSPs if they don't change then you're going to fail as a vendor like you're not going to be able to match what they actually have in reality. So that other change was that CSPs are committed to meet on like for this one would be if, if we're saying in a unified cloud native infrastructure well that's not up to you if you're building a CNF and they're not, they're running an opinionated infrastructure. And they're saying we run on, you know, three different three different hosted environments or two plus our own internal and they're all opinionated. But we, we want you to run on some unified upstream vanilla version. And then you will work. That's the, I think that's the misunderstanding. It's not possible to have a vanilla version. There is no such a thing. They're only opinionated version. They're only opinionated versions. That every operator is different. That is true. But if there is no such a thing as a vanilla Kubernetes distro. Maybe this paragraph refers to like the usage of a cloud formation, key templates and all these technologies. And maybe that's a great like, I mean, if you have like, if you're using those technologies. Like key templates and all these things is not, it's just you're using the cloud technologies, but it's not unified. Like, and we need like something that's why we, that's a major success of Kubernetes, right, because we use it as a standard, like a way to define it. Like, like a unified standard to define things. But it's a case, I guess, that's, that's right. Like we need to want to unify cloud template technology could be. But there is no such a thing, I think. Yeah. All right. Yeah, but that's, I think that's the trick here is that all of this is driven by the operators. So we are not doing this because we, you know, we have too much time to do this or too much money to spend on this. It's driven by operator requests. So if they would require something else from us, then we would do something else. Yeah. The key is that they all build their opinionated stacks. That's why we are rotating against a number of opinionated stacks because this is what our customers are using. I think one, I think one of the presumptions where you're starting is from where things have been versus where they want to go. So the ask is not, hey, please go back and fix all your stuff. The way we're saying now on current, like as of today, or even six months ago, the way you're talking about it is what was in the past. The outcome just launched their production network. A large portion of their production network, not all of it, but a very large portion of their production network on this, the chef. Get ops. Yeah. Yeah, yeah. That's what it is. It's an opinionated Q and this is true. That's brand new. That's the girl gave the point is it's it's brand new. So you wouldn't be expected to say why haven't you done this yet. The ask in this whole white paper is, let's keep moving forward to that. So it's not going to be it's defined. And now, instantly, their running production is all implementing something that's the vendor neutral everything. What's going to happen is whenever multiple CSPs are all saying, hey, we also are going to follow these steps so that you have more of a unified environment to point out. And then you come in as a vendor and go, actually, this is different from this one in this. And now they have to figure that out. But at least the commitment that I'm hearing from them is they want to try to converge more and more toward, you would say, oh, it's closer. These five are very close. There's three other CSPs that are out there that they're not there yet. And their flavors are very different. You can say that they're all different, but it doesn't that's that's a big difference from saying how much are they different. They can get them to where they're 95% the same at some level. And that covers a large number of CNF store you could say 99% of the CNS will run on any of them, but we have to do these adjustments per operator. That's a big difference between saying, you know, 10% of the CNF has to be configured very differently with different requirements or higher. They're trying to reduce the changes required. Yeah, I think that's a very good, very good direction and I fully support that. Now, how do we find this common denominator? That's a big question. Well, this is the start. So the other one was they just the NGMN was very high level. This is the next level. You should look through this if you haven't yet for the challenges specifically forget about we got stuck in the terminology on the very first part introduction and pre-validation. But the other parts of the challenges are them trying to say here's what we're we're dealing with operationally right now. And then the ask here is what they have been saying so Sylva is based on the experimental cloud computing so Sylva project, but it's based on an experimental cloud platform that Orange has been working on for years. They have production recently starting to run on similar aspects of Sylva, but Sylva's not as far as I know, you may know Gurgay but as far as I know there's nobody out there actually running something that's there's no actual certification or compliance program yet for Sylva. It's in the works, but I don't think anyone's actually running anything based on the alpha or the in progress work there. But I know they have validation program and they ask CNAF vendors to validate against. Yeah, but is the one actually running a production other than I can say Orange is running in production pieces of what Sylva is, but I don't think they're running like a fully compliant here is Sylva. I think they do at least orange is doing that is that's my my impression from what's happening. I'm not sure it's in production, but like somebody already mentioned, they have multiple environments already set up I think telephonic has one orange has one I think orange is building a second. I think Tim is building one, but there are two to platform environments stood up one from telephonic and one from orange that is being used for CNF validation. Now, whether whether they've taken those and move them into production, I don't I don't have the answer to that but they do have Sylva environment stood up for doing that CNF validation. Right. So that would be closer to production on that so that this just goes back to the the same thing that there's a move towards it. And the request here isn't that everyone is compliant to everything that's outlined here as of today. It's let's start trying to move towards implementing this stuff and talk about anything that's a problem so this would be if there's something that's in conflict with what's being asked here and what's in silver then that needs to be pointed out. Vook and other folks from Deutsche telecom were part of this, and they're trying to make sure that the platform when they're talking get ops patterns and stuff from what I've seen those would be compatible with someone that's using something like and you're using KPT packaging and the configuration that you do in get is going to be very similar to someone using flux or Argo CD oranges using I think Argo workflow with something else, but they're so they're using different software for how you're going to implement those different practices and patterns. And if you're developing your deployments and your operational management to use those sorts of practices. It doesn't mean you're going to be done. It's not going to be some specific thing for a tool, but you're going to be a lot closer to working with all of them, then if you don't support anything for like deployment from from get. If you, if your package can't be configured if your CNF can't be configured and deployed from get, then you're not going to work for an FIO, or, you know, flux or any of these things. So that the first goal in this is to get to that base level. And that gets you that reduces the efforts to then move between the opinionated versions Gurga that you keep talking about. And then the idea is if if we can get everyone closer to that that vendor neutral. And then we come back and you know, ideally as a creator you can say hey here's. Here's three different flavors that we see often and from different operators are all using these, but they're doing something in a different way then we can start looking and going well then how do we make it easier. Maybe influencing all of the, the, the specific distributions, but also looking at, you know, stuff like the different layers that can help with going across those that was also outlined above. So, just like if they are the different, how, what's the typical procedure to get a consensus agreement on making a more uniform API standard, but a uniform API between the distributions. I think it's not necessary API is what we are talking about here but more like runtime capabilities or something. I think that's the key, because the API is our kind of easy. Kind of what kind of easy. Yeah, well, ideally that so APIs are just a way to interact with the system and utilize the capabilities in the system. So, that I think the APIs are an important part of this. It may not be that the API and API specifically is the way that you're interacting. On the other hand, it's how are you defining APIs. And so when we're talking about declarative configuration and a declarative system, sorry a declarative system from the cloud native perspective, you're talking about declarative configuration, you're talking about declarative APIs. There's a lot of pieces where you can have that. I think the capabilities and attributes in the system. You can, you can say how are you going to make them available to different components, whether you're extending the quote unquote platform, or you're having a CNF that's closer to the platform that needs to utilize an extension than it may be almost an extension. And then you have, you know, other parts where it's maybe a higher level workload, but there's, there's places you're going to interact. So, when you say API you could be a little bit generic, but whatever the case I think you could say they should be declarative. Whenever the system that you're on is saying it has capabilities, it needs to be able to, to announce, here's what I have, and then the application should be able to say to the system. Here's what I want. What do you have here's here's the needs you could say but it's really starting with here's what I want. And then the system ideally is going to respond. Yeah, I did use that as a more generic term so just just imagine that the just different organization already have their own opinionated implementation. So, but going forward, what's the process to make them like take one component one stack and stick it into another stack and it's still going to work. The one I've been using is like on app orchestration or any of the, the whole full stack, like, how do we, how do they work together. And if there is a, like, if it don't kind of work together, what's the procedure to, to have an agreement I guess that's the question. So, probably the first thing to note and acknowledges how native, are you going with your entire environment and entire stack. And there may be parts that work within a system, but you, they're not cloud native. And that's okay. It's just what you've decided on so if there's a greater benefit to not having something native to the Kubernetes environment, I'm just going to be specific to Kubernetes. If it's better higher value for you to not be native, then by all means, don't be native that's where we're not saying be cloud native no matter what this is for real world. So that's the very first thing to note. And then, after that you can decide with whatever component you're bringing in. And sorry, go ahead. That actually bring the next question I have. So you just mentioned that not everything is cloud native because a lot of the, the current stack is written based on open stack, for example, right. So, but now cloud native by cloud native typically means it could remain as container not necessarily but so like their new ticket. Like, for example, WebAssembly is becoming quite big on the edge. I know it's not directly related to the, to the infer, but it could be. So, with those new technology being introduced which may replace container technology, I don't know, I don't know if it will, but let's say if it does, what they probably need a way to define the, you know, how those older types of technology is going to talk to each other right so is that an API interoperability question. I mean, I definitely think that APIs can be part of a solution for integration of that. And you brought up open sex so when we say cloud native my own personal view is you can take a lot of different technology and it could be designed so that got into the infrastructure question that we're having earlier like what do we mean when we say cloud native and okay you have cloud native workloads but it's cloud competing infrastructure. And so I the intent here was all layers of cloud native so I'm going to go with that so I've designed Zen Zen based systems that I would consider closer to cloud native or just using stuff like hardware dynamic and and configurable Zen systems that weren't your traditional virtualization type of infrastructure. Okay, so that's just the first part, I think you can design the platforms of technology, but there can be technology that was specifically designed to run in that fashion so Kubernetes was created based on those practices and principles which means when you're building a Kubernetes based system, it happens to it's going to automatically have some of the attributes that you would want in a cloud native system. But if if we look at how do you integrate real world, then you may say there's a there's a network that you want to integrate with that's running on a platform that's not cloud native, but you need to interact with it. Well, then I would think you're going to try to have a layer on the cloud native side to allow some type of integration that makes it maybe is neutral as possible so there's some layer between the system that's designed to be cloud native and declarative with this API is and all that sort of thing and then maybe another system that's not designed for that. It's whatever it's designed for it's very much not designed to be dynamic. If you look at rest as an API a way for developing APIs, and the actual rest not what lots of people have developed. It allows you to interrogate the API defined further API so that you can literally dynamically with your program that's interacting, it can see the next API that you need to call. And it's directed so your application can literally find new function calls remote function calls via that. So, but you have to design your application that way and you have to design your API that way. So if your Kubernetes environment has a API for, you know, maybe integrating expanding the network, but your other platform isn't designed that way. So you're going to have to have some layer. And there's a lot of ways to go about this so I'm really just saying my opinion on this, you would put some layer between them so that you can continue to have your cloud native environment and ideally expand it. By helping the other one. And if you're using something I don't want to just call out own app but if you're whatever it is if you have some type of external orchestration management system, whatever that is, if it's not designed to try to work the way that these workloads and I would say cloud native computing workloads would do a lot of the distributed management and decision making based on the environmental changes that are distributed throughout the system. But you want to use it will again you're going to pick you're going to have to create some type of layer. So how is that going to work. So you may have applications that are already running on Kubernetes that are designed to utilize the Kubernetes orchestrator and dynamically be updated. There's a lot of new operators using like a ML to read the metadata and make changes. Well that's not going to be what's designed with an external orchestrator. But if you want to use it you're going to have to have some layer and then decide on maybe conflicts or whatever, but I'm getting into implementation on that I think it can happen and my opinion would be, you try to put a layer between it so that you can keep as much of your workload in the environment, following cloud native principles, and have a layer between for translation is a who's on on that's on the Nephio side was, I think we got Victor, you're here. Yeah. So this made me think of that the Nephio summit was anyone there at the Nephio conference a couple of months ago. Yeah. You remember that one of the talks was about external. How do you interact with like external systems. One of them would be. All right. Yeah, but not just over and but like that what is that I'm dropped it in my head right now but the is the protocol for communicating changes and stuff. That's one of the main topics that kept coming up. The configuration management changes that gets pushed out on a network. Oh, yeah. Yeah, yeah. So, one of the parts it's not all of it but there's one part of that that's very much not cloud native and it can't be made cloud native the way it's designed so there was people working already on trying to provide like a layer between so that you could push both directions. So you'd be able to update on the net comp side the systems that are using it that have pieces that just are not designed to be in this type of system. So then what you have to have is a layer that essentially translates. And you're going to have to update both sides and you have to reconcile any issues. So I think that's what you end up needing to do is having some type of reconciliation between the systems. If you want them to both work in the way they're designed to. So if you want the net net comp side and those systems that are designed to do that to work fully and you just run them fully the way they are. And then you have another system that's fully, you know, nephio dynamic cloud native, whatever. Then you're going to have to have some layer in between that knows how to reconcile the differences. Hey, thanks for joining. I don't I don't know if you caught up but it was the one of the first questions here was this thing that Philippe had responded to I know that you gave a update. This is on the pre validation section. And it was the use of cloud native infrastructure. And one of the ask was can we communicate like what do we actually mean here, but it's the concept of is cloud native referring to work pledge running in a cloud competing environment, and I was trying to communicate what my understanding that the desires have it on all layers. Um, I don't know if that was Nikolai earlier, or who it was that responded I know Gregor you had a few comments but I think someone else started that. If if you're there, I'd like for you to communicate like from your perspective as a CSP. Ildeco was saying that this term was confusing. And we definitely didn't want container orchestration because we're not saying just you're running in a container. We're saying it's following these principles. But I don't know if there's another way of having this language to be more clear. The stackers has that distinction. I mean, from the stackers one of you. Kubernetes is mostly defined as a container orchestration system. You know, yeah, you can use. You bird and you can manage. And also with a special container. You can also use. You can also manage. What application. But just in general, like they try to. So if I do do this as a orchestration system. And open a stack, mostly as a cloud computing platform. That's usually the way to define things. So, I guess, illegal what she wants to make that third distinction. Yeah, and again, like, I'll say before, like. Maybe for me, it's more. The workload. Computing is more related to the infrastructure. I mean, speaking, hello, I joined later. They are different. There are two camps, actually, and this thing came up frequently that you can even find the book from. Unfortunately, this is Chris Nova. And other authors called cloud native infrastructure. And this book is actually explaining that this is an infrastructure that enables cloud native applications to run with all these principles and so on. So we also internally refer to the Kubernetes based infrastructure and ecosystem around it. As a cloud native infrastructure or infrastructure for cloud Navy native. So, from this perspective it is for me implicit. Because it combines the orchestration and the dynamic nature of infrastructure capabilities for application to be cloud native. And the cloud infrastructure is to general it could be many things. Okay, I guess, what maybe we can do in order to move forward this point. We can affect you things here and also try to reach illegal and trying to find like a middle point like. Yeah, thanks for for putting maybe using that reference of the book. You can also try to clarify or like try to give an explanation. I think maybe just explicitly saying what you said, Luke would be good. So we expand what this term is, and what it means to you to actually have that expanded definition. And I was thinking specifically cloud native we don't need to define that's frustrating to have to keep saying the same thing. But apparently the cloud native infrastructure and how that's met isn't as clear so if we can define that either and the, you know the introduction or preamble or whatever. By the time it's said here, or you just expand that sentence, just to communicate what it actually is, then that would probably address this issue. Yeah, I think we could even borrow from the definition that is already there or refer to the definition. Like we understand cloud native infrastructure as and then. Yeah, let's share the link, by the way, as a reference in the chat here. Is that to the document or the book. No, the book which is one source of reference there there also number of articles and many things but this is, I have to confess this is not unison in the broader community and I got frequently. Also such a feedback when we use the term or application could be cloud native and not the infrastructure, which is indeed at the end through. But here we refer to the infrastructure that enables it gives you all the properties so that you can run the cloud native application without external orchestrator with the reconciliation with all these, these kind of things. But I can try to to make an formulation to remove ambiguity out of the document. It seems like it we're saying a full stack an entire stack, the infrastructure and workload, everything, including the how you deploy. Since we're advocating get ops and stuff it's the entire stack. So if that can be communicated. I think when we put a short word, it's not going to work because people aren't going to understand what that means I get it and I thought this was what she meant but apparently it's not universally understood that way. Let's talk after and try to add something in here. I also think it'd be okay to, if there's like a quote out of the book, we can just drop a line put it in quotes. And, and then ref, add it to the reference at the bottom. It's okay to have like a single quote as long as we reference it. Yep. Yeah, I agree. All right. Well, I'm going to resolve this one's Kubernetes. I'm going to try to work through the last of these that got, I think addressed either with the last update, or there, there's some spelling and stuff like that. But we'll be merging this pretty soon go ahead. No, no, I just saying like, I mean, after the double power. Thanks everyone. Thank you. Have a good day.