 Good morning. Good morning. Good morning. Hi, Taylor. Good day. Hi, wherever you are. Hi, Nick. Hi, Victor. Nice to meet you. Good morning. I dropped the meeting notes into the Zoom chat. You can add your name and any topics you'd like to discuss. There are some agenda items that have been added. We'll give it a couple of minutes. Yeah, maybe two more minutes. Let folks join. Hey, Jeffrey. Hey, good morning, everyone. All right. Let's start it. Does anyone have any topics they'd like to have added to the agenda for today? All right. And this call is recorded, like all the CNF working group calls, and it gets published to the CNF work group playlist, which is under the CNCF org on YouTube. That may be changing. Maybe future ones will see what happens as the CNF working group will be moving over to LFN for those that don't know. I guess I'll, before going on the agenda, go over that again for folks who haven't seen the CNCF telecom specific initiatives, including this working group, the CNF test suite, the CNF certification and other things like that. They're all moving into LFN, and there's going to be some type of merging and transitioning of all of the, I guess, related, closely related things within LFN. And the idea is to create a new cloud native focus telecom program within LFN, and then CNCF will be doing the more general domain all across every domain item. So there'll still be networking focus and other things within CNCF, but anything that is domain specific for telecom and networking will be in LFN now. So there's more upcoming events. There's more KCDs, these KubeCon cloud native day coming up. Some of them are one day events. Some of them are two day events, but they're localized. So be watching out for one that's in your area. And there's a few coming up in North America. One is going to be in Guadalajara in February. And I know there's another one that's maybe later on going to be in, I think, in Austin. I was hearing about it. I don't, I don't see it listed yet. So KubeCon cloud native telco day or sorry, cloud native con is Paris in March. We don't currently have a cloud native telco day for that. Anything's on the schedule. Folks are wanting to see it there specifically at KubeCon versus it could be somewhere else. And you should reach out to the event team. I'd probably say sending a message to the via the KubeCon event. And then to LFN to say that where you'd like to see it. If you've been enjoying this. We had 150 plus in person and over 300 for the live stream at this last one in Chicago. All right. Let's pull up the PRs to see if there's anything new, but I think there's only one. Yeah. Hey Taylor before jumping into the PRs. As far as, you know, with, as you mentioned the CNF working group moving under LFN and the certification. Is the certification CNF certification testing going to change and process going to change with it moving over. The reason I'm asking is, is there's some of our CNS I was going to submit an update for the one that we had already got certified last year and then I was going to add some new CNS or do a PR for for submitting our some new CNS for certification. Should I hold off on that? Because it's moving on over and things are going to change as far as the test criteria or should I continue? I would continue. Okay. So that we know the, the first part of this is allow the certifications to keep coming in. So that was stated. And so that would be right now. So if you're, if you have an update for the existing. Or a new certification that comes in in the next few weeks. Then just use the same process that you've been using. Same pull request on the. GitHub repo. And beyond that, the next thing is going to be. They want a certification built on what's there and move all the current products over. And that will mean starting with the process that's working before we do anything else. So what we may have is the repo may move into like a new org. We may move. You know, there may be a new web page. Launch soon instead of the CNCF IO slash CNF that'll probably be like a redirect or something that'll go to the new landing page. For this combined initiative. But all of the short term stuff should mean that. You can keep doing what you're doing and keep submitting. And then we'll build from there. That's helpful. Thank you. I think. If I, I'm just going to go ahead and jump to this and then we'll go back to the accelerating since we're talking about it. The, probably the. What we're going to be saying that'll be different other than maybe the repository or the web page. Would be expanding the certification having some more tests. Specifically for the CNF side. There is talk about maybe. Whether it's this. Same certification or like a subset that's focused on platform. There could be something like that, but the very first thing I think we'll probably see is just more test. So a new version. Would have more test, but it should look pretty same. Similar from your perspective. I don't think it's going to be based on the any new products coming in and just be a new version. And then the other part would be. More officially launching a test catalog. That's going to be based on the. CNF test suite suite of tests, which is. I think it's 84 tests right now that we have. There's more in the pipeline right now. And potentially adding. More tests based on. What's in the etiquette, the elephant etiquette projects are C2. Test matrix. I think there's about 5 tests. That are missing. Although. That are listed as missing that could be added. There's a few of those that are actually already in the test suite, the test suite. So those could be just officially part of this new test catalog. So. This is going to be a cloud native. Telcom test catalog, I guess is what you could call it. And we want to. Officially, like, say, here's a big list and build and get more people involved. The etiquette projects suite of tests. Are all external. They pull in stuff like Kubernetes. Test. Specifically. Select sets that meet the. Requirement criteria. And. OCI specification, so it's pulling in any of those. And different pieces like that beyond the Kubernetes test or the. Maybe the SIG. The different Kubernetes SIG tests that are available. They also run. Two sets of security tests related to like. CIS recommendations and a few others. And. The CNF test suite has the same capability as far as running external tests. We do run a suite from. Cubescape. Armo. Security project that runs. A whole set of similar CIS tests. So we'll probably be expanding on it. On what you see available in the CNF test suite. We'll cover those same set of tests and then we'll. Be adding anything else. But the idea being. Eventually you should have sets of tests within the. This test catalog that can be used for. Different purposes, including the CNF certification. And then we'll be working with like the FIO project to add. More tests around. The deployment. Side of what they're doing. Going along that pipeline. And. They have a lot of stuff using. The K. P. KBD project. So that's going to. Work with. I think get ops patterns and. Configuration and code. So there's. A lot of declarative configuration stuff. So I think those are the. Like the expansion. Beyond, but. To me, it seems like it's, it's going to be aligned with stuff. If you're familiar with any of the. CNF. Projects, the test suite certification, it should. Feel familiar and just be. Expanding. Okay. That's helpful. Does anyone else have. Questions or. Comments on this. So. There is a. There was a alignment workshop. And that. Added more details onto. A session at cloud. Cloud native telco day. For those folks who didn't weren't there. It is. Was recorded and it's. Available online now. And the program alignment workshop. That had folks in onsite. In Chicago and remote. We've added a. There's. Notes from that session. Where we were trying to gather input. So with a lot of. The chain. Transition and changes I think for the. Certification and test suite. A lot of those are. Pretty straightforward, but there's a lot of other projects in LFN and. How does it all fit together? What do we want to do first? And. That was what a lot of this was about. So if. If you're interested, you can go look at that. Taking. A lot of input ended up going with. Sticky notes and trying to gather the themes. What do people think? So if, if you have. Your own feedback, it'd be good to. Go through this and. Probably be opening GitHub issues. We have the discussion board. So. And of course, the slack, if you're. Not in there. All right. I'm going to let's see, go back to the. Pull request, which I think there's only the one I had it up earlier. So this is the. A white paper. That's. The contributors and. Authors for this were CSPs. There's a list of some of the folks that were involved. At this point, we're getting feedback. And suggestions from a wider group, but. Is anyone not seeing this white paper. Is this new for anybody? All right. Does anyone have questions or comments that we could talk about life? Jeffrey, you had some. Stuff in here. It's kind of hard to really make any suggested changes until we. Remediate some of the existing ones, I think. All right. I mean, I'd say at a higher level. My only real, you know, like macro level feedback is. There needs to be an acknowledgement on the other side that. A cloud environment will be provided with certain, you know, guarantees. If people are going to write cloud native software. I think people kind of conflate. Certain things when it comes to cloud native. I think one of the reasons the whole notion of cloud native, you know, software principles work is because certain cloud providers provide SLAs and certain guarantees in their cloud. And to kind of demand that CNF vendors do X, Y and Z. Without knowing that there's actually infrastructure to host software. If it's designed the right way, I think is a miss in this document. Just an acknowledgement of if you build your software like this, we're going to provide the infrastructure needed to run it. You're talking about just the. Maybe the compromise between CSPs and the providers and creators on on what. What's going to be guaranteed what to focus on. And where. Things can be relaxed. No, I just think there's a lot like so the last one was a manifesto. Okay. So a manifesto is this is all the stuff I want. I got it. And it was about accelerating cloud native adoption and telco. And so I feel like, um, instead of just saying once again, these are all the things we want to do it or else. There needs to be an acknowledgement. Like. I mean, you read some of the comments. It's like, well, you know, the acknowledgement is, is that I've got Kubernetes running. And that's the de facto. I'm like, that's cool and all, but you can deploy Kubernetes on really crappy hardware. You can deploy Kubernetes wrong. There's no acknowledgement of how. You know, CSPs are going to shift to ensure that they have environments capable of hosting the software. And it's the same thing goes to the other big topic of. You know, there's kind of like a poke in the eye of. Vendors only do this so that they can upsell, you know, like pro services for deployments. I would argue it's way more about a risk mitigation practice where. They don't like to give up control because they're held to SLAs with financial penalties to it. And it's way easier to provide an SLA. If you. Write a black box that you control everything. So. Basically, I mean, you don't have to put any of this in there, but like if you want CNF vendors to take stuff serious and come to the table, then there's got to be kind of like a meeting in the middle of. You know, if we're going to do things differently, then providers have to agree that they're going to do things differently as well. And I guess it's for the record. The same way you deployed every other piece of software for the last 40 years doesn't count as doing stuff differently. So when you're saying the provider providers, you had mentioned essentially, I'd say like the hyperskillers and then are we saying the communication service providers, the CSPs, the CSPs have to do something different or the hyperskillers. The CSPs. Okay. So in the early days, people would be like, you know, oh, we're not Google. We're not Amazon. We can't do it like that. But you want people to provide you software that runs in those types of environments. So then. I would argue that you need to provide said types of environments. And I don't, I don't really want to speak for the CSPs. Ideally, we'd have someone on here. My observation would be some of them are trying to change what the environment is. The Orange had a experimental network. And that's really just coming out of experimental. So thinking, I guess one thing to maybe start with would be from the CSPs perspective, they're still very much in this transformation. And that's not done. They're not looking at this as everything's already cloud native. And everybody's moved from doing it the same way to, and what do we mean by cloud native? I guess people are still working to try to get things built and operating based on this new environment. So Kubernetes native would be your taking advantage of the attributes and properties of the environment. It's actually built to use those versus it can kind of run in it. And from the CSP perspective, I think that's the main thing that you're seeing here. So the manifesto was very high level from NGMN. And what was communicated for doing this paper was we need something that's moving towards a more actionable items. And then I think with where they are right now versus say a year ago or two years ago, Jeffrey, they weren't running those environments and they weren't fully in production and they weren't like even six months ago, you were barely seeing anything actually in production. Lots of publications online from all parties, integrations, clouds, the providers, the creators of the software saying things have been in cloud native for years, but you're just starting to see them. You're making my point, though, Taylor. If they don't actually have environments to host the software that they're demanding, then why would anybody write said software? That's what I'm getting to. So Dochitalcom in September just launched their production Kubernetes environment that uses like deployments with GitOps. If you've seen the Doch Chef project from them, that's on GitHub and there's a lot of different components. They're using Flex and a bunch of other stuff. They just launched it, but it is there now. So when this is coming out, it is after that, but this is new. So I'm tying it in with the statements you are making. I think if they put this out two years ago, it wouldn't have been very useful for exactly what you're saying. There wasn't anything there or they would have needed to really work with maybe the cloud providers that were actually ready at the time, which would have been very few, the hyperscalers, but they have just started launching. So I think that would tie in with it. And I know that some of them are taking a harder stance on saying, here's how we are managing and deploying and we're matching this for our actual environment. Like I believe DT is working along that with whoever they've been working with. Orange is, I think, more tying in that experimental. And then they had, I think a lot of the stuff you'd see with the Linux Foundation Europe, Silver Project. There's a lot of that experimental cloud that they did. I think it was three years ago when they started that project. Well, a lot of that's gone into there and they are now using stuff like, I think they have Argo, but they have Flex workflow. I don't think they use Flex CD, but I think they use Flex workflow. So they're actually using some of that in production now. So they have full environments where they'd say, this one's ready. Of course, if it's just Kubernetes running on a OpenSat cluster and they're not even running the Kubernetes cluster in a new way, it wouldn't matter. But they do have areas. And I think that's the areas that are ready that are being run in a new way. I think those are the areas they're actually wanting. This is stuff to apply. Yeah, but this is missing my point. For one, you know that I'm a huge advocate of meeting all the requirements that are listed in this document. There's nothing in this document though. So you keep mentioning DT, DT is a pioneer. If you're Ericsson, you're writing software for all providers, there's nothing in here that says we as the provider community are going to change to accommodate what we're requesting here. And I'll give you an example of just someone as large as Deutsche Telecom. If I'm going to write software, as Perz stated in this document, what's the acknowledgement that I can write software consistently and that it's going to deploy consistently across your network, right? Like if I start building things from the way that things are listed, I mean, I saw 12 factor listed in here somewhere, you know, there's all the notions of the resiliency stuff at the bottom that was being debated, et cetera. But is your core team and is your RAN team and is your, you know, IT team managing OSS, BSS. Are you as a provider going to get your other providers to come along on the journey with you? And are you going to run a consistent, because once again, I'm going to point back to the hyperscalers and why cloud native works. I write to Amazon's APIs and it's the same every time. I designed software knowing that there is a constant, you know, known quantity from an infrastructure standpoint. So that way I can write reproducible tests. I can make things, you know, more tolerant to like memory failures and I know things like that. Why? Because I have a guarantee from the infrastructure provider that if, you know, no day fails, it's going to taint and all those pods will be rescheduled over here. And that real estate is available. All I'm saying is there should be a small mention somewhere in this paper that providers are going to meet them halfway and provide the infrastructure need and simply stating everybody's going to run Kubernetes is not good. In my opinion, because you can deploy Kubernetes in a craptastic manner. So that's all I'm saying is like within this paper, we say we want all these things. And to make that worth your time. Us as the provider community are going to start moving more towards X types of operations, whether it's get ops, whether it's cloud ops, whatever you want to call it. But if you write your software to do all the things that are listed in this thing, doesn't matter if you're deploying with our core team or our brand team. It doesn't matter if you're deploying at AT&T or DT. Your software is going to deploy and you will have a reasonable expectation of being able to support it. And roll updates because this is the, you know, direction we're all going. And if you make this commitment to us, we'll make that commitment to you. Like groups doing great things. Like when at Ericsson want to change their entire like development methodology. Right. Okay. There's, I think three main things. Let me try to respond. So the first would be a lot of, from what I can tell a lot of the folks are changing it within some area, even if they're saying they haven't done anything in others. I know Ericsson has been doing some of this already. As far as how you would operate and how the actual network functions are implemented and run in a Kubernetes environment, it's already happening. So there are at least some areas. These are big enough companies when you're naming Ericsson or Nokia or Cisco that they're going to have different departments that are maybe in different, you know, different levels of adoption if they're going to do it. And some of them already are. And I've seen stuff with like Mavener where they've done tons of stuff. As far as anything partnerships with Mavener, any of the applications that are running are using a different model for how they're being deployed and managed and everything else. So I think some of this is already happening. But we're talking past each other though. All I'm saying is that acknowledgement needs to be in the paper. I know this is happening. Like I'm saying there's nothing in this paper with this giant list of demands saying, we're going to meet you halfway. That's all I'm saying. Yeah. The paper should acknowledge that providers are also going to change so that vendors can feel safe doing this. That's all I'm saying. I think maybe a concise statement on that would be good because there's a lot of areas that you're hitting. So something on that for the recommendation. What I keep hearing is you wanting to the service providers say we are committed to moving to a new, this new architecture. We're going to be adopting across the board and the model that we want to use for the management is whatever related. I think that could, if you can put that in there, that seems to match. And I, I'm not seeing it here. It may be up in the other areas. I was trying to look the automation and stuff. There's some of these in the requirements and in the challenges where I believe. It's implicitly requested or assume that it's already understood. And I'm saying that because of comments that I've heard from the providers whenever something's written in. So when they're talking about. Deployments like this. They're not thinking. Okay, just figure it all out and hope that it works. I know that this has to do with the providers are committed to making their environments work with deployment tools like this and patterns. Like the get ups patterns and practices. They didn't put it in here because they think we're going to just leave everything the same. And if you change it, we just hope it works. They are changing. They're not wanting them to explicitly say, we're going to provide an environment that works with these things. Okay. That's, that seems like a pretty easy ask. And I recommend you for if you want it in. Then make it specific to that and put a comment in. And I'll try to, you know, tag everybody as well and, and have a look at that. What you're asking for, I think is already happening and what they're planning. I'll agree to disagree. I would say that this is the list of a very select number of advanced providers that we work with regularly, that may be doing some cool stuff and limited pockets. But if we're going to ask all of the different CNF vendors out there to shift, then I mean, this is like the early days around like, you know, network standards, et cetera, right? Like when we moved to TCP IP stacks, et cetera, when everybody had their own things. This is like the early days of like IGPs when like IGP was Cisco's proprietary special mojo and it was fantastic, but everybody still went OSPF or ISIS because they needed to be able to run across the board. I mean, like having a couple of really savvy people who are doing cool things saying, oh, we're already doing this. So conform to us. Doesn't really work when, you know, you're writing a DU for all providers. So like you said, it's just a small acknowledgement of if you do this, because once again, you just listed a bunch of tools in that section. You just showed me that tells me nothing that you're guaranteeing that those tools are set up correctly, that you're going to have operations teams that are able to ingest my software correctly. I mean, if everything has this pipeline, but it's still hard swivel chair, which is where 90% of providers are. Like I said, we can't take the top 10% and say everybody is going to shift everything for just them. That top 10% who are the thought leaders need to give an acknowledgement that they're going to bring everybody else along with them. And then this becomes the new de facto standard. I don't think you're, I don't, I'm not really sure what you're asking. The CSPs are not going to be able to force all other providers to do this. There is a major effort from folks who've been involved to try to get people going. Just like the instrument manifesto, they made a lot of effort to get people onto that. And there's other providers that are on the instrument manifesto that have expressed interest in this. And there's people like Sana who was on both. She was interested in this effort. They were actually happening simultaneously, but it was decided to focus on let's not even do the manifesto since that's being done. Let's do this. So I think you're going to see more providers that were on the manifesto and adopting this. But that's going to be a large industry effort. If you're as far as continuance to who's going to be saying yes. And then DNA, they're not, they're not something one we've seen. And there's other ones that aren't on here because they haven't been available vacation or whatever during the time when we're doing the signing, but you'll see more. I don't think tell us we've never, we never saw them other than open source summit and Vancouver like four or five years ago talking about CI CD. They weren't signing on to like try to push this because partly with what you're saying, they just, they don't see any movement. So they decided to do their own thing. What is tell us doing for part of it? They're running 5G core applications that they built. They just stopped working with vendors and they started hiring people and they have an internal team building some of their software. And they're running it and AWS. And they just built their own, but they're following like deployments and stuff. But as far as what we're talking about, you have to start somewhere. Jeffrey, we're not going to get full agreement. I'm not asking for agree all I'm saying. Let's look at the tell us example. If I'm the development team inside of tell us writing packet core software, you know, I'd probably rather deploy an AWS because I get a known quantity from the infrastructure there. All I'm saying is there needs to be an acknowledgement because all this is, is a giant list of demands. They're good demands and demands. I agree with wholeheartedly. There has to be an acknowledgement though that like I said, like you have a bunch of names on thing. This is a bunch of people saying we all collectively want this. Okay. Well, what if all the CNF vendors wrote their own thing and we've made it. Here's our giant list of demands, right? Like they could do that too. I'm not saying they will not saying they should. I'm just saying this paper has a lot of requests. Like there's even you put the suggestion and maybe this should be should versus must or things like that. Like you have a giant list of demands. Then there should be some type of acknowledgement on, you know, how you were going to meet the people you're making requests of. Right. So I think the big sections dependency CNF shall do this. They shall do that. Like. What is the guarantee that if I write all of this, the way you want me to. That there's going to be an environment to host it. And I'm not asking for like someone to sign them. Blood or give up their first born. I'm asking two to three sentences in a paper that says, we acknowledge that things are going to change on our end too. And we are going to continue to refine our infrastructure to meet. So I think you're saying this similar to what you were saying earlier and my response is same. You say what you just said, put it in as a suggestion that something like that. In fact, I would say, write it up as a, I suggest something like this. What you're saying sounds fine. I don't think. There would be a pushback for putting in that because. From my perspective of everything I've heard. They already. Assume everyone knows that that's what they're trying to do. And you, what you're wanting Jeffrey is for it not to be an assumption, you want them to explicitly state that they're going to try to do that. And I don't think they'll have a problem with explicitly stating it. The stuff that. It's right in here about. Business commercial model. This is actually related. To an acknowledgement. So it's not the same acknowledgement. But it's talking about. The providers need to make sure that. How this is fitting together. And working with the, the. Creators of all the software. That there's a business model that they can continue on. And. The reason why I'm bringing this up is not that it's, it is addressing what you're saying. I'm bringing it up because there is an acknowledgement that. If there's not a way to, you know, make money within this change, or if you can't do something, then. What's the incentive there that needs to be part of it. And there have acknowledgements in a lot of different areas. So what you're saying just needs to be made explicit. So. This is the section I was specifically called out. This is where I put my comments and notes. Well, I like create a new equilibrium and win-win. How is it win-win. I see the providers winning, which they need to, but I'm just saying like. And we, you and I've been talking a lot. I'm curious on other opinions too, but in this paragraph right here, the one that we have up. You know, it's we're going to do all this stuff. But it doesn't actually say. How vendors come out ahead with the providers in this. It just, I mean, it's all architectural. It says you guys are doing this because you want deployment, pro services, money. And there's stuff in the comments too where book and I talk about like the notion of SLAs and the notion of being a prime, right? Like, but that paragraph we were just on, it talks about win-win, but I don't necessarily see the plus side for the vendors. Like, how do they ensure that they continue to like provide SLAs? You know, like, there's nothing in there that like necessarily, because right now in their minds, black box, big iron hardware is, is the wind for them. And we need to convince them that they need to go down this path. Right. So this paper is not that I, I agree with you on a lot of these points, but I think the very first thing to start with is this white paper is not going to try to address everything. It is not going to lay out. Here is the plan for vendors that is going to make money. You just need to show this to all your business folks and the technical folks and they're going to go, yeah, we're going to do it. We're going to make tons of money. It's absolutely not that. And I don't think the providers are going to do the work for that. And the other thing I would say is this is a, the manifesto was the NGM and all of the providers saying, Hey, we're not happy. And here's the high level of that. And what this really is Jeffrey is the, we can say that there needs to be both sides and all of that. But the providers have the, the largest voice in the industry because there's more of it. So it's happening all the time when you want to look at best practices for running on Kubernetes, I can look at several of the integrators, the providers that consulting for telecom and see blogs and stuff that have been going for a long time. It's happening there. So what this is is trying to have the providers have a voice of what they're trying to get to. It's trying to reach a balance. There isn't a balance right now. And that's what they're trying to say and what they're wanting to do. It's not going to address everything. So we need anything that you're wanting you, you're suggesting, we need to make sure it's, it's minimized on that. If you want something like this to be addressed fully, it should be an entirely different paper or document or whatever. It's an effort completely different. This paragraph could be in a, a whole paper with a massive number of references. We could have lots of examples, everything else. I have a question. I used to work for telecom. So is it everybody? Cause it minus Daniel industry, they are big providers, telecom providers, network providers. And there are new providers, like using the cloud native technology and then of course, there are actual equipment or server solution providers. Are the actual interest aligned? Cause at least the, on the emerging new providers and existing telecom providers, the actual interest is not always aligned. It's sometimes even conflicting. So is this addressing that problem? Is it just addressing the need for the big providers? So if I'm understanding right, are you, are you asking, are, is this trying to take in consideration new providers and, and new, I guess. Networks and stuff that are being created completely different from how they were in the past. Yeah. Yeah. Who's that company in Japan for God's sake, that's basically become a telecom kind of overnight, not overnight, obviously just a couple of years by adopting, at the time it's not cloud native as virtualization technology, they're going into cloud native now. So there are a lot of the private 5G and all that stuff. So that interest is not that they align with existing provider like AT&T, Verizon, who have already invested a lot in the existing infrastructure. And so I think to be aligned, the actual requirement need to be much higher level than specific, because there is a lot of things that the existing provider may not want to lose the ground fast to new providers. Yeah. So there's, I think it is to simplify. Yes. I think that consideration of that is there. I think you're seeing at least when you look at stuff like, you know, and these are in references, but the 12 factors for compliance. Okay. So a lot of this is built off of what you would do, like the 12 factor apps. I'm in the wrong area, the references, but this would be built off of 12 factor apps. So yeah, down here. And I think you're seeing some new services that are just saying we're going to build our entire environment and all the applications are going to skip what's done in the past as far as telecom networking. And we're just going to take on stuff that you're already seeing in other domains for running these applications. So they're just jumping away ahead. And when you look at someone like orange saying they're going to have a fully automated network capabilities by 2025, those new organizations and efforts that you're referring to, some of them are just saying, we're building our network to use automation today. It's there already or dish wireless. They are trying to have APIs that are open and available for vendors to come and write integrations as long as they follow the APIs. You can have integrators and other platforms provide services. So that's innovative, but that's an older company, we could say, but you do have new companies that are just launching and providing those APIs. Well, I think what you're seeing here is primarily moving towards stuff that you would already be seeing in those newer companies. And then the other one that I want to point out would be DNA. So Finland. One of the things that has been mentioned by folks like Joanna was what about scaling down for providers that are smaller? So when you look at someone like orange or DT, which has the T mobile side in the U.S. who's interested in some of the work that's happening. Well, DNA is much smaller than any of them. And they've been complaining that the integrations that come to them, the integrators, the provider, I'm sorry, the providers, the creators, the vendors, all of the folks that bring solutions to them. They're bringing them stuff that's meant for the very large providers. And they need things to be able to scale down and fit for more options that are flexible to leave only what's needed. So I think going that way also fits with these new offerings that you're talking about because you need that flexibility and you need to be able to scale it down or whatever's needed there for those different options. So I think it's a good fit. I don't know who you're talking about in Japan. If you have access to the document, please add it or you can send a message in the chat or the Slack channel for the working group. I'm primarily familiar with like entity and some of the other companies there or there is a there are a few. Yes, on that. I think they're more of the creator side companies. Oh, yeah. The company is called Rockerton. They basically build your own. Telecom platform utilization from ground up in a few years. Become a new telecom provider. All right. Yeah, I think it is a fit for that. But we, you know, we, this isn't a done. And I think one thing to think about when for this list and everything is it should be live. It's a living document or say, and this stuff would be changing. So if there's things that are valuable for new companies like that, building new things. But we're, of course, talking right now is more of the Kubernetes type environment. So if they're using something completely compatible, it may not be a match. But if it's if they're building stuff that I would say is Kubernetes native, they're building it from scratch, then they're probably going to have inside into like the operational side management and everything else. That's good practices as well as, you know, the patterns and and anything that could be implemented or extensions and other things that we're starting to see. If they have insight on that getting them engaged should be good. Otherwise, we're going to have multiple iterations of this. That'd be the other thing. So this is trying to say, here's the first version. We could add more. I do think some of the explicit stuff Jeffrey had mentioned would be good. And if anyone has anything else, please add your comments. So we're coming top of the hour. November 27th. Do we want to keep that? Which ones are we going to keep? We'll cancel the 25th. That's a meeting. January 4th. So these are usually holiday type. People are off about the 27th. So anyone have any thoughts on that day? Well, when does the transition to the networking happens? I mean, I guess that this will somehow concern these calls to that's still in discussion. Like what would it look like? Well, I think that was some folks that didn't make it today. I think Oliver had some feedback. But I think one of the main things that has been said again and again was there should be some type of new program or project that's created that's taking all the different pieces like the networking group, the test suite and stuff, within Elephant. So a new program that hadn't been decided on. And then, you know, what's moving over is there going to be any multiple groups? Is there going to be something focused on the certification itself? That's all in discussion. And I think for now this group will just continue. This will be the place for any of those discussions. Okay. Ideally, we'll see, you know, more folks that are interested join going forward. All right. Let's see. So the 27th, I guess. I'm good for next week on Monday. So I'm okay with keeping it. Yeah, unless it's kind of linked to the holidays. Yeah. All right. We can continue on the slack if there's a bunch of folks that want to cancel them. I can do that. Thank you. Have a good day.