 Hey, how's it going? Hi, Bill. Happy Monday. Do you want to make your trip back to the US and back again now? I'm actually going in about like just over a month. So I'm very excited to be going home for the first time in like a year and a half. Yeah, I can imagine. Can imagine. Yeah, cool. It's a good time of the year too. Yeah, definitely. It's vaccine season. Yeah, that too. I was thinking mainly weather, but you're right. Yeah, it's it's also good weather too. So I'm very excited. Thanks, everybody, for joining today. We'll get started a little bit after the hour to allow people time to join. You want to put your name in the meeting notes that'd be great. And then we can get started in a little bit. So thanks. Howdy all. Hey, Taylor, how was spring break? Oh, it was pretty good. A lot of doing nothing, which was nice. I mean, it's been spring cleaning, but mainly just enjoying the sun and relaxing. It's kiddos are away for the week. So that meant I did nothing. Freedom. I will give until I'm five after I all will give until five after the meeting notes are in the Zoom chat. I'll repost for those who just joined. Oh, that's my name. That's not that's track and paste there we go. And you can add your name and. Whatever it's in the items, I will get started in about one minute. OK, it's five after. Thanks, everyone, for joining it today. In case you got lost on the way here, this is the weekly meeting of the CNF working group and in case you don't have the meeting notes already, I'm going to put it in the chat so that you can have it. Before we jump in, is there anything anyone would like to add to the agenda? Hearing nothing, we can probably jump in then. So the first thing is the use case template that a book put together in case people were on the call last week. We said we were ready to merge this one once. Book had taken out his use case so that we could have them in two separate PRs and he did that. So thank you for doing that earlier. Unless anybody has any last second comments, like very, very last seconds, we're going to merge this pull request. OK. Cool. So I know I saw that book was on the call. So thank you for creating the use case template. And so for people that are new or don't remember what this is, this is a template for people that want to submit use cases. And these are going to be the backing of all of our best practices in the CNF working group. So every single best practice needs to have an actual real world use case behind it. So thank you for putting this together. The second question I had for a book is I know you already written up a use case. Did you want to? Did you have a pull and then you pulled it out? Are you going to make that as a separate pull request now? Yeah, actually, I was looking to to close this merge request and remove the branch and I'll create a new branch and put that another use case, actually. Example is as a new pull request. OK, so I didn't create it maybe in a course of the call, I could just push it. And I can present what it is, but I didn't prepare. OK, yeah, no worries. Maybe if you can do that in the background, we can circle back at the end of the call. Good. Cool. Thank you. Um, so then the second one is what we talked about last week about the elections, about how it'd be helpful to have some type of deadline for legal in terms of getting stuff in. And essentially, this is a one line change about interested parties. So interested parties can be added at any time, but must be added at least one week before any elections to have a vote. Uh, I said right now. Taylor, I saw, oh, was it 14 minutes ago? So I haven't read this yet. This is just new because I'm trying to catch up this week. So OK, and I was reading a lot of the slack messages and it seemed like there was still a discussion around what individuals versus parties and how that affected voting and all the other things. And it seems like we may have other areas that aren't that may not be counted. Anyways, I'm mainly wanting to make sure we're clear if this section is really going to be. You have to be listed or you get no vote. Then that I think is really important for everyone to have. Yeah, I guess the initial. Thought, well, this is just right, a vote for the co-chairs and the tech leads. And why I guess maybe to get the contacts about this was the problem that some people running into is in like larger companies, they're like, OK, why do we need to add like when's the deadline for like doing this? You know, if there isn't any deadline, then it's not going to get done. And so it'd be easier if there is. You need to be in by this time, otherwise. You don't get a vote, I guess. So we're not trying to discourage people from adding themselves in as an interested party. So that's why they said they could be added at any time. They just we kind of need to put a deadline for that. I know that we need to have some way of knowing who's eligible to vote. And that makes sense. I am just not clear on that for this being the way to do it. Interested party and the other. I may have misread or misunderstood other CMCF and Kubernetes groups that have the interested party section. But I wasn't attaching that to voting eligibility. So that's how we have it written right now. I mean, that could certainly change in the future if you want to change how we do our elections. But if we look at the actual charter right now. Is somewhere in here. Each organization interested in the interested party section has one vote. So right now we're basing the voting off the interested party section. That could certainly change in the future. But that's how it is right now. Right. That makes a lot more sense. So does that answer your question here? It makes sense why it's listed there. Yeah, I guess I'm concerned that about and making sure that we're including everybody. Yeah, right now when we first created that section. The I think the main purpose was around communicating the interest from organizations in the industry. So anyone, you know, other companies coming in that go, oh, I see that they're involved and what is this about? And they get involved or CMCF orgs or, you know, other projects. They go, oh, all these groups are interested. Let's see what's going on and maybe get in. That was where I was seeing the main focus of that section. Separate from the voting. OK, yeah, look at some of the stuff like the Kubernetes steering committee and other. Here's the community voting. There's some of them that have. Their own. Like there's a whole section. But what I hear you saying is that you want a separation between participating companies that get to vote and interested parties that just want to come in and look. Is that what you're getting? I don't know that that's required, but that was where my brain what happened and if. That's what I hear you say. But that is what not that that's not how the charter is written. Right. I agree with you. So that I guess some of the comments in the slack that the slack channel for the scene of working group. Are about individuals and groups and how do we deal with all these things? And mainly, I want to make sure that everybody that's. And involved in trying to contribute. We'll have a vote. So yes, to tie it in with the company stuff that we already have. If you're part of the same company, we already deal with that in the charter. But if your company name is not listed. And somewhere or you you're not involved with a company directly. And it's you're an individual. It seems we need to make sure that people are there. So if it's part of the party's fine, let's just make sure everybody's listed. I believe we have a potentially a subset of voters right now. This is my main concern. OK, yeah, I tried to kind of follow up with everybody last week that it's been on the call to add them as an interesting party. But if other people would like to add themselves, we're not trying to discourage participation. Yes, also kind of related to this discussion is this issue that was brought up last week of what does it actually mean to be an interested party? Because right now it gives you voting rights. But do you have any like obligations was kind of the question is some people are struggling to get it through their legal department? Is there anything you have to worry about if you have your name listed there? And similarly, is it going to change over the course of time? Because if your obligations change, you might reconsider your participation. And these documents are all effectively changeable. Yeah. And so I think, yeah, kind of all of this is how we we have like the first step of governance, but how do we get to like step two? I guess the question kind of once we get like off the ground, I'm certainly happy to like help with that, too. I think kind of once we get this through this election cycle, I think the co-chairs will be in a good position to help hopefully like lead the community to the next level of governance, I think. I think there's a lot of great content in the cloud-native community already, stuff like this. Maybe I'll add these to like the issues right now and also coming out of say, contributor strategy. But we can look at Bill, the voters. Markdown that you have is related to the steering committee, just to make that clear. So that elections, MD is the process and the 2020 voters Markdown actually is the list of eligible voters. So that I guess one of the things to point out in the. What was eligible voters for the Kubernetes steering committee? Yeah, a combination of things. So in my mind, this would maybe be similar to what we would could do. Potentially, this is more complex than just doing interested parties this year. That's fine. But the idea would be you could have interested parties combined with contributors that have been making pull requests. They're not listed as interested parties, but we want to accept them, too. Mm hmm. Right, so that you can go through all this. But on that voters, indeed, it kind of says what it is. So you have this list of people that were doing contributions that are shown with DevStats. So that's the CNCF project that actually looks at contributions with commits and then a list of other eligible voters that were added for other reasons that met other criteria. I'm just wanting to make sure that everybody has a voice on this that should. So if everyone wants to make it keep it simple and as an agreement that every everyone needs to be added to the interest of parties, then we can go that path. Yes, is there anybody on the call that feels like they aren't represented right now in the interest parties and would like to have a vote in the election? And here's here's who it is. This the only person I don't have a contact for is someone at Chung Hwa Telecom. And so Aiden has been on the call before, but didn't have any contact info. So I don't have any contact info for someone there. And is there anybody else on the call that I'd like to vote? It's not on this list right now, because the ballots will be going out later today. What about CNCF, CNCF? Anybody there get a vote? How does that CNCF is staying out of it? OK, we're a neutral third party. But we've seen I saw that you wanted to add full. Is Google listed? I see that there is. I think Mexico and myself, I met off. I think we are joining this meeting for the first time from Google. So happy to be added that we're just observing. So I can add those three people right now to. You see the comment for in for cloud? Yeah, OK. At one point, I'd like to have these in alphabetical order. But yeah, that's. And then. I'm also going to. This is terrible. Is there? OK. And also AT&T. Bill, I noticed that you have an alphabetical order. So do you want to order? Because I guess some of them are. Yeah, it's it's out of alphabetical order. That's correct. It's maybe if somebody can do that in the background. Well, I'm like, OK. And once I then I can merge that at the end of this meeting. Is there anyone else on the call that would like to be added? So in case you missed it, we added a vote co-op in for cloud Google and AT&T. And in case you weren't aware, this is now the interested parties list. Can I suggest something since the charter is going to be static while the interested parties will change? You may want to keep this as a separate addendum. Yeah, which is easily changeable. Yeah, I think that's probably a good idea. But I think now that we're getting more formal, we should be. We're growing and we need to like kind of restructure how we're doing things. We can do that. And maybe also the alphabetical reordering in a later pull request. We don't have to do it in the middle of the meeting, though. So yeah, that's fine. Yeah. OK, so I'll add in about that. And either we can make an issue or somebody can make a PR about that. And then Jeffrey, I saw that you made the pull request about creating the glossary and then is he on the call today? I am. Yeah, I saw that you added a bunch of definitions and then took a whole bunch out. Yep. Yeah. Which I guess would you do you my thoughts on this? Yeah, like if you just go into the main doc, you'll see like it's just a few things, TVD, based on what we know we need. Things that are going to be contentious, which is probably going to be most things, just based on like the last two years of what I've seen. I would I would do definitions for things that are new, nebulous or people assume are preexisting as either issues or discussions and then create individual PRs for those definitions. Else we will have an empty glossary, I think, for like the next eight months. So yeah, the only one I left in there is the Kubernetes one. I mean, if people really want to argue with the people who, you know, host kubernetes.io, I guess we can have that discussion, but I figured that would be the one least controversial one. Yeah, I stripped everything out so we can get the template in. People can start starting discussions, start making pull requests. So my PR ended up becoming pretty lackluster, all things considered. But we could at least get it in place and then start working from there is kind of my thought. I also in the notes I linked. So me with my clairvoyance, I started a discussion right at the beginning of this group saying if we don't define this, we're going to fight about it later. And here we are. So there's already some thoughts in there for people to continue to rehash at least what a CNF is. And then, you know, we can move on to things like cube natives, et cetera. OK. Yeah, I mean, I think it's. Yeah, like a good place to start. So I'm happy to approve it. I guess maybe if we can either get a couple more approvals now or like just merge it next week, I don't think I don't think now it'll be very contentious maybe before. Yeah, structure sounds good. And ideally, we can focus on stuff like the more specific things where we can agree on and get those in place where there may be different terms that have been using across like I think one of the items was use cases that were using different terms, but they actually meant the same thing. They were just different terms. So dealing with those early on with new with new PRs would be good. Yeah, I guess maybe in the interest of. Kind of getting this off the ground so we can kind of start those discussions. Is does anybody have any major concerns about merging this as it is like? I don't think there's anything super controversial in here. It's just essentially Kubernetes being defined. Well, the only the only comment that I made was about the the tech, which is after the Q-net definition. Oh, I did it in the Slack channels. Oh, yeah. I'll be honest. I was too lazy to look up how to do superscripts or subscripts in markdown. I just hadn't got to it yet. So I don't know if there is a way to do that. But we just we can remove the kubernetes.io and just put some type of indicator that, you know, obviously makes a connection down to that reference down there. No, no, be in the definition. After the definition is like, yeah, the last class part. Yeah, yeah, at the very in there, the kubernetes.io and the I just put it in as a temporary placeholder to like kind of tag it. But there should be like something to where like if we're pulling a what have you directly out of something, a more, you know, proper citation methodology. I just did that quick, keep it as a placeholder. OK, I guess do you want to link to there? Like, well, if you in down in the references, there is I don't think we need to do it because the link is down in the references. We just need like I didn't want to do the numbering thing yet because these are going to change a bunch and I didn't want to have to constantly update like the numbering are based on like reference stuff. But like in reality, you could like drop like a number or three there because I think it's that third reference. I just some way for us to show because I think we should do small citations and the definitions and then build out the references at the bottom. That way people can go like, yeah, down there, they can go and see where we're pulling stuff from, especially if we're, you know, co-opting an existing definition. OK, about changing it to be like a asterisk or something like that or see references. Yeah, I mean, maybe the easiest way is like to say to start numbering them and then every like it doesn't matter where things are placed. Right, as long as you link, it doesn't matter where it is. And it's reference one or it's reference 100 as long as the link works. But yeah, I guess does anybody have a strong preference on how we link them? I'm good with not having to decide now if nobody does. I just changed mine to approve. Yeah, I agree with the same. And if someone wants to come back through and go, oh, here's how to do it. Mark Dunn, like you're saying I don't he didn't know how to do superscript or whatever. And then if someone wants to put something in, they can link it. I guess this is what Ian is always pushing us to do is merge fast and then come back and change it. It's easier said than done. But yeah, I mean, yeah. I guess does anybody have a problem with like merging the like the glossary as it is? Go for it. OK. So. Thanks, Jeffrey, for putting that together. And I look forward to the discussions to come out of this. Cool. Yeah, the next one is the issue that created. I don't know, like any of you thought about. This at all since last meeting. Now, I've been terrible this week. I will throw it into I'll put that as a section in the charter and put the request together. But not the only pull request I've got on my job list. But yes, indeed. OK. Based on comments so far, I'll take out the commentary and basically leave it in pretty much as is. I don't think there's any need to change the wording. Everybody seemed to be was objecting. Cool. I guess the only thing we really have left is the elections. But before we jump into that, I guess, look, have you had a chance to make your pull request? Yeah, actually, you can find it there. You use case. OK. Cool. Do you want to just maybe show it with the no, no, three dots? Click three dots on the on the right. Yeah, and then view file. I think that's the best way to run it. Yeah, I don't expect this to be merged now, but would use the chance to explain a little bit what I had in mind behind. So that's essentially use case, which I am in my function very much close to and I'm seeing every day of frictions coming out of that in a real production and real deployment environment, which is essentially how do you, you know, what's the relation between a cloud native net for function and underlying infrastructure and the expectation of that is normally that cloud native net for function can tolerate a lot and would not be dependent on many things. And this is actually what I try to describe. So in terms of involved processes, we have operations and life cycle management. But indirectly, it is going to give a feedback to the development and the deployment. I just wanted to elaborate the use case in its core and not to touch everything. So essentially here, we have two roles and then personas involved the CNF DevOps team at the CSP or operator side and the cloud native platform. I know that it is going to create some discussion, intentionally use it here and we can maybe throw it for the definitions to the to the Jeffries document. But I said intentionally cloud native platform DevOps. So this is a team that manages the DevOps and then operates the infrastructure for that for the involvement system entities. We have a platform, meaning infrastructure. We have a CNF. We have a CI CD and monitoring and essentially the thing is that there are certain patterns which I describe here. I would call everybody to take some time to read it, but briefly summarized. There are some patterns when you have an infrastructure that is built for a cloud native applications and cloud native workloads, it assumes or it behaves in a certain way. It's according to the best practices, immutable declarative. It's not highly available, doesn't pretend to be, but offers all the mechanisms for high availability to be realized on application side. And then when you have such infrastructure, there are certain life cycle events that are happening that are assuming that application can without degraded performance or degraded function, handle those. And this is what would we expect that behavior if you scroll down a bit. So the expected behavior would be that the CNF can cope well with all situations that are happening in the infrastructure, especially on the node level. So one of the main highlights here, main topic here is when one or more nodes in the Kubernetes clusters are away and going away and then being drained and then reshuffled left and right. CNF shall be capable to bear it without visible impact on that. And another thing is the CNF should be able to say if after change in infrastructure, it is still feeling okay or not and not to wait like whatever certification and stuff to happen. So this is currently what would be expected behavior. What challenge is, is that it's not like that in practice. So we have in the many instances and examples, we notice that the CNFs are actually VNFs, which are just packaging containers, maybe reworked a little bit, maybe have dependencies on the hardware, on the particular nodes and so on. And this is not what I would consider being cloud native, at least in respect to the relation of application to infrastructure. And the CNFs are also still following to the large extent this systems integrated approach, which doesn't leave you the chance when you change the infrastructure on a weekly or bi-weekly or monthly level, doesn't give you a chance to still be sure. You need to wait the certification cycles and so on. So that's a situation. Practices I didn't deal with and I just put here because we now need to probably use that as inspiration to discuss about some best practices and we can refer them here where that's not available is. I just highlighted in this last part of the template what should be done differently to overcome these challenges. So I think it would be fair to say that it's something that would require people to read through and then to comment. So I don't know how much of the discussion we can have now because it's very fresh. For the one one question from for the overall approach. So what is the like the relies on some kind of an observation technology. Which is not available. So do you have an opinion that what should happen then? I lost you, Gargely, for a couple of seconds. Can you repeat just bring it to context? So what should happen if there is an accelerator hardware accelerator, which is not present in the infrastructure? So how the application should behave? So should it run with degraded performance or should it just like stop trying? So what should be the approach here? Because like the big question here is that like does it worth the effort to even run the application without the accelerators? I mean, like what's the purpose of, I don't know. We see if it can handle two cells. I mean, this is now you are going into into a particular example behind this use case, maybe, or that's related to use case with a specific set of assumptions. I think that things like that could be discussed or should be discussed actually if it's a valid input or valid concern from your side. We should think of how do we handle those in terms of like, do we discuss that in a PR or do we have some breakout sessions or something? Because there are a couple of ideas that come to my mind where your question is coming from. And for example, on that particular case, we see a lot of today's CNFs are simply using and it might have this issue with accelerators being present or not present because they rely on DPDK and SRIOV, which is a typically the virtualization technology that got ported and transported into the cloud native world. But if you look like what are the potential alternatives, what are more cloud native alternatives, we might come to XDP, to EBPF, to all the stuff. But this is already going into best practices, which is not the purpose of use case. Use case should trigger the discussion. Let me just ask a couple of questions which might help here a bit. One is, if we imagine, for instance, an IP second point, it could consume an accelerator if it exists, but if it doesn't exist, it could work without as well. So that would be if you like two flavors of that IP second point, and there'll be more flavors. There'll be ones that run higher capacities or lower capacities. You might deploy in different ways depending. So it would be possible to say, well, a solution that lets you run with or without an accelerator if an accelerator exists is more flexible to us than one that exclusively requires you can only run with an accelerator and you effectively produce another accelerator, another CNF for the without use case. So that's one thing. But then the other thing, and I haven't read this yet and I need to read it, is the important thing about use cases is they don't dictate what it is we do and don't do. They let us score what we should and shouldn't be doing. So when we come to define best practices, we can judge them by the use case saying this serves this use case well. So if we can come up with options that let us do the more flexible rather than the less flexible and they don't have significant disadvantages, then that might make them a best practice in the sense that it's better than the other practices that we can think of. So the important thing about use cases is they let us choose best practices on whether they are, in fact, better or not. That's completely right. And if Bill, you scroll a little bit down, not up, down, yeah, these challenges. So essentially the best practices on the, still a bit up on the next chapter that's not visible, yeah. So I think the use cases as I was actually working on it, it's a subject of change, but it is a situation that is described and that we are facing. And then the challenges and limitations when we run the CNFs in Kubernetes and I know Kubernetes we need to discuss still, but in general, the challenges should present the problem for best practices to solve. And then we might go and say, okay, how do we address this challenge number one and challenge number one of use case number seven? Is there a best practice we can elaborate on that? Is that really best practice or can we have a consensus and so on? So they should indeed as Jan pointed out, stimulate our discussions. And I think I could say that there is no, even reference to any accelerator in this one. Maybe there is if I- No, there's not. I think that there should be no, but what it refers to is essentially, what it refers to essentially is, even if you have a cluster where you have accelerators on each node, there are some network functions that would do a node pinning and stick to one node for them to function properly. And what we are seeing here when node is not a unit of availability, when node could be like rebooted and removed out of the cluster every like a couple of days, how is application making sure which can or doesn't need to use accelerators how that application can manage that this IP sec, for example, microservice is let's say horizontally scaled and that can take over the existing sessions that we're running via one pod by another pod, which is still healthy. How this migration could happen without any need for orchestration from top or dependency that is blocking infrastructure, lifecycle upgrades. That's correct. If you look at the lifecycle. Ah, please continue. Yeah, sorry, one paragraph up, you do say that application should continue functioning without degradation of performance. So we need to be very careful in the use case. If that's the requirement, then it rules out a lot of best practices. So it's important that we agree here on how strict we want the use cases to be. I think it says here, CNF shall be capable to bear without visible impact on its function or performance, the situation. Yeah. There are some assumptions. If we are that strict here, then it really limits the type of best practices. If we get that flexibility here, then it opens up for more best practices. Yeah, I was going to bring up a similar thing as well. And this depends on how we define the CNF. So in order to avoid the definition problem, I'm going to talk about a specific pack of treatment or a specific endpoint that is handling a stream of data for this particular example. So when you have in Kubernetes, the way you get a device is through device plugin. Device plugin has a couple very simple APIs, which include the ability to assign or provision a device to a workload. And in the process of doing so, it resets the device and then hands it to that particular pod as a thing. And one of the problems that we'll run into is that there's no way to tell it, please don't reset this device before I hand it off. There's also issues around device plugin in terms of there's no easy way to say that something is a class of a thing. Like maybe you have a bunch of 100 megabit NICs and then you have a certain set that are one gig NICs, they all connect to the same network. You want to consume the 100s, but fail over to the one gigs, which are more expensive. If you run out of 100s, like there's no easy way to perform these type of tasks within the device plugin framework. And this is before you also consider the relationship or the lack of relationship between device plugin and the CNI. So we want to be careful that we don't conflate the overall performance of the system with any given endpoint that we separate these two things out into two separate use cases. Like I might say I have a Kubernetes cluster that's acting as a firewall and all my firewall functions are distributed. So I may lose a pod and maybe I have some slight interruption of service for a subset of my systems while they reconnect. But in the process, I still have my uptime. I still have my availability for most of my applications going through. And what we want to do is try to is first separate these things out and then simultaneously provide information about best practices. Like if you want to achieve the capability to resume the sessions. If you want to achieve these type of things then we can dive into how do we achieve that? What do you have to pay in order to achieve those particular goals and are they even reasonable goals to begin with in this particular environment? Maybe at this particular point with the current Kubernetes infrastructure it may not be reasonable to hit all of these goals but with changes per maybe in or out of Kubernetes with things that are associated with it maybe you can achieve these things depending on future advancements. One other thing I'm glad that look put in here that there should be performance limitations or considerations like here's the thing if you hand me something that doesn't run very well I'm not going to deploy it in my infrastructure. This is one of the reasons why I think we try to set up the whole three different like domains within the chairs. This and that is there's going to be a lot of conflicting opinions. There's going to be a lot of divergent requirements and I know we've gotten a little bit softer on the whole whether we're grading things or this and that but at the end of the day this should be the whole entire point of best practices. If I say that performance has to meet what look put in expected behavior then the question is is it a feasible requirement? What are the trade offs? Like can I use things like node labels, device plugins, et cetera? What are the expectations from the infrastructure? But if we have something that like doesn't have any hard stances anywhere then what are we really measuring the best practices against? I feel like the use cases should drive the requirements. Yep. This is a good situation where we would need a concrete example because this is now very high level and then we are all talking from certain assumptions that we have and maybe we have even picture when Jeffrey or Jan are talking maybe they have even picture of concrete network function, concrete situation they faced and that they see difficulties and then so on. So this is where the discussion in my view could get very tangible, very specific and this is why we need also those examples in. I have those examples as well but I'm not kind of the owner of those in order to bring them like specific vendor X, Y, Z and talk about them here. This is what should come from the vendors for and there are different applications or sorry, there are different assumptions. For example, when I say we need to unpack it when I say without degradation of performance I have something specific in mind and I didn't detail that in but I'm saying if you have a cluster that's comfortable enough that is planned properly that has maybe I don't know 10 nodes or enough nodes you should be able to reschedule and you have a possibility to reschedule your pods on another node. So it's not blocked. It's not like a very limited so that you get the degradation. So under this assumption I expect that the function would not be great but of course if you lose half of the cluster and you have to serve, I don't know thousands or hundreds of thousands sessions with the less capacity then of course that's a normal case for degradation. Yeah, better than loss of function in the native way. Yeah, that one's better phrased as building up from the bottom, right? We're trying to express the requirements we have on the platform rather than the platform design in this, you know, best practices ideally on a CNF at the moment at least we're not really talking about best practices of the platform but what we are gonna have to say is something like we expect the platform to tolerate a single point failure. Single point failures will have this kind of consequence like lost nodes and we expect to put the CNF in a position that it can recover based on that and exposed functionality of the platform. Now, Jeff has gone into design considerations in for instance, I might use node labels as some part of doing that and you would have to argue why node labels are sensible and also who's setting them because it's not obvious to me in fact, I don't think it's logical that a CNF developer gets to set node labels I don't think it's logical in an ideal world that the CNF developer knows how many servers are involved. So if it comes down to setting node labels then obviously that's the operator of the platform that's setting no labels and you would have to determine whether node labels is what they wanna do because presumably they're identifying specific places to run CNF pieces and also why they're doing it and how they might make choices and this sort of thing. So you've opened account of- To be fair though, Ian, on this exact point, this was what I was saying like we have like the different I forget what you call them, well, we call them actors, right? And we don't agree with those are yet either but this is the whole thing, right? is Volk and I as providers and I'm gonna tear into this book here because this one is near and dear to my heart but like there should be like the total expectation that the CNF developer side would come with their own requirements driving use cases, right? And then like I said, so for one, something like node labels has no business going into this type of document in my opinion. Like it should be like node labels is a best practice because of blah, blah, blah based on meeting these use cases, right? And so, but then that's what I'm hoping this group will figure out is CNF developer says, well, you know, I need deployments or I need Damon's steps instead. And if I do node labels, how do I manage all that metadata? Like these are the type of discussions I would hope would come out of this is we have multiple points of view represented in these use cases driven by what the different requirements are for the different actors. And then we can actually sit down because there's gonna be trade-offs. There's no getting around that. There's always bottlenecks, right? So what are they and what does this group collectively? You know, what grudging agreement do the provider platform side come to with the, you know, the CNF developer side and you know, how do we get to some uncomfortable compromise in the middle? Totally agreed. I mean, the point is to work out something where a CNF developer can get their job done and a CNF operator can actually make use of the results. So that's completely, you're not wrong in this and this is where those things should come together and then the implementation should drop out the bottom of it. This is one of the reasons why I've chosen to put this kind of use case first because it's one that is connecting a lot of players and PCs because CNF developers are developing the CNFs in order for them to be deployed. And if it cannot be deployed or if it cannot run in the environment where it is operated or it doesn't present the options to make it run, then it's a work wasted. And this is maybe something we need to keep in mind that everything cannot run in isolation but simply say that you will not always be able to make choices on a vertical integration of the thing and system integration especially if we talk about cloud. This is very much different than in a, let's say classical setup where we got this proprietary network functions and hardware and then also in the VNF was very much prescriptive by the CNF and in the cloud native world you don't have a control over the platform so you cannot specify it. You can just say what capabilities you need and when the application will run properly. Yeah, that's for the dedicated time I guess. Yeah, clearly this is a very inspired discussion today and I think it's gonna lead to some good discussions down the road and I'm looking forward to those. We do have three minutes left so I do want to kind of circle back and make sure we kind of have everything covered. In case people missed it, Shane put himself up for the service provider chair and also like I said before, I'm missing a contact for Chungwei Telecom. The other thing that we discussed last week is there's the current nominations for the tech lead. It closes tonight at midnight if you're interested. These are the people that currently nominate themselves and one suggestion last week is people that don't win the co-chair election could also be rolled over to the tech lead nomination. So I guess if people are interested in that, we could also do that too. I would rather we did that. I want to understand whether a chair would be effectively have all the responsibilities of a tech lead plus the chairman responsibilities as well. Suzanne, can you be elected for both? Or are you asking me or indeed do you need to be? If you're elected as chair, does it do you need to stand for tech lead at all? Yeah, I don't think if you're elected as chair, you need to stand for tech lead. Right, so then if we said that those standing for chair are also in the tech lead election and anyone who wins the chair election won't get the tech lead title when we're basically good, I think, aren't we? We're not limiting the number of tech leads. So I mean, it's basically, at least I assume we're not limiting the number of tech leads. So as things stand, it's basically majority, well, 60% as things are documented. Yeah, the number of tech leads is currently not limited. You just have to be elected by a majority of the voters. So it's however many people the community think should be tech leads. Yeah. So I'm just thinking- I think there's some clarity around on the chairs who would be a chair like who you're representing and where you're coming from. So the SP chair, I guess a little bit of the confusion maybe. And I've heard comments, so I'm trying to bring this over the last month at least. Shane, you're with Red Hat. And then so that would seem more like not a service provider unless you're thinking OpenShift. Maybe that's, well, that would still be a platform, not a service provider. But what is, has there been discussion last week or any clarity around who would be a chair? Go ahead. Well, we've never put in the charter that there's any eligibility requirements on that. So, you know, how would you say that you respect, you respect- Do you have to be a member of the Kubernetes community? And what would that mean to represent the Kubernetes community as an example? Do you have to be a member of a company developing CNFs in order to represent CNF developers? I think my take would be anyone can stand if they feel they can argue that they're going to do a good job of representing that community. So if Shane wants to say, I can represent the service provider community and he can persuade everybody that's more true than, you know, everybody else standing, then good on him, honestly. Yeah, exactly. So in case people missed it on the mailing list, Shane is nominating himself for the service provider co-chair based on his in-depth experience with network virtualization at Verizon. I think he was there for some of routine 10 and 20 years. So that's the clarification on the mailing list from him. Right. I don't think he's even been a year at Red Hat. Just trying to bring clarity to it. So I think I understand and maybe agree and like what you said, Ann. If you're interested, then you could put your name up. So I suppose this means if you have no experience in any of this, you still put your name up and then people can decide if they want you to represent. Yeah, and I'll just make a call to the voters to make sure that they're choosing, bearing in mind that they're speaking, we all get to vote for all the chairs as things stand, I believe. So bear in mind, we're looking for someone who will best represent that community. Okay. Yeah, and the ballot should be coming out later today. And if you think you should be getting one but you haven't yet, please contact me. So that's all I have for today. Thanks everyone for joining. Sorry, we're three minutes over but thanks for staying with us if you did. And yeah, I look forward to seeing the results from the election. I hope. Thanks, bye. Thanks everybody, bye. Thanks, bye.