 Hello, Anat, Nicolay. Good morning. Good afternoon. Hello. We're just going to wait for us to join. Well, for more than all Taylor is traveling, so I don't know if he's going to join. Oh, that's right. He said something about like the conference, right? Big 5G or something? Yeah, okay. Big 5G event. Okay, let's see. Hi, Victor, how are you? Good. All my windows were on top of each other. I was trying to locate myself here. Sorry. No worries, like the first hour of the day. Yeah, well, you're a little earlier. Yeah, you're earlier. I should be better. I've had a couple cups of coffee already, but I'm still, it's probably more Monday. Yeah, I couldn't attend the last meeting because I was attending the open source summit. So probably I will have a little bit disconnect what happened last week, but yeah, I'm just looking for the meeting notes here just to kind of jog my memory as well. I can stick it in there for anyone just to quick access. I know it's in the, it's in the meeting invitation, but just make it handy for everyone. CSPs for the KubeCon, okay. CFP for KubeCon, yeah. Do you want to submit a CFP proposal for CNF Working Group? Well, actually I can start sharing like that. I was thinking the way a little bit more, but yeah, probably. I don't know if more people are going to join to the meeting. Yeah. I can actually, and I mean, I guess I guess I want to add, I can add something to the agenda. Please. I'll add it here in a second. Let me just give me a second. Okay. I just added an item there. I just I can, if we want to talk about that. I can do that. Okay. It is six after the hour and apparently also Tom can also join. Okay. I guess that we can start. So, well, apparently Taylor and others are attending the, the, by G event. So hopefully they can share something after the event. The next thing is like, I don't know if you have plans to to submit some papers for, for the elephant developer testing forum. This virtual events obviously. It's a great opportunity to share ideas or best practices in this case. Do you have plans to submit something? Is that to me or to just everyone? I think for everyone, like, yeah. When's that close? Oh my gosh. Yeah, that's very soon. Yeah, actually, if someone wants to submit it something, yeah, we can maybe submit together or like. Yeah, I mean, I would be interested. Victor, if you were interested, I mean, I, if you want to set like, I would be happy to just maybe shut up a short call and just discuss a little bit more. I'm working in an elephant in the, in the anecdote assured program and we've had long had conversations about, you know, CNF, you know, there's sort of, there's work going on and sort of CNS over on this in the CNCF and there's a very course infrastructure that should support CNS and there's some requirements for those within LFN. I've been working in the past with Taylor, of course, trying to get, you know, strengthen the collaboration between both organizations so that there's a less fragmentation, if you will. And so, you know, I don't have the answer. I think that's one of the things I'm thinking and I'd be happy to maybe discuss it a little bit more. Maybe not on this call here but, you know, if you if you're interested I could, I can reach out to you and maybe we can have a first class and then see if there's anything that we might want to bring up to the, to the group. No, that's awesome. Actually, very interesting. So, well, you have been also in the nephew discussions. Yeah. You're so aware like that now we are like considering like, I don't know if that is the first or third pillar of the provisioning like to consider like not only the workloads also deploying through nephew like the whole infrastructure. I guess if we can. I think that we can combine all these areas like, as you said, like to unify and try to make all these things like online. So, yeah, but yeah, definitely quite interesting to do that. Yeah, I mean I have, you know that I'll just throw it out as another example I mean that you know we for those for those of you aware with Silva, you know, it's a, I believe that there are plans at some point to offer, you know to do CNF sort of validations there and using the test suite from CNF and I, you know, I, it's great. I just my, my concern is always about these slightly variation variations and different views and sort of how to be. I use the term, align where we can and only diverge where you have to, because otherwise it's just, you know, creates so many different views of what it what are the best practices at you know specifically for CNF. Yeah, you get different, you get different answers if you go to different places and I think that's a that is of course a little bit of a challenge. So the more we can do to collaborate I think is is my main, the main thing that I be interested in trying to form some kind of session around you know how do you how do you bring how do you bring those closer into alignment while still allowing the flexibility to have different opinions, you know, have an opinion at a view in different places. If you look at LFN, for example within aniquette I mean we've managed with some of the work we've been doing to align on the first sort of essential, and I know I'm mixing between the CNF test suite and the working group here but I think some of the work we do here is just translate into tests in the test suite. And there today exists, I think it's around 15 essential tests. We've managed on aniquette to align on on 14 out of the 15, which I think is actually, you know, those very encouraging. That's those small steps I think we can do to help, you know, to contribute if we have new ideas to bring them back and sort of say are these applicable for everyone or are they really an opinionated view that it should be only in one place. I don't know if that makes sense if it doesn't sorry guys. It's still Monday. No that's fine I mean, so trying to understand like your ideas to more like an open discussion or like a co-fraction or. Maybe something like a call for action. An open discussion. Yeah, let's let me do this. I can I'll reach out to you and see if we can maybe just set aside 30 minutes and just discuss some ideas and see if we can come up with something that would make sense. Because I don't have a clear view on it right now and I can probably share why if we meet. Okay. I didn't make like once say something or. Yeah. Oh, no. Okay, no, no worries. Also Taylor is here. Hi. Thank you. Hi, I'm not sure if it's already discussed. I would also like to have a discussion on between horizontal and vertical cloud. These vendors bringing their own cloud solutions versus building one big cloud, where all these can be on board as different than it's not sure if it's already discussed in this working group. I mean, yeah, this is a, I mean, I guess it's like with CNFs and I guess it's a valid topic to discuss here as well. So, yeah, I don't know, like, do you want to discuss right now like as part of the agenda items or like, what is your. If there is interest, yeah. Okay. So, I don't have to, we don't have too much items in the agenda so let's put it like, what is here in the agenda and maybe what do you think like. I mean, the rest of the topics that we have is not too much. I don't think that we're going to take us so much time. And definitely we can save some time for discussing this particular topic. All right. So the next quite events is like the open round summit. If I understand this is your virtual event. So, and after that we have the open source summit. So, yeah, also I guess like there's going to be a one. The regional summit as we had in Vancouver. And the other two events are like MWC and KubeCon. So, Taylor, did you mention something about like a KubeCon or like the cloud native telco day as a collocated event or like you don't have information yet. We're not confirmed. We're wanting to get sponsors for the event. And you're going to try to make it happen. I mean it seems like it's been well received every time so I think we need to keep doing it. And if we don't have, if we have enough sponsorship then we'll probably end up with potentially a full day. And if we get a half day only then we'll probably do the community gathering like we did and keep kind of you. Okay. Okay, nice to know. Is the sponsorship prospectus valid. This is the new one or it's I would just use it as a, I don't, I don't know that it's covers in a, I'd have to look. But you can use it just kind of as a gentle idea basis and we'll scan and get a new one. Okay. All right. Those are the old events that we have. So there's any anyone missing. Please feel free to add it as part of the list. Even. No. So, okay. Just a quick. Yeah. You probably are connecting from a phone or something. I have opened the prospectus it's just a relevant information for any for the North America. So, yeah, it's, it's okay. Yeah, okay. Thanks. Thanks. Okay, so that give us time. I don't know if we have PR to review like, or something, but I guess, much better to start like checking the items that we have here in the agenda. So, I'm not, this is the topic that you want to discuss about this or like. I think that the topic I proposed comes under this year's. But, but mostly on the infrastructure side. Okay. So basically the point that you want to discuss is like, having a CNF which is applied among multiple data centers like how can, what is the best practices to deploy that. Do we deploy that CNF is vendors incorrectly or like. No, mostly infrastructure perspective. I mean, I don't want to name any vendor. That's a, that is a vendor who is providing by the solution that is a vendor who's providing ran. So they all have their own Kubernetes distribution. It's a cloud network function versus the operator having a unified cloud. Let's say from open shift or be aware or range. This will create silos, right? I mean, as a operator, each of these products have its own lifecycle management. It'll be difficult to manage again. So how is the industry addressing this? Let's say the same CNF can be, might be certified on both open shift and VMS instead of having their own cloud solution from each of the vendors. Isn't it possible to or consider it as a good practice to have one unified cloud where all these CNFs can be on boarded instead of having so many different deployments or different versions. Okay. I guess that's reminding a little bit the, the topic which was discussed during the, the guiding event. So we're like. It was presented that were. Let's take it the case for, for 55 or five deployments like where you have like a multiple CNFs. And every single CNF is using different vendors which has different infrastructure requirements. So, I don't think that I don't know that maybe I'm lacking lacking of knowledge but I guess like I just assuming that mostly like the industry has been using a single infrastructure vendor, maybe I could be grown like someone who has better expertise on that can chime here. So, so, so I think it's like, we haven't, that's that's why we have a lot of initiatives, especially around like where we're trying to desegregate these and establish certain open standards and interfaces where like components can interact. So I can explain maybe in terms like I'm in from nephew perspective because it's the, the last thing that I have been involved. So we are trying to define infrastructure as a, as part of the, the, the, the CNF requirements. So, so when you express your desire, like what is your, your 5G deployment desire. So you consider like the infrastructure as part of the requirements. So eventually in this case nephew is going to take the decisions and he's going to try to make the deployments. One of the, the key tools that we are considering for, for that particular exercise is cluster API. So the idea is to consider as part of the package, the certain custom resources of cluster API and deploy the application, try to solving the requirements of the CNF in this particular case. It is something that we're like still experimenting and certain things that we haven't reached that point. Obviously, this is very new and haven't explored yet, but I don't know like someone has another experiences or like some of the ways that the industry has been mitigating this particular case. If I understood what you just said, as long as the Kubernetes cluster can be orchestrated using cluster API. So it hardly matters if the Kubernetes distributions are from different vendors as long as it meets the requirements. Yes, exactly. So basically cluster API has different providers. So and in that way you can express those requirements based on the application. But yeah, I mean, now we have like a, I mean cluster API has been there for a while. So now the major difference that we are trying to do is like we are trying to integrate like that particular tool with the nephew ecosystem. Similarly, we can express the 5G deployment like as any other like Kubernetes resource like where you express your intent. I don't know if that makes sense, but for now we're working on that and it's showing like a good results. The only problem that we have is like right now cluster API only focus on deploying Kubernetes clusters. So, and there are some cases where we need to interconnect those clusters like so, for now I don't know if we have like a tool which can help us to interconnect those clusters using the same model that we use like a, what is the name? Kariam, Kubernetes resource model. So it's something that probably we have to face it in next common releases. Okay, I think nephew would try to address the current challenges because I heard from different operators that we have one from Ericsson, the one from Nokia, and they also have their own based on OpenShift. And it's really hard to convince let's say Ericsson or other players to move from their own Kubernetes distribution to OpenShift. They'll come up with so many saying that it's not good for that's not tested or these things that would come up with. So hopefully with nephew and with standardized cluster API, I mean with cluster API it can be addressed. Yeah, exactly. And also now like a Kubernetes has this LTS concept so not only you depends on the cluster vendor, like you also depends on the cycles that they have. So if for some reason they don't want to move forward, they haven't applied all the patches because they are like Kubernetes distribution. So you have to heavily depend on them like on their own cycles. So, yeah, it's a good point like that. One more question if you're okay. On nephew. So, so we have nephew, we have VNFM from vendors. So is nephew trying to get into the VNFM space, you know, directly orchestrating the CNFs instead of letting the SVNFM orchestrate the components. I'm not really sure because I'm afraid that at some stage there is nephew beside slightly overlapping the domain orchestrator or VNFM. I think if I have to define nephew in few words. I could say like a nephew is. So it's like the tool which is bringing the, the GitOps best practices like for for CNFs. So, I mean, obviously I'm trying to put a lot of so so in that way like it's not pretending to be like a replacement like like probably is trying to connect a lot of the things that they are there. I mean, there are people who are like connecting with on app. So with all our existing ecosystem in open source ecosystem. So, yeah, but obviously the way that for example in on app was managing the life cycle of the VNFs was like a very manual thing so it's like a lot of interaction between different operators. In these cases, the interaction is more like a get up using GitOps best practices like. And the Git Hooper or Git Hooper or any Git server as a source of true. Okay, okay, got it. There, there are some parts that they're looking at orchestrating deployment of kubernetes. It's at least in the future part of nephew. They're focusing on onboarding and management of the CNF life cycle, including any type of capabilities needed for the networking and anything. That may require the CNF and attributes and needs in the cluster. So that could be expanding a cluster with certain things. And that's where they're looking at operators and other parts that may do it more administrative things on the cluster than just deploying a CNF. So they're getting into that they're at least writing up things and the documentation for potential future management around orchestration of clusters and multiple clusters. I don't know if if that'll ever come to be something that they focus on but it's it's definitely talked about in some of the calls and it's in the documentation. But management of the environment and and stuff is as part of it, the CNF onboarding would be the main thing. Yeah, so that's true like also about nephew. In two weeks, I guess we're going to have the first release. So that is a long, a long things to do a lot of a lot of things to implement in that particular project. So, also move a lot of moving parts. It's promising a lot of things. But yeah, it's also a good place where we can like bring these kind of concerns and say like, well, what if our, what is what about this case like are we are others in this particular this current issue, like are you addressing all these things. Okay. Well, Taylor, I couldn't attend the previous meeting so I don't know if you have something, or I don't know if you discuss something from the previous meeting that you want to bring in this particular Nothing really from the previous ones that Nikolai did you put forward any of the stuff around best practices that might apply to Kubernetes extensions and plugins like CNIs and other things. Yeah. No, not yet. Not yet. Right. So that this would be some relation to thinking about like what is nephio covering and other projects that are dealing with when you're looking at GitOps, how to use the patterns and stuff with GitOps for doing deployments. So you're going to start thinking of things that are not just deploy the application onto Kubernetes with without thinking about the platform. So there's some parts that end up thinking about what is, what are you configuring on the platform and stuff like that. Then you start looking at things like extensions to Kubernetes and everything else. So there's Nikolai had brought up CNI plugins like Cillium and there's other ones that I think would come in. So how do we talk about projects like that and best practices that we think would be good for the community to adopt in general. So we kind of and Victor a few months ago but we were talking about maybe highlighting best practices from nephio. So that could be some areas. Things related to maybe that the boundary between ran and and then core core components, and how do we, what, what would we think would be practices and maybe technology to look at that are some of those edges. And even we could even think about like Stefan run ran because now there's more and more adoption of running Kubernetes on the edge and everything well how are you going to do it on radio oh ran is digging into that. But I think that would be something to explore. A lot of the practices we've been focused on are general practices that would be for any type of workload, not even specific to CNS. So we could look at what are some specific needs of CNS that aren't as common for other applications. And then how would we. What are some patterns and practices that we would recommend. If you're running in a Kubernetes environment, then how do you best take advantage of those. Yeah. And I think Nikolai the stuff around. What would be one of the areas that gets in a more important networking applications and networking environments. But that that might get into workloads taking advantage of those and then what should that be expecting. Yep. And if we're going to have projects like psyllium that are going to go through and say hey we're following best practices. And that could community agrees on running in a Kubernetes environment. And what are those so that you know that they could be written up and maybe they become part of the CNF certification so that potentially profiles so maybe we have workload that are important like profiles and then something that would cover projects like psyllium that would maybe wouldn't be considered workloads but are important part of the environment and we want to have it where they can say hey we're following best practices. So the core topic that I was thinking around like maybe it's not related with little more CNFs and all these things. It's just about the how to manage the. I mean, a few years ago, we didn't have configuration tools like Ansible, Pop, HF all of these things. So that's why those things work really well because we have to manage all the operation tasks. So, so it were those were great and and and we have a great progress on them. But now that assuming that most of the deployments are using Kubernetes as a as a standard like the new cloud operating operating system. So, I just think about it like she still is still making sense to to do certain operations with Ansible and all of these configuration tools or makes more sense to take advantage of Kubernetes. Talking about, for example, you can, if you need like a to to install like a kernel module, for example. So there are ways to do it the same task using Ansible or you can take advantage of Kubernetes and do the same operation. Same thing for installing things on the host. I know that definitely that somehow violates the principle that we are saying I'm not trying to use privilege containers but it's possible to do it. So, I don't know if you want to talk about this particular topic where it could be a good practice or bad practice to use Kubernetes as a as a configuration tool, or keep using the same tools like traditional tools like Ansible. What do you think maybe Taylor or someone need one to mention something about this topic. And I, I think folks can get to caught up on the technology and tools like Ansible. For example, and versus the reason why you're using them and the patterns that I think can be applied with different tools. So GitOps doesn't require flex CD, for instance, get the patterns behind GitOps are older than the term GitOps. So you could see people using the same type of principles that you're saying with those type of deployments and management for the configuration and all of that. For a long time before probably before Kubernetes I would say, and I think those are more important to really understand. Then looking at the technology or tools or whatever has to do with does, does the tool let you follow the patterns and practices that you want to utilize that you think are going to be good. I guess stepping back what is the problem that you're going to solve. And then do these, this is technology help you or is it going to be harder because there's definitely some technology where you could say you can use it will following any pattern but it may fight you or it may. It may not be designed to follow those patterns so when we talk about Kubernetes and cloud native. This is an implementation of the principles and practices that existed before Kubernetes, but they're baked in so it means when you look at Kubernetes as a framework, and you want to follow cloud native practices. It's going to just help you along. So when you're looking at configuration management, deployments, whatever else will then, you know, Ansible would just be one tool, and you can go. How does it follow those. So Ansible and and many of similar ones can be potentially simple enough and they allow you to have a domain has a domain. You can create your own domain language, where you could build Ansible playbooks and stuff using its terms to do things in a way that are following best practices and patterns that that you're wanting to follow. I'm not against using Ansible and you can see some of these configuration management tools starting to come back again. They seem to be pushed to the side by some other tools are coming forward and now they seem to be coming back and maybe being better integrated. Yeah, also, like, I mean, yeah, definitely that's true, like you're saying. But for example, like, I think the naming was the puppet agent. If you compare some of the functionality that this particular agent is doing in the servers. It's quite similar like the what cubelet does in in the worker notes like I mean it's constantly checking if there is something new to do and once received instruction applies the application. Obviously more things to do it like a cubelet in this is connecting containers and doing a lot of stuff. And Pope agent definitely manage files and self packages and things like that but I guess I guess in a sense that the functionality that's his particular these two things are like doing is, is pretty much a similar in a lot of things. So, yeah, so maybe the the major difference is like the level of adoption that Kubernetes has so so probably not probably few years ago. There were just few people using Kubernetes in their own deployments, but now that the massive massive of the deployments are using Kubernetes probably is not the case like most of them has Kubernetes on it so it's not a problem doesn't have that particular agent or behavior in the server. But yeah probably yeah the is it better to have like a choices and tools I'm not saying that we don't have to stop using answer or any configuration tool, of course, there is their own use cases. But I guess, I don't know if we we should start like relying more in in having the fact that maybe we have Kubernetes as a deployment. And take advantage of those tools there and try to minimize the, the, the, the corner cases. Like, I don't know, like, probably is this is all depends on the use case every single use case and probably has different scenarios. We'll have any other topic in the agenda. I don't know if someone wants to bring something. I had, I did actually have a, I think it's, it feels like the timing is kind of good. I have a there's a discussion item at the bottom which I just had put into the agenda. Yeah. Yeah. So, basically what I shared this with Taylor a week or so ago just, and I don't know if anyone else has, if this is just me or if there's others who might think this could be a good idea so this is really just a discussion item. Having participated here in the CNF working group. Great for that matter. One of the things, you know, I feel like I have a pretty good view on what we're what our, what our goal is of course identifying best practices, and I think I ran into. I was looking in our repo today and I just found a nice little reminder, if I would almost. In fact, I'll do this I'll just take a picture and share it in this in the chat so I don't have to screen share my screen. It was a little bit along the topic of what we what you were just discussing now. Give me a second here, I'm going to put this in the chat. I can give you access to chair. Okay, yeah, if I'll do that that's fine. Bear with me for a second. So, yeah, so I just, I was just noting when you were talking, I think maybe there's some relevance to this as well. This is from our, this is from our repo here this is some documentation we have on sort of how we work with communities and off to the scope, right. And so I think we were talking a little bit about infrastructure and we're talking about, you know what this group is focusing on how do I build CNS how do I run CNS deploy manage lifecycle. We've been talking a little bit about nephew. What I wrote in the notes or an agenda today was really just question about, would it make sense or would it be a value to this group to somehow try and build a view of what we, you know, we have categories and I'm just going to go to that for a second here so bear with me. I think it's here to yeah so we have these different categories. We are, we've been working with identifying best best practices. And I'm wondering if it would make sense to somehow try to summarize. What are the areas where we feel that, you know, if we were to sort of put a judgment call on this area is fairly well understood, it's green, there are best practices. There are versus other areas that may be underdeveloped. And we're just a tool to try to help us understand where our best practices needed because I think sometimes for at least for myself it feels like we're looking for best practices. And I just like to have an organized way of seeing where are the challenging areas. And I think you were touching on a little bit Victor about life cycle management there are new tools that are being that are coming. And I know that we're not less so looking at the tools but we're looking at the patterns and the best practices. So it's just a, just a thought, if someone would be interested to think that would create some value to identify the, you know, what are the areas in terms of CNS that are underdeveloped needs more work needs more best practices to address some issues and that. If someone else feels the same way very curious to hear your thoughts. To be honest, I never think about it but now that you present this. So, so what could be from your opinion like what could be the best way to the criteria that we can use like a number of best practices or the quality of the best practice or. Yeah, that's a good, that's a good point. I don't have the full view, but I think maybe starting with simply. It's fairly simple to identify what we have and what you know we we have categorized things already so I think just having a reflection on that and then certainly maybe looking at, you know from a community. We can just sort of rely on ourselves to say so what are the areas where we feel, you know, there's only two but let's just use an example hypothetical this category only has two best practices. Is there a reason is it because we're not having a, is there new challenges there or other challenges that remain and even if we don't have the best practice we can identify some of those challenges that just, I can't help but I think this might help us, you know, identify areas where we need to solicit, you know, and whether that's from CSPs or vendors, you know, trying to understand what are the challenges, or that you're having how do we, you know, so that we can reflect on on on possible best practices for that. It's just, it's just an idea otherwise it feels like it's does anyone have any best practices, you know, it's a, it's great and I think we have identified them. We've identified some. I think from a more maybe structured approach to, you know, where, where are the biggest challenges that remain and maybe identify out new new categories that we haven't really touched on. I have some, some kind of quick comment here my mean earlier earlier in this, in this call. I remember who brought up the topic of, okay, but vendor X is delivering their CNS only certified against their own Kubernetes. And this clearly is a sign of not following any best practices right because essentially this means that their distribution is fine tuned and the CNF is fine tuned for. Much between the Kubernetes distribution with whatever plugins and whatever it comes there and the CNF so I mean I'm not saying that we shouldn't invest into the best practices. I just somehow feel that. I mean, the real world is not really following them and then the question is, I mean, is anyone practicing these practices I guess that's, that's the question. I would, I would love to have all of these, you know, being followed and so on and so forth. And we have examples of CNS being certified which obviously are following best practices. I mean, you cannot pass the certification. But, yeah, I mean, this is more like a observation not not not that it adds anything. Yeah, no, I, I, I, well, for myself at least I, I think I agree with what you're saying. And I think in some ways this was again backed for at least in my thinking was that we, you know, it's almost like you can see this is another way to think about what I was was kind of suggesting there are trying to discuss is almost a maturity, maybe model right and somehow trying to come to because if why aren't they following those those best practices then. And I'm sure there's many different reasons. Yeah, exactly. I agree. Is there, is there any disconnect between like whoever has to implement them and what we, what we think because I mean, I haven't been to each and every discussion here but more or less know and understand what we mean when we're doing the best practices, and it's somehow kind of I don't know, ideal world where, you know, we have stateless services and everything according to the theory, but that then in the end, maybe in reality is just not feasible I don't know, I mean, I don't know. Yeah, something that probably we have to somehow try to go and listen to a real world vendors of the CNA side. Yeah. Ideally we're solving someone's we're helping to solve problems or pains when someone's saying I'm having a hard time with this. I'm trying to help with that. So, a lot of problems in the past. Well, relating to what is Kubernetes doing or what is cloud computing, one of the main topics is interoperability between multiple clouds at the start of this call talking about different clouds, and then how do you ensure that things are going to work between them. If someone's providing their own environment, whatever, so that the interoperability there is part of it, interoperability between the different applications or CNS that are going to work together. I mean, we have it split in different ways this these actors. And the interoperability I think can be applied at different layers, including the how the CNF in for operator, how do I run the in for a deploy and manage. Well, my in for actually has extensions and stuff because the workloads. Well, then how are you doing in different environments because most of the service providers are running multi cloud. You know, maybe their own and then running somewhere else. Interoperability, but if we'll start with who's the actor, having a problem, and then where are they having the problem then we could probably dig in there versus the even like this section is just talking about right now it's just CNS developers there's a another document that's best practices for CNF developers so. This is only one actor, and then some CNF developers, they actually care about how to run and operate it because they're the ones building it and they need to know how is it working so they actually start thinking of this. So in some some ways they could be the actor is also a CNF operator. And then how do I consume it okay well, you may have CNF developers that are also thinking about that. And so these areas. This, this is kind of to split and think about the practices that may overlap, you may have a microservice that also needs to think. Okay, what is a configuration life cycle, or upgrade ability of a microservice why don't we have these. Just an area to really think about the best practice, but the best practice may actually be in multiple areas. The more important thing is, who is it applying to whenever you're talking with someone, and they're saying hey I'm having a problem. And we're going to go. Well, let's think about best practices that we know. Are any of the best practices that we know do they apply. I think if we have a, a actor that's putting forward some pain or problem that they're having. It may be easier than just talking about what best practices have we written up or not written up. Yeah, no. Yeah, I agree with you. And that's the categories is great I mean that's just you know it's categorization but I think to your point it comes back to so what are the. I hate to use the word life cycle but it's it's everything from, I mean as a, as if I start with just myself I mean as a representative of a CNF vendor. The challenges that if we were to sit in a room and just start to say so what are the challenges well the challenges someone already mentioned that there's many different opinionated versions of Kubernetes. So every time we're going to show that we're actually you know it can can be deployed there and and and it works. You know there's a lot of certification work that has to go on. Some of its overlap and very similar some of it's different. What about orchestration so is the end customer looking to orchestrate the CNF using own app or using nephew or using something else. That's that those are so there I think my point is trying to understand what some of those categories in terms of the areas of a CNF that not as not only the CNF vendor who's creating it they're creating it for the purpose of to be used by someone. And so what are the, what are the challenges of those different environments you're going into and I guess I was trying to think about what are those areas if we can sort of massage out some of those areas and try to understand where are the challenges. Because then you could start to look at what you know what best practices do we have what do we not have an effort to get a list of challenges probably be a good place. I'm actually headed towards the big five G event today so I'll try to listen and and write some up. Some of the stuff that I've been hearing are from the consumer side, the service providers themselves, and looking at how are they managing so some of those are going to be overlapping down here, but writing up the challenges. So if we can have wherever they are. I'm not really worried at what layer just who's having a challenge if you're in a Kubernetes environment. What type of challenges are you having. And if you're a vendor, and you're having challenges deploying or you're having a challenges integrating and working with another vendor or running on Kubernetes is problematic with some other requirements that you have somewhere else. Those are the what we need to write up right we made it to the top of our. Thanks folks. Yeah yeah thank you. See you next week. Yeah.