 We'll give fix. Oh, hey, Nikolai, just dropping me under the channel. I'll give it a few minutes, let people join. Did you attend the FIS summit last week? Nope, I don't know that it's happened. Was it a virtual one? Well, it was virtual and in-person. I didn't go in-person, but I did attend it virtually. No, they're here for recordings. I hope so. It looks like the recordings have been uploaded to the wiki page for the event. They have one recording per day. So like 12 hours worth of recording and then they have timestamps by the different talk areas in the wiki. So you got to scroll through or whatever to the specific time. There's some good stuff. TELUS was there talking. Orange did a, I think it was a virtual talk. A lot of stuff on Oran interoperability. Speaking of recording, this call is reported. Seeing a working group. These meetings. Recordings will be posted on the CNCF YouTube and the CNF working group playlist. You got any agenda topics, Nikolai? Nope, not really. Let's see, upcoming events. KCDs continuing. Have you attended any of those, Nikolai? The local regional. I think Tom is going to be at KCD in UK, London. I don't know how you get those on. We had one that was going to happen pretty close to myself, but it. It got canceled right before it was up, unfortunately. Let's see. We're going to be in. Cube con and Claudio. Coming up in November. And guess we do have. That one's virtual. We have a stream, I should say for that. Are you read? Are you. Connected remotely for that one, Nikolai? Are you going to be in person, Chicago? Chicago, no, nothing personal. Yeah. I might. Remote it, but might consider. All right. Trend to ramp up interest to be able to communicate for the EU. What needs to happen there. So a lot of changes. So you didn't see at an FAO. I guess I'll just say it here, but since it was. Announce there and it's now at least public on the wiki. There's. And I think more announcement specifics will be happening at cube con, but. There's been. An effort between CNC F and. Elephant. Try to provide some type of unified. Testing and certification and a bunch of other stuff, which would be related to the CNF working group and. The test suites used by Aniket RC two already, and by Silva, Silva project and Linux, Sonish, Europe is. Using both Aniket and the CNCF. Test suite and best practices as parts of what they're doing. So I'm trying to find a way for the elephant and CNCF domain specific stuff to be. More unified when people are looking to work on them or. With where they should go. So. There'll be more of that like during clad in telco day and keep con announced and trying to figure out where that should be. So it'd be good to get feedback on. Stuff like the. CNF working group home where it should land. What makes sense. There's been some. Feedback from CSPs about having. Continue to have. That I guess the horizontal across all domains. Input and collaboration from CNCF. While having the domain specific stuff in elephant. So. I think it would be good to figure that out. I've been back and forth myself. It seems like something like the CNF working group would be good to have within CNCF though. For itself, even if maybe. Telecom specific challenges would be addressed directly under elephant. The best practices that were maybe even just if we just talked about cloud native best practices and not just. Networking and telecom specific, there'd be some type of working group to feed back in. Maybe have. Expand what happens in this group. We have had some people note that the best practices that we've been working on and publishing are applicable for any application. So you could just say cloud native applications running in Kubernetes and. And then talk about. Platform stuff. If you look at things like Deutsche telecom and. Chef. For deploying doing deployments and they're using flex. Well, they're using get ops patterns and those are not specific at all for. Telecom, those are. You know, would be good for anybody to pick up and. Even nephew. They're their use cases and stuff are really focused and the networking world, but. What they're building on, especially like KPT is not networking and telecom specific KPT is usable by anybody. So anyways, we need to figure that out. Where that goes. And I think that would relate to stuff like coach your nominations. If the work, seeing if this working group stays under CNCF. Where does it fit? Does it just keep floating at the top? Do we do something like put it under. The app delivery. We were kind of staying separate because we thought it was a little bit of tag networking a little bit of tag. App delivery and several other things. If it goes, if this group ends up migrating over to. Then what do we do about coach your nominations? Does that make sense? You have any immediate thoughts. Yeah, I mean it's interesting to see how something like this evolves over time and as you said you said it at some point you realize that. I'm not that specific as one kind of thought in the beginning, but I think that that's more or less what was the point of the whole effort right that. Whatever the cause require. I'd like is raising the bar for overall like require months towards the infrastructure, the reliability, high availability and so on and so forth all of this actually can benefit the rest of the ecosystem as much as. And the other way around all the practices around specifically around deployment, you know the flexibility that the cloud native is bringing. It's definitely benefiting the telco so I think that the ultimate goal. But what I'm hearing here is more or less like we're close to it and it's like that that there's not that much difference between the telcos and the regular enterprise type of workloads. Okay, of course, the differences are there and probably will stay, but they're kind of shrinking. And as you just said about that does shift. In the end, the practices are just a regular application practices not not anything that's not new and if you if you look about it I mean the version of the telcos like 20 years ago. There was still all these crazy specific protocols going around. And now we're talking that even the way that the applications are being deployed are more or less aligned with the rest of the world, which is which is a huge huge huge step forward. So, where should it live. Yeah, maybe as you said, being part of the hub delivery probably makes sense. I don't know what the other options are there I mean specifically within CNCF. Hey Victor. Hello Taylor. What happened during the FIO as far as the discussion about CNCF and LFN and then where would that put this working group, you know where should it land. And that would be suggestions and recommendations for CNCF and LFN on that and that relates to like the co true nominations. If we have a something like this working group, whatever it keeps the same name change name or whatever but the season CNCF fine for nominations if it doesn't then doesn't matter. And there is a request from hearing from like some CSB to have something overlapping so it's fine to have a unified front and wherever it should be so the domain specific stuff maybe the testing and certification under LFN but where does where do you have other stuff. And there are people that are happy for the adoption that next I was talking about where are the general purpose cloud native practices that are the same everywhere are being used the same in telco space. And it's where telco is no different than try to use the same practices. So, where should this working group go. Would you put something like the chef, if it was a. You know, I mean it's, you know, specifically for the show telecom. What if you had a version of this that was just take the engine and the ideas and not say it's for telecom it seems like. Okay, this would just be a get ops based. deployment thing, kind of like an FIO is really general purpose capability. Yeah. So, so I think, like, I think that there is like a more DevOps adoption and I'm going to try to expand that idea I mean, we have been saying that for years and it is not something new but the way that I see the things is like. If we see in the past, usually operators, try to build the infrastructure and provide whatever, but it's available like they have a free devices or any special other features. So, and usually developers didn't have like that knowledge like even in the way that we validate that certified workloads. Like, I mean, I can check out. Think about it like in the past where we have programs which were certified. Just infrastructure like using an okay and that all the efforts and all the initiative people are just focusing in just infrastructure. And later you have to certify your, your workloads like with our problems. I guess, like the major difference in FIO is, I feel like it's more like application driven, like, who is going to dictate what you need from your infrastructure perspective is obviously going to be the, the app. So, so now the CNF the vendors has to dictate like, okay, this is my app and the things that I need for my app. And the infrastructure has to provide that like that. And I guess that that's a major difference like that, because in the past, yeah, you have to do different rules for a different two different things, and no one was showing things. Yes, that's a secret sauce for me like an FIO is like offering like saying, well, this is my, my package, my KPP package, which is provided in this particular CNF application and the CNF application requires these cluster requirements. And if those things are provided or not provided, or you have to create like a new cluster just for this single app. I have to create it. I guess that that's major difference compared with the other applications and other ways to do it in the past. I mean, maybe it's my just perspective for So, so in that sense, I guess, coming back for like what we have is trying to combine the, the, the, the certifications programs like, like the, like the LSN certification program with the CNF, CNCNF program. I guess I didn't make sense because I guess now how mainly the application is going to dictate the requirements and we need to think about different ways to set side workloads or provide like a secure way to provide certain level of certainty for the, for the consumers. And are you referring to telecom workloads still? Like, like, like, or just workloads in general. No, just, well, in this particular case, yeah, I guess, I mean, so that there's still a does a request to have like cloud nativeness for the telecom workloads. It would be how do you help with those additional ones and FAO is trying to cover those with what are the practices for using operators and other things for operator pattern and other stuff to provide additional capabilities for CNS. On the other hand, I don't find that to be make make a very strong driving motivation that telecom workloads are so different from everything else that you're going to need operator patterns with a framework like FIO that would never be used anywhere. The very first place I think of would be similar to telecom edge deployments where you may say we need this type of performance. We need this, you know, whatever capabilities and it's different from other applications. But then think about manufacturing on edge and not the not the communication standpoint, just the capabilities for, you know, near, you know, instant performance or whatever, you know, real time performance. When you say real time, it's always, what do you mean by real time but you AI models push to the edge and having to do decisions that are near real time to run manufacturing things that have nothing to do with potentially that the communication side so you may still want that you may need to have like high speed networking capabilities, but that can be in addition to say a AI models that are pushed down and then run locally on the edge and then are making decisions and you need to make sure that the processing power, maybe you have specialized chips or something like that, or you have sensing data. You have specialized equipment and you need to interface with that. So then how do you do that and think well, you should have a, you could still have a modular application and something is focused on the AI model and something is focused on gathering sensing data. So I still think like a lot of the same challenges are going to be in other domains. Yes, like, I mean what what I was trying to say, like, like, maybe in the past, like, I mean, I can take, for example, I don't get an example. We were trying to model or expose as many about this as possible, like, okay, the infrastructure has to have support for multiple weeks, and you have a, I mean, just the model or the reference you have to have like maybe or genus or anything like that, but probably your CNS never required that, like, I mean, it was super, it was great, like with a single interface, it was working fine and it had to, and there is no reason to think about an extra network interface. So I think that's, I guess, the major difference like in the past we were like trying to expose as much as as much as possible, even when we probably know that the, the, the workloads never going to be as a model them or are just a portion of them. So I guess I think now that the difference is like, okay, well, maybe as you said, like, this is a traditional workload, like, that doesn't require like anything special like high performance and anything like that. So, I guess, who has to dictate how the infrastructure has to be mostly like the application per se and who is going to express the intent like this is my intent of infrastructure. I know that I have all these capabilities, but I just need this working. It really makes sense, as far as communicating that intent, intent driven, integration and deployment and all of those things that those type of patterns are not specific to telecom. We're telling the telecom application developers and, you know, whoever's doing deployment and the consumers that this is the practices. The, how you should actually do it. That's what we're trying to say, and that's not telecom specific. We are trying to help the telecom take on practices, but we also want other people to do the same thing. So then when those application developers for networking apps are trying to inform the platform or destination, wherever they're going, what they need that they're doing in a cloud native way. So that I guess this gets back to, you know, the question and we're not saying today, but we need to be thinking about it. Where should this working group go, you know, when it says a CNF right here containers should handle single concern and service. We really are just saying any application, any application running in cloud native environment. Should try to have each of its containers handling only a single concern. So you break your services. This is related to microservice patterns. And we want to encourage that. We were targeting with the use cases in the language we were targeting. The. Helco domain and networking. Application developers and trying to communicate that. Because we're saying this domain is behind really is why we're doing it. We're saying you're not taking advantage of DevOps patterns. You're not taking advantage of. Microsoft is micro service architecture patterns and practices. And if you're running in those environments where. They were designed. These platforms Kubernetes was designed to run micro services. So, if you're not running micro services. Then you're going to be limited in some ways on Kubernetes. Because it was designed that way. But where should we go. Do we do we try to encourage that there's a CNF working group equivalent to what we're doing here within elephant. Victor. The, you know, I've, I've been on the project along with you for years and it's not the same as the CNF working group, the way that we've been doing it what we've been trying to get through. And should this group move under elephant. Should this group. Stay under CNCF. Should we change it to make it more generic put it under. I think next slide you were saying maybe under the app delivery. What do you think Victor. Talking last week with Oliver. He's about like. They asked. Consumer of these particular programs. Are the occasion. And you think about like a from the consumer customer point of view like. They have if we have two separate programs where they have paid for everything with a membership and in order to get the batch and all the things. Yeah, you're putting basically the, the, the bar more higher, like, okay, I'm going to pay two members sheets. I'm going to apply for two different programs and I'm going to get the double of the batches. I think the double thing, so the double benefits. I'm not sure if you are providing that particular double benefits. So, so probably the answer is like, if we are offering the double of benefits, the double of customers or double of income for the participants. It makes sense to keep them separate. I mean, just trying to be more like some empathy for them like that. The other thing is also regarding try to coordinate efforts. And usually we are the most the same people working in both places. So maybe that can reduce the number of disconnection. So I see more reasons to try to unify efforts instead of keeping them separately. Of course, like that, complete different two topics, different domains, one is obviously more for infrastructure for people supporting these cloud service providers and just more for seeing offenders. So obviously the expectations and things are more, more different. To keep it separate. Well, we have been doing this for years and maybe we have seen the trends and the benefits. And also we have seen the trend that is going to be done okay. The last few years. It's time to rethink about it and maybe change a little bit. An experiment new new ways to improve it probably probably it's going to be fine to try. From the vendor side, I guess, you know, I don't I don't know what that would look like. Someone like Intel. They're contributing directly to Kubernetes. Multis being a CNI and they're part of the network plumbing working group and their Kubernetes and they're part of other things directly in CNCS. They're also part of elephants so it seems like the company. Probably just all companies, but whether you're creating the product or consuming, you know, you got to decide where you benefiting thinking about the CSPs and why they would want to be a part of both. So they are domain specific when you think of them as a company like, okay, it makes sense that, you know, Linux foundation networking is helping to drive and listen. That's their domain or just telecom is under networking. It's within networking. There's a lot of different areas on networking. On the other hand, you have them using flux and psyllium and, you know, multis and of course Kubernetes so if they're not part of the Kubernetes community, then how are they going to have their feedback and their challenges directly heard. You could say that they haven't heard by say elephant and elephant is going to go listen and elephant is going to be part of the community, but now it's indirect. So the end user is not. Giving feedback directly to this project. So in my opinion, that doesn't make sense. And I know that at least some of them aren't going to separate. You know, douche douche telecom. They are, you know, using flux, they're going to stay part of the CNCF and Kubernetes community, but they're also doing stuff with, you know, there's projects within all of them. And I don't know how that should fit. I have suggested in the past that maybe Linux foundation should have some type of dual membership for groups that really want to be part of everything. You know, I don't know what that look like. Yeah, more than a single membership but less than having two memberships or whatever. As you add more it becomes cheaper. I don't know this is me on the outside just thinking but those that are trying to take on cloud native practices so if you look at say tell us they're running networking applications serverless on AWS lambda. They, that's not traditional telecom practices. They're not running some of the traditional applications for them to be able to do that in production right now. They should tell calm launched a production version of their Kubernetes on bare metal that's deployed from get ops a few weeks ago and that's in production running 5G, you know, traffic right now. That's also not traditional, and it seems like there should be direct feedback into the cloud native CNC F community for the projects that they're using directly in the Kubernetes. But they're also needing staff, I think, from projects like nephew which are going direct moving migrating into LFN from LF. I don't know who's using VPP based networking applications in production, but I know that there's vendors that are writing VPP so. And they're running among Kubernetes. So now we have, you know, definitely networking focus at FDA so elephant project that running in Kubernetes so they're there needs to be something. Victor there needs to be some type of something where we can have them collaborating and continuing to work together. And what I think that we cannot continue doing the same thing and expecting some results like. Yeah. That makes sense. I don't know what it that looks like though, so that you know if that potentially like the word, I think we're still we're still trying to figure this out and by the time we get to cube con cloud native day then some of it will be decided and some of it still be decisions because there is a workshop happening during cube con to continue these conversations but the test suite and the certification that are domain specific seems like it makes sense. It's really where did the different things go. And that's the question. Where should something like this working group go, which was trying to get best practice feedback. And maybe there needs to be a change. And, you know, what we're talking earlier and Nick, I was saying maybe under the app delivery or something like that maybe if there is a change Victor but it's within CNC F. And getting behind something specific would be good, or maybe it does need to make to the elephant. Okay, yeah. By the way, Nikolai, are you expecting to, are you coming to the Chicago, the cube con. Sorry, no, no. No this time. Okay. No shooting for parties. Okay, well. All right. Well, anything else. I'm still interested in writing at best practice stuff. And if nothing else will take content and try to put together some larger paper like this issues by adding the practices we have. I still think something like this would be useful wherever this group goes whatever the future. Victor we were talking about looking at best practices from FAM. Now that we're through the technical summit. If you have some thoughts or ideas on that. Let me know. Okay. Yeah. Do you have any best practice ideas somewhere where people aren't talking about them and we should try to push them forward. Nothing comes to mind in this point but I might think of is this the list of the categories. Yeah, just think of it as areas to inspire. Yeah, probably is going to need a another round of adjustments based on how people are currently talking about stuff. But observability and diagnostics of course these are big topics that at least I have kind of came across about I mean I don't I don't know what we have added here but I mean and it's. I don't think anything yet. There's no best practice proposed we might have like GitHub issues about observability or there's definitely discussions but there is no published best practice. So if there's like a specific challenge to put forward. So here we need to have. I guess specific maybe to the telecom network and domain. Here's here was one that somebody put forward I guess the observability. And then I wrote it down and put push the issue. But if something you're thinking of. You might want to mean you, you have at least two kinds of viewpoints one is for the process or you know the application itself and the other one is the outside like the communication and focus are at least legally required to be able to observe, you know, and to monitor the external traffic so that's one thing that's kind of, you know, to do so essentially the infrastructure. That's there should should be able to to provide these capabilities and what this is kind of best practice but kind of have to provide it in any case. That sounds like something we should have put in to this practice, we, we did talk about observability for how this practice. If you have everything like as a monolith, then you aren't going to be able to see what's going on between the services that are talking is related. To what you're talking about. So I don't know if, if you're talking more of like a non functional observability requirements and then we'd need to break down what are functional requirements to meet that, but think about it and then maybe come back and write that up. And Victor, if you come up with something that you think is relevant for the nephew, KPD configuration stuff or get ops or whatever, or could be the operator stuff you're talking about. All right. Thanks everyone. Have a good day and a good week. Thank you. Thank you.