 Hello, we'll get started at about 10, at five after, not 10, five after. Hello, we'll get started at five after in about a minute. All right. I'm not hearing anyone else. My check. Let's see. What do we have here? The meeting nights are in the zoom chat. And looking for, are there any walk-in items? Topics to add. It's kind of a random heads up. I'm sure most folks saw it. The KubeCon North America CFPs pushed out from April 11th to I think May 23rd. So if you were thinking about submitting an abstract, you got an extra month now. Thanks for that. That's a KubeCon and I CFPs. Is there any talk of whether it might be in person or not? I don't know. They're still trying for it to be in person. You know, it's a lot of variables. You know, current plans, I believe from the agenda, you know, the events team is to have it in person. I think it's. October 12th, 15th ish. Sometime during that week in LA. Wear a mask and get vaccinated and we'll see what happens, but. So our monthly meeting times. For this call usually had been flipping. We're trying to decide if we wanted more of the. Later time. And if we're going to keep the earlier time as well. Or do we. Feedback on that. I need to put out another form getting. Feedback, but just from the folks on this call. Yeah, for me on East Coast, North America. So this time. Works better for me, but. I think it's important to have some flexibility for others and other. Geos. Some groups. Have a. An early one on the same day. They'll have an early one and then a later one. So that's one thing that we could. Think about. So next month have the 11 and also have the 1500. So that's one thing that we could do. All right, maybe put together a form and get it out. See the feedback. I think on the last one, there was only. One. Respondent maybe for the last early call. But we'll. Try to get that out and get some more feedback. So someone had a, an item in here that just said Nokia. But it had no other details. I don't know. I don't know. I don't know. Jeffery. Morning. Yeah, I'm just so, I don't know if the people have seen. I don't see him on here, but I'm. An individual named Philippe reached out to me and he started putting a bunch of stuff. That you want to click that link, Taylor. It's mostly just been. Kind of a collection of notes. I don't know if there's interest. In us, like. I don't know. I don't know. I don't know. I don't know. I don't know. I think Philippe has interest. If we wanted to. Try to start working on another document within the telco user group. I've kind of just been using it as a dumping ground for thoughts, but I'd put in real work if other people were interested and thought there was value in it. I think. Yeah, I think it has value. It's in here and. You know, I'd be happy to contribute to it as well. Yeah. Just in general. When I think of user groups, I kind of think of. More like people within a specific user group. Looking for help with something. I think the challenges paper could be a way for us to kind of put some information out. Like I said, it's really just a collection of thoughts. So getting a little bit more specific. I think that there is. Challenges that maybe have arrived. I guess in the CNF working group that probably aren't actually CNF specific. It's just. This like shift to how we hand off software, how we consume it. Everybody saying they're going to constantly test and deploy. Yada, yada. I think we could look into stuff like that. Maybe do like a dual paradigm, like. You're a software provider trying to figure out. How you maintain SLAs in a world where everybody's saying you need to deploy constantly. You're a service provider who's trying to consume that. And if you're cable specifically, you know, you don't like to touch anything that's working until it completely catches on fire. But I think kind of just semantic of this whole group in general at the beginning, a lot of the thoughts were very, very seen at focus, but I can tell you the whole concept of just like Kubernetes that kind of run it as a bunch of one offs. So that's another thing that kind of pops into my mind that would be potentially worth looking at. Just something as simple when I was talking about Frederick's use case with the, you know, bump in the wire firewall. It seems like, you know, it's an entry level use case until you realize that like green blue deployments become really, really challenging depending on how restrictive or permissive your firewalls are coming in and out of your data centers. So, you know, suddenly, you have to like start looking at a higher level of workflow. If you want to grab an entirely new subnet for the new node, you're provisioning to do a fresh install, things like that. So they said, if there's interest, I don't know, like kind of this group in general where we want to go at a macro level. But if it's to continue to like put out documents and things that we observe that are specific to being a telco vendor or a telco, then I'm down to help. Jeff, I have just a question. This is just from the service providers perspective or also from GNF developers or both? Yeah, I think it's really whatever this group wants. Like I said, it's really just a collection of notes. I mean that act was just like a placeholder and it's super out of date at this point. It's like almost two years old or something. So we've kind of done a lot of work in the CNF working group around identifying actors. So I would think that it'd probably be more valuable to potentially write a paper where we give multiple actors points of view. Because, you know, challenges are not just, it's hard to like lifecycle manage a CNF, right? Like something as simple as I've got my own monitoring stack and Tal wants to provide me a better monitoring stack or integrate his stack into my stack. How does that work? You know, there's lots of things to unpack and I think a more diverse view set would be better than just the telco one for this personally. Jeffrey, may I comment a little bit on your proposal? I mean, I'm looking primarily for what I'm reading. I mean, I have a former telecom background, working with a complete cellular network and implementing platforms and services in terms of different applications and end to end, starting from the terminals, from the core network, transport, base stations, BSS, OSS, security, provisioning, mediation. Now, I mean, you're absolutely right. There is a lot of focus on Kubernetes and applications. But at the end, when you start, you know, putting this in a production or in a commercial operation, once you have some kind of an interaction between all these applications and provide service or services. And this is in a ways already specified in the 3GPP. And now, because of different roles, we are not talking anymore about telcos, but we are talking about CSPs. And now also, if we look of all the specifications also focusing on slicing, and if we look at the global mobile supplier association reports from the last year, there are more than 330 applications for private 5G networks. I mean, a slice is in a way a logical network. So a little bit on your proposal, on a focus. I mean, if we going to shift focus on communication service providers, and then we look whether this will be service providers that are actually providing different type of applications put together. And then we look at the so-called traditional mobile network operators who own a license that actually they are entitled to provide in a particular allocated frequency, particular type of network services. I mean, shall we try to put some kind of and then we can, you know, have already utilized the 3GPP specification on services, because now the main, even if we can take Etsy Mac, because there is a very clearly outlined what the latency is. And if you look at this specifications, even in the openness, the function of the UPF is vital for this latency, but then you have four different alternatives. But depending on which party is involved, you will see that it is the party that has the particular informational competence, whether this is a provider, you know, for the base stations, then the UPF is in the, you know, BTSs. If it's a mobile network operator, it's probably, you know, at the aggregation point. If it's a kind of, you know, distribution of some kind of a Cisco or Juniper, then it's a kind of in the data network or in the cloud, or if it's, you know, it will be the core network. But at the end, you have the latency that you have to provide from the data where it is generated if you're using the term edge. Now, I mean, it's very convenient because majority of the people are very good with Kubernetes with the applications. But what is the purpose of this? The reason that the services and their certain specifications that are, you know, indicating if again, sorry to repeat myself on the latency, I can give you some of the requirements and, you know, most of the mobile network operators are actually complaining that, you know, from zero to 11 milliseconds that delay, you cannot provide it. So just give me 50. Third, if you look in the subscriptions, that's more or less, you know, the silver subscription. I very much agree. It's a very good, you know, comment because it is in a way outlining what is the purpose and what is the objective. And based on that, you have to choose some kind of a framework to use. I mean, I'm a little bit, you know, surprised that there is almost none of reference towards the three GPP specifications on the services. Because also, as you see, even again, sorry to be, you know, referred to the 5G, but in the network functions related or applications related to network functions, the context is separated from the business logic. You can go deep down on this. Compute and storage is actually there is a particular functionality where this is separated and this is stored in separate places. But again, sorry to repeat myself. We are very much, you know, in the area where it's convenient for us. You know, when it comes to Kubernetes and all the applications because, you know, in the OS kernels, you can actually handle very much when it comes to terminals, when it comes to the, you know, files and security in one place. I agree. I agree that this is a very good point and maybe, you know, it's worthwhile to be discussed. Maybe it's worthwhile to, you know, bring some references on that. I mean, with references, some of the specifications, including even security. Are you saying here that these specifications tell us exactly how to use Kubernetes to get this job done? No. Then what are you saying? I'm just saying that we, you know, we are using very much Kubernetes when it comes to applications, but these applications have to form services. But these services are specified. Yes. I mean, they're kind of four different areas which are specified and it's very much, you know, related to ultra-reliable low latency communication or the IoT, including different kind of a multi-axis. This is the mobile network. This is the Wi-Fi. I mean, this is all specified, including even satellite access. Yeah. True. So what's being put forward by Jeffrey and that asks, it's a repeat from two years ago like you pointed out. Should we go down and write up all those concerns? So if you're saying out there, there's already a lot of the concerns that have been written in specifications, that's what we want to pull out. We're not interested in saying that a specific technology is solving it somewhere else. That could be another document, but what Jeffrey's saying is should we write out the underlying concerns? So if you have some, you know, knowledge or there's papers that can be sourced from or whatever, then it sounds like there's interest in this. Writing out the concerns. Yeah. I don't think we have to stick to one paper too. Like observability. You know, we talked about that being like one of these pillars of things going forward. Anybody who's ever tried to like get true observability and a super heterogeneous environment knows that that can be a struggle. I mean, we could do like a macro level paper. We could find people who, you know, specialize. Yeah. Yeah. Yeah. Yeah. I do. It's called the telco user group, but those of us on the service provider side have just gotten used to everybody calling everybody generically telcos, regardless of whether or not they have a mobile network or not. But the, I mean, I think for the most part, Taylor correct me if I'm wrong, this is really kind of, yeah, like the CSP user group in the CNCF. We just all get the telco label. I think so right now. I think it would be equal CSP user group. And to your point earlier on getting input from, I think there's some questions. Maybe Victor, you had asked about vendor versus service provider side. So the end and Jeffrey responded that we want different voices, maybe with the multiple papers, whether it's multiple papers or at least different chapters. I think it would be good to have one actor, one voice for a section so that it's very clear when someone's reading that what perspective are they coming from? It's okay if, if there's an effort, maybe to combine those or talk about how do we integrate or conflicts or whatever else, but it would be good to go down to the end of the concerns of each actor. It's real quiet this morning. Jeffrey, your, your ask was, should this continue? And is it something that the user group thinks is valuable? And I definitely think it would be valuable for this group and specifically to share the knowledge with all the other groups, whether that flows into CNF working group background, more background information for best practices or it goes into other efforts. I'm sure stuff like network service mesh and all the different CNI projects could all benefit from saying here underlying concerns and how it fits together as well as larger projects that may take on building a combination of services. I think someone said earlier they'd like to help. Does anyone else want to throw their name in on this to help from the, the viewpoint that Jeffrey would be working on? I can help. I can help with references and stuff. Was it Ian or someone else that also? Yeah, it was Ian. Yeah, happy to help. I think to start guys, maybe we set up a second document. We're going to pick a couple of things. We're going to pick a couple of things. We're going to pick a complimentary Google doc. And kind of go into the original one. Pick and choose some of the topics. I mean, unless we want to write like a really long document, which is fine. If not, I think we should kind of. Pick a couple of actors and then pick a one or two challenges that those two actors face together. And then, you know, we could maybe do like a series of things. Like a couple of people or, you know, Never get finished. Yeah. Exactly. So I think yeah, just picking a focus. Like we could pick something like, like you said, like observability or software delivery. Or I would say like one of the big ones that always comes up, right, is we do a paper just on the relationship between a provider and app vendor and a platform vendor. Or provider, right? It's just talking about like figuring out the actors, and that can be challenging, right? Sometimes the provider builds and maintains its own platform. Sometimes it builds part of the platform and outsources the other part. But like that's something that in almost all these groups that I'm in, we're always like having discussions around what is the platform responsible for? How do you manage the life cycle of the platform? I think that's the same thing with the application. How does the provider stitch those two worlds together? I think that could be like a potential interesting one to start with. I don't know just because it keeps coming up a lot, but we always have these. For what can this application expect, you know, X, Y or Z, et cetera. Jeffrey. May I just suggest a slightly different approach because. I mean, you're absolutely right. It's not that I disagree. I just would like to, you know, lift up slightly different approach because of the shift that we are seeing. I mean, traditionally that has been very much as all the services had been deployed. You know, there is a network, there is a platform, there is an applications. But now there is an evolving towards, you know, shift from the process centric to data centric. There is a more and more information about automation context and kind of a data characteristics and data granularity. Do you think that maybe there might be a section or maybe there can be an approach to start looking on different platforms that are trying to actually utilize so that we can try to lift up this aspect of data centric solutions and data centric platforms. Just an idea. In addition to what you're currently proposing. I'm not sure what you're asking. Are we talking like, I didn't mean to cut you off, Tal, you go first. Well, if you didn't understand what I said, maybe he can clarify. I'm sorry, Tal, was this a question or? No, it sounded sorry. I interrupted. It sounds like Jeffrey didn't understand what you were saying. So maybe you want to clarify. Yeah, I can look for alternatives to Kubernetes. When you say data centric, are we talking about like looking at different underlying hardware like, you know, memory centric architecture versus compute centric, you know, processing centric architecture. I'm not 100% sure what you're, you're specifically referencing here. I mean, I'm just trying to, you know, the starting point where shall be, I mean, as you kindly indicating, we can still start looking, you know, with Kubernetes and different tools. We can do that. But also, you know, there is a little bit is shift on about structured unstructured data, context, automations, context, information management on top of libraries, semantics, and then based on this type of information, different type of applications and how Kubernetes and, you know, different, you know, solutions still very much cloud native, but the focus or the starting point is slightly different. So right now there's no suggestion from Jeffrey to look at technology. It's talking about what are the underlying drivers before you pick any technology. So the looking at relationships between actors is not a focus on what technology a service provider and a, and a vendor and an integrator, it's not talking about that. It's what are the underlying business reasons. So are you suggesting some different way of getting to this goal, the purpose that Jeffrey is putting forward? Good. Well, I mean, in a way, this is very much related to business, but I mean, there is some kind of new frameworks where you can discover resources, very much, you know, nodes that are using or generating or processing particular type of data and data characteristics, and then you can discover and then you can connect it. But instead of looking at the applications, the starting, the key point is semantics and the data characteristics. For instance, temperature, temperature of the room, you know, different classes. Currently you cannot use multi-typing and then you cannot subclassify whether this room is a kitchen or a bathroom or a living room, but they are the temperature. Then are you measuring the sense that are you providing the data of the sensors in the room? Or are you providing the temperature of the room? Now, if you're going to focus on the applications, which is perfectly okay, we will be most likely providing, you know, as an example, the applications information that is on the particular units that are providing the data. Or are you, if we start... I think I'm clear on what you're suggesting. So what we're actually doing is stepping lower than that. If we were just going to put a stack and say, here's a particular application and then you say, what is it providing us? Well, you could go lower and say, here are maybe data points and statistics on what's being used and what's necessary. We're actually going below that and saying, what are the business needs? If you want to point to any studies out there that say general needs of a service provider and CSPs in general, then that would be great. But we're not talking about applications. Geoffrey is not suggesting that we study the current applications available for Kubernetes or any other platform. Certainly I have no objections to that. I just lifted up slightly different aspects in case because it's very much related to business. It's also very challenging because it's very new and it's also requiring completely different approach. I don't think we have to limit ourselves to one paper too. You could just drop your name below mine and let's get a second initiative going. To Taylor's point though, when you start talking about IoT sensors and how I'm extrapolating data, the specific challenge I'm talking about is I have three vendors each offering me a sensor. I have a business requiring me to drive all three. How do I actually consume this without creating completely separate tool chains for everything? How many layers of abstraction is appropriate to get some kind of point of commonality before I have so many layers of abstraction that I can't actually troubleshoot anything? To Taylor's point, I'm kind of like a level removed to what you're talking about, but there's nothing that would prevent the tug from looking at two topics at once. I'll add my two cents here. I'm confused. I'm looking at the document and trying to understand what the goals would be. It's obviously one level removed from the technologies, but how far are we really removing ourselves from the problem? It seems like if we're talking about challenges, we have to go back to the whole idea of NFV and what was trying to be achieved by combining telco with cloud technologies. A lot of this stuff, these challenges predate Kubernetes. Kubernetes, as I mentioned, if we want to create a document like this specifically within the CNCF telecom user group context, I'm trying to understand what is very special and specific about it. Cloud-native, Kubernetes. Should the paper be specifically about... I can see it going in two separate directions. One, which is very Kubernetes-centric. The goal of this paper is to show what are the gaps in Kubernetes right now in terms of achieving our larger business goals from a very high level. Another direction this can go is not Kubernetes specifically, but cloud-native specifically. That is taking the cloud-native concepts, which could work on OpenStack, could work on legacy clouds. They are not Kubernetes-specific. And think about those approaches and what challenges they might have for business reasons. So right now, I'm not sure which direction we're going exactly, and it seems a little bit vague to me. So that's why I'm not jumping up to help because I'm not exactly clear what the goals are and what would be achieved by creating this paper. Tal, one of the things that you said in there seems to me to be... behind it would be a goal that Jeffrey is trying to put forward. I'm going to say it and Jeffrey tell me if I'm wrong. You said, Tal, that NFE and other efforts predating Kubernetes have tried to solve many of the problems that have been seen. I'm trying to rephrase what I was hearing. And those problems, the underlying problems that may have been solved, either they were solved or they're still trying to solve them, are what we want to write down in a paper. Before ever getting on to talking about cloud-native or Kubernetes solutions, the first thing that we want, which is not documented in this group fully anywhere, and I don't see it publicly everywhere, anywhere within the CNCF and Kubernetes community, is what are those problems? So what problems did NFE try to solve that we can see outside of the technology? Right now, all I see is solutions being put forward, but no information about what is it trying to solve? And I think Jeffrey is wanting to underline. That sounds good. If that's true, Jeffrey, I mean, this is a very ambitious document. And in a way, I think it's... we've reached that point that we need to rethink our initial problems, right? Because a lot of what's happening right now with the move to cloud-native from VNFs to CNFs, depending on who you're asking, it is an evolution, right? With VNFs, we did things one way. With CNFs, we're doing things maybe in a better way. But I think there's a reckoning that needs to be done before just evolving and moving forward. It is worth going back to the original problems that NFE was trying to solve. What were our challenges then? And maybe look at how we're trying to solve them right now with our new understanding of what a cloud can be, right? So in a way, leapfrogging all over the history of NFE. And rather than seeing it as a evolution of what happened before, maybe going back to the drawing table, and this would be the drawing table, and reconceptualizing what are our challenges? What are we trying to solve? Let's go back to basics. And let's not assume that everything that we were doing until now is the right way to go. That could be valuable. It's a big thing, though. I think it's a big thing. Right. Well, and so your initial question, Tal, the answer is generic. Yes. This is also why I was saying we might need to split this up, like get very specific focuses. But to me, there's what you were just describing, which I would think is kind of the initial journey. And then the second journey is, you know, what shortcomings does Kubernetes have? The thing is, though, is how are we measuring Kubernetes shortcomings, right? There's, yes. Your point of like not assuming that we're already doing everything right, because we keep driving along like we are, but then everybody says they don't like how things have gone up to this point. And to your point, like really when it comes to down to it, you know, a VM, a container, et cetera, we're just like discussing packaging really, right? Like how coarse or how fine is this packaging? How am I like carving up, you know, the measurable unit of code I'm delivering, et cetera. But there's things like, you know, like self-healing networks, right? Like way before Kubernetes came around, we had talked about like VNFMs, like re-spinning up VMs that have gone down and auto-healing and this and that. Did it ever really pan out? No. Does slapping Kubernetes in the middle of it, you know, help things? No. So I mean, like when we say we want something to like self-heal, what does that actually mean? And is it feasible? Horizontal scale, is that feasible? Like do we actually want it? There's just all these things, right? Like these generic assumptions that someone put on a document once upon a time. And we keep bashing our heads against the wall and coming up with new ways. Like do I really care if we use Tusca versus Yang versus YAML? Not really. The question is, is can I actually model the network service or the network device that I need appropriately with it? Right? So I would say that it's the latter, sorry, the former is the first goal. But I think, you know, subsequent things you would start to look at, well, now that we've identified what we actually want, can we actually meet those needs with the tools that we have today? And if not, what tools do we lack, what tools could potentially be retrofitted, et cetera? Okay, that makes a lot of sense to me. I think it would be ambitious. And I think we'll eventually have to break down these challenges into areas, right? Some of them are more technological. We're not speaking maybe about specific technological solutions, but specific technological challenges in terms of networking and hardware and support for that. But some of them are really architectural, right? Things like orchestration and as you said, modeling. And, you know, we're not, we're going back to basics to an extent, but we're also learning from what we did learn, the lessons that we did learn from NFE, what worked and didn't work as well. So I think, you know, we don't have to go completely down back to a starting point that knows nothing because we've learned a lot in the last five to 10 years trying to do this. You could say that we've learned a lot over the last 20 or 30 or you could keep going back. I do think we should go back to the very basics and breaking it down into the smallest component that are challenge, breaking the challenges down to where we can focus. And when you say there's a technological or an architectural challenge, whatever it is, what is underneath that? Or we're saying orchestration is important. Okay, well, why are you doing it? It seems perfectly normal to anyone that's managing or doing orchestration management on a day-to-day basis. The problem is you're stuck in the middle and you're not going to step back and go, is there a different way for me to handle the underlying reason why I'm doing this? And this paper right here, or the paper that we had up from Jeffrey, that was the ask, what are those underlying things? Why are we, what are we doing with orchestration? And just a moment ago, Jeffrey was naming a few things. He's actually saying here are some of the underlying things that we want. And over and over in the communities, I'm hearing that the other side, specifically within the large CSP networking, it's the, we already have a lot of background. We don't need to talk about it. We don't need to go back, but there's an ask. I mean, Jeffrey's asking, and I've heard other people in this community that are asking, so that on this particular paper, the idea is let's go as far back as we can with the basics. Yeah, I'm absolutely fine with that. The point I'm trying to make is that if we do it honestly, if we're very honest about going back to those basics 20 years before, then we're opening up, we really have to open up ourselves up to the idea that maybe cloud native is not the solution, right? Kubernetes cannot be the, if we're setting Kubernetes as the goal that we're trying to put, well, then we're not honest about examining the problems, right? If that is the foregone conclusion solution, then we're not asking the question in good faith. So I think if we really are starting with you, we absolutely shouldn't think cloud native is the end goal whenever we're looking at this. We also should not say NFV is, they've solved it. We shouldn't look at any of it. You can go further back and go, oh, there was actually pretty amazing hardware solutions. Let's go back to VMs on mainframe. Well, that's a lot of the software technology we have today is literally from VMs, the hardware redundancy in mainframe. So it's now in your VM and software. So the point is not those, any of those in solutions, it's what was underlying driver. And that's the, when Jeffrey was saying the relationships between the parties for getting the data from these data centers, what is, that's an underlying challenge, which we may come to a technological solution. The next papers after that, that someone could build on in this group, or maybe a totally different group to go, oh, well, we're going to talk about the challenges in doing a, a Kubernetes, that's fine. And the missing gaps, or we're going to do a cloud native non-Kubernetes specific. Fine. But you're going to build it on that underlying platform technology neutral. What are the business drivers? Yeah, I think that's all true. I think the complexity here that it's really not going to be one paper, because the challenges are, it's a tree structure, right? A challenge would depend on what solution you chose to meet an earlier challenge, right? So if you think that the flexibility that you need to solve your networking solutions involves using off-the-shelf cloud software, such as OpenStack or Kubernetes, and that presents challenges according to the choice that you made there, right? For example, orchestration. So I, yeah, if we're going back to basics, I think we have to be careful about not mixing challenges that already makes certain assumptions about how we're going to solve things. I'm for this. I think it'll be hard. I think it's going to be challenging. Yeah. The first challenge is to make this. One thing I left off here town is it was originally on challenges and drivers. So like the big thing, right? I'm coming in. So now that we have the CNF working group and we decided we're talking about cube native versus cloud native, this and that. The tug in my mind should be a little bit more purist. Like the CNF working group has a very specific goal that it is going to tackle. How do we make this stuff work in Kubernetes? And that's kind of come over a few months of debate in this and that. This though, right? I would argue that through some of my experiences, I should probably still be using way more use case specific hardware. I mean, what was I trying to solve? I was trying to solve for uptime, you know, more agility with like getting services out, not waiting like four years for a fricking fire wall to be installed. And then it's like, you know, you're not going to be able to physically or sorry, virtually spin one up. But the reality is, it's like, you look at like the first, you know, renditions of like the virtual pack accord. It was a one VM to one server mapping. Like I would say like at the baseline, we, we took, you know, the VNF model and now we're probably doing it with the CNF model where we're still coming at this like it's an appliance. And so then my, my question becomes, why wouldn't I just run an actual appliance? Like infrastructure is code. Like I could model, you know, I can even model like the topology of my physical network. You know, there's tools for that, right? And like, I mean, someone has to physically go and wire it, but you could technically model everything. I mean, the question is, is what are we really trying to get to? Cause I'll be honest internally, you know, there are times where I tell people they shouldn't be containerizing or virtualizing something. And then, you know, they give me like, are you crazy? You look here, the cloud guy, but I'm just like, look, all it's going to do is add complexity and you're not going to get any of the benefits that we keep claiming come with like a cloud native or a virtual shift, right? So, I mean, was there a lot of great stuff that came out of, you know, the move to VMware and open stack, and then eventually Kubernetes, absolutely. But to your point, does Kubernetes solve everything? Does it create challenges that we don't necessarily need? In my opinion, the answer to that is yes. So, you know, one of the, it's really interesting. This is an interesting conversation. There's, if we're going back to the actual business drivers, right? As you, as you say, some of our problems is that our business goals themselves are contradictory, right? We want to have the cake and our cake and eat it. We want portability, but we also want, we want open standards and we don't want to vendor tie in, lock in, but at the same time, we want all the integration, the powerful integrations that come together with, you know, using a specific vendor and specific standards. So, a lot of the history of this is that telcos, right? If we're talking about the business value coming from the telcos specifically, which give the requirements for vendors to provide solutions, well, they want to have their cake and eat it. So, it's an interesting starting point because if we, if we go by these challenges, then we, you know, we will come with contradictory solutions and difficult solutions sometimes. So, it's part of the two. And again, I think if we're, if we're asking these questions very honestly with good faith, which it sounds like we are, and I think that's a good place to start. Noting those conflicts, right? You know, we want portability. We want these workloads to be, as you said, appliances that you can just run everywhere, but at the same time, we are addicted to very specific features. We want layers of abstraction, but then at the very high level, we want to define things like CPU cany. So, we're constantly shooting ourselves in the foot, I think in the history of NFE in terms of on the one hand, using things that are off the shelf. But on the other hand, doing hacky solutions that outside of the telco world, you'll never see, right? And in the enterprise world, they wouldn't dream, I think, of doing some of the things that we want to hear in telco. So, this is fine. This is all great. I think, Jeffrey, I'm really glad that you're leading this. I think you're the right person to do this. I think it's going to be challenging. And I think it will be very interesting to see how we continue working on this document. And I'll look into it too. I'm happy to step in and also do some work. I feel like my goal here is to keep us honest. So, I'll try to do that. No, I try to be honest too. I would say calling out those contradictions. Tao should be like some of the challenges that we address. Like, here's the thing, right? I will tell you, not me specifically, but you know, big tier one CSP moving to Kubernetes is a business driver for me. Right. So, here's this baseline business driver that I've just said forward that then might contradict with all these other things because certain things don't work good in Kubernetes. So, yeah, I'm very much in the same mindset as you. I kind of want to just call this stuff out. If nothing else, if we could just address this stuff so that we could start with like a neutral point to, you know, at least open up the opportunity to look at other things where it makes sense. I think that would make my life at least a lot easier when I'm talking to other executives and architects within my company. And if you're not allowed to look at something else, if you at least have it documented that there's a conflict and that way you can at least point and say, we anticipate a problem. That would be a good thing. Let's end the call here and tell, can we put you that you'll help and try to move towards a neutral, honest baseline? I'm not the only person who's going to do that, but I'm happy to be joined the group and see what I can do. Yeah, help with that as a goal sounds good. I would just like to add that I like the way Jeffrey framed it. This is going to need to be broken down and, you know, starting with the actors and the ecosystem, because I think that is one big change that's really happened in the last 20 years in terms of the ecosystem and how telecom approaches some of these things. So I think that's a really good place to start. All right. Anything else? We got two minutes and then we're seeing if our group is coming up next. Thanks all. Thanks everyone. Bye. Have a good one everybody.