 Okay, I think we can probably get started now. So thanks everybody for joining. This is the CNF working group. We meet every Monday at 1600 UTC. Talk about cloud native network functions. Before we dive into the agenda today, is there anything that anyone would like to add? Okay, hearing nothing, I think we can probably jump right in. So the first thing on the agenda today is the use case template that we'll put together. So I saw them on the call earlier. And I know there's still quite a few comments around this, but does anybody want to kind of talk through this? Or does anybody have comments or is there anything you'd like to say? Hope you can hear me. So maybe just as a way of intro for the people who didn't get active in the pull request, the template for the use case was supposed to be informative about the use case, practical use case that should serve as a basis for extracting or recognizing or discussing some best practices that we wanna finally end up with. And I try to put actually the template together in a way to serve this purpose of informing who are the actors or personas or roles in this use case. What do they want to achieve agnostic of technology? How would they expect the system to function? And then ultimately, what do they see as a challenger as a limit or as a suboptimal behavior of the cube native approach and to describe that. So this was a logic behind the template. Happy to tackle specific points if needed. Yeah, so actually have one question. So I see here that you put it in the like the CCDP folder. Now it's actually wondering if it would be better to put it in the use case folder. If we wanna say that's where like the templates are. So rather than, I think you put it under this one. I guess, I see where you did that because it's like the other templates in here. You're right, it was my omission actually. I overlooked when was creating a pull request. So I think I made another commit in a fork. I'm not sure I need to create additional merge request for that to end up in the main repo. So we could do it either by me correcting that and pushing another, creating another pull request or approving that and then I make a correction with additional pull request there. You don't wanna update the current one? I can update the current one as well. Thanks. I need to look that because I couldn't update anymore the branch because the merge request is active. So I would need to probably restart it. That's strange. You're saying you can't commit to your own, the use case template branch? Correct, but I'll look at that and we'll correct it. We'll reach out to you if I have some blocking points. You should be able to modify on your own side in your own and you may need to do a merge because I see that your branches, it might be behind master. Is it possible for me to just change it? Do you know? Not in the user, in the GitHub interface. You'll need to clone it and to do it. Okay. Then you would have to request a merge back to his and then a merge back to the other which is possible. I've done it, but it's... Yeah, good. I don't think the purpose is to get lost in the Git usage. Okay, yeah. The other thing I wanted to chat about just to hear like other people's opinions. So just because this also goes into like an issue that we have open right now, it's like this involved party section and there's kind of like a discussion whether this should be defined in this section or should it reference out to like a separate documentation? Yeah. And so the related issue in case people are interesting is issue number 54 of creating similar to how we have like a use case section and like a proposal section also creating like an actor section. And correct me if I'm wrong, but you said like people should go in here and define that like in the use case whereas some other people are asking like for it to be defined in a separate document. So I was really thinking about what would be the most or easiest and the most meaningful way for people who are writing the use cases to do that. So if we define it in a sense of foreign key and say here are the, you know, you need to hear in this template pick one or more of the roles that are defined in another document might be for some people who are writing that additional burden to look and say, okay, which persona, which actor is there. And if there is no actor that he wanted to do it, he will need to ask to extend that other document. So I settled down on leaving it a bit more freestyle because it's the information that we will extract later on in the best practices and we'll map it to real personas or actors there. But I'm also not very much fixed into whether it's like this or open. So the idea is for the chapter describing the parties. I think I wrongly used the word party. Didn't mean parties, but the different hats that people have or different personas to actually summarize who are the human participants in this use case and then what do they want? What are their needs? And then in the next stage which system components are involved in that use case and then how do they behave? So I felt it's maybe better to give it to the writer of the use case to describe and to think about with some examples but open for discussion. This is Watson, I'm seeing, it seems like people are using the phrase use case and user story almost interchangeably. And I'm wondering, and I've seen in here that we're saying that we're gonna have a requirement for use case, not a requirement for user story and it's wondering what people are thinking about that. Just as an aside, the user story has a lower barrier to entry in the use case. Like if we're gonna say people, if they're gonna submit a principle they need to point to something, the use case has a higher threshold. But yeah, I don't know if anyone else has seen that. Yeah, I was actually gonna bring that up later because we do kind of have like another issue open where we talked about like creating user stories and obviously this pull across is around the use case because that's how we usually define the issue. And I guess maybe that's an open discussion like would we prefer to have user stories or use cases? And yeah. Wait, can we end up with both? Those are two different things. Yeah, exactly. And it's not that they're equivalent in terms of should we use one or the other for this thing, it depends on which thing you're trying to do. Yeah, and it's important here because we're starting to say one of something's required. We're saying that use cases required, their use cases have more information in them than user stories normally. So if we're gonna go by like Ivor Jacobson's definition of use case. So yeah, we're making things on this, right? A use case is broader, but also more theoretical. How I reasoned about the use case, it is something that's very practical and that's kind of mind to mind that the best practice is out of it to trigger the discussion. So real life stories from different angles who are saying, hey, here is my situation. This is how I think it should work and then this should enable me if I move to the cloud native world and then cloud native network function. This is what I will face with or that I'm already facing with and what's the best practice or what's the user story? I would say that the use case could contain many user stories, but if you compare it to the movie, so use case is entire movie and user story is a scene in that movie. I think that's, I'm not sure that's true. If you look at the use case that I put in the other day, the other week, it's specifically use case because it says I need a tool to do a job. A user story would theoretically describe the job, but the problem with user stories is you don't really want somebody to be describing their situation as regards how they're gonna make money out of their customers, it gets complicated. So that BGP use case actually works quite well as a use case. I want BGP and it's reasonably self-evident why you might want BGP. A user story and there's one I've got in motion that I'm trying to, well, actually make look like a user story because it's got altogether too much in the way of opinion in it at the moment would basically say in this instance, it's gonna say, I want to install a CNF on my network. What's it gonna, what are people going to want to do in the process of doing that? And it involves dancing around developing teams who are gonna make the CNF and then hand it to ops teams that are gonna deploy the CNF because potentially with some hedges around it saying potentially those two teams are in or not in the same organization. So a user story is really about describing people's actions and the results they intend to achieve by those actions. But a use case here, as I used it before is really saying, here's a description of a tool that we want to be able to run. We're talking around the questions. So I think one of the questions was do we want to require one and which is it or both? We could say this is requirements and specifically for best practices. So when you're proposing a best practice, what is required? They are two different things. I don't think there's any disagreement on that. And then which if any of them are required? I would say either or both will serve because what you're looking for is justification that there is a problem to solve and being a best practice, this phone fundamentally has to solve a problem. So your suggestion, Anna's, you must have one or the other. Or a list, I mean, any of those, yes. Okay. So maybe I'll add that as a suggestion here. And if I look at the user stories, let's say my daily job, it's usually something very specific. As a network admin, I need whatever functionality X in order to do thing Y. So when I think of user story, it is very specific, very, very narrow focus, but also gives some very good scope for it. And the use case is more like, broader context of this whole thing. I think that's the problem with these terms is we're not 100% consistent how we define them because what you're calling a use case, I would call that are fine, I've been tainted by rally, I would call an epic, which is another form of user story with a broad scope. But the reason I'm distinguishing in my head, use case doesn't necessarily involve actors. It involves more about functionality. I am trying to do this thing and this tool would help me to do it. Or there is a thing I want to be able, doesn't necessarily have to involve people. So whatever words we use to categorize those, I think the important thing is requirements, documents are required to justify whatever we suggest you refer to use cases, user stories and any other things in this folder. And so I guess the question is, so what does that mean for this poor request? Or are people happy with it the way it is? Like taking into account our previous conversations or the things people like changed? Essentially, I think what is very much needed for us to have is a reference anchored in the real life. Anchored in the real life. This is really an essence that we need to bring out of either user story or use case or whatever. So that we can, when somebody proposes something, be able to discuss around it to understand why this story is like a real case. Is it a theoretical case? Is it a very broad case happening everywhere or very focused niche one? And then out of that derive understanding of what should be done in order to make things better in a cloud native sense. And this last piece is best practice actually, which I mentioned. So I could work this PR around the systems so that we eliminate people out of it. And if we wanted to, and then simply say how the system should behave and how the systems, what are the challenges with the systems when we talk about Qubenative approach. So this would give us that scope and we can keep the users in the user stories. But I felt the touching actors from systems, because actors always have expectation of the system, might give us too much breakdown. We'll potentially start dealing with, how do we categorize the things? Is it here or there? And so I would suggest that put it together into one kind of, yeah, I don't know how we would call it, merge of user story and use case. One of the reference documents or real life reference, whatever. So you were saying that the template should be an overall template for use cases or user stories and people can fill it out to their use case or user story, is that correct? More or less, I think it should have been looked at once again and maybe extended or more generalized. Maybe we could have options in the templates, like if you don't need this chapter, please skip and focus on the other one, something like that I have in mind. Yeah, so maybe with that framing, people want to kind of like look through this pull request again this week and see what like, yeah, if there's more things that should be added or like contextualized or things like that. Taylor, I see you're unmuting. I guess with the confusion on use cases and user story, my gut feel on it is that we should have two different templates. And ideally, not only a template, but if we can point to two examples that people go, yeah, that's a good user story. I understand why that's a user story. And then the same for the use case, then when someone is looking at the template, they can go over and look at real information, not just loremepsum, and it's filled out. My suspicion here is that while Vux stuff is useful at the moment, the answer is, before we commit it, we try and use it to see how well it's working, and then we can adapt it to what does actually work when we try and put real information in. Or alternatively, we just commit it and we say here is a work, for example, try this. It's not mandatory that you use this, but we recommend this as a starting point. It depends on what we're trying to do here. Are we trying to tell people they must comply with this template or are we trying to tell people that if they use something like this template, their job will be easier? I mean, ultimately, it boils down to what we want for the best practice proposal. And then the suggestion here is, don't bring any best practice if you cannot reference it into a real situation. Don't even think about it. Yeah, I guess. But I'm confused by that because this is a use case template, so not best practice template. I'm not saying that this is a... So if you propose a best practice, you need to reference it to something in the real life, be it the use case, be it the user story, be it whatever elaboration of the case. Just that best practice should not exist in isolation. Yeah, I certainly agree with that. I think we all do, actually. I think we have consensus. So I'm fine with that. But on this particular document, yes. So for best practices, we need context use cases. For use cases, we want a use case to be complete and this is a means of trying to get people to get it to be complete by having all of the information it's gonna need, not suddenly be wanting something that we forget later on. But if we attempt to write a few more use cases, I wonder whether we could do a better job of that because we'll see where it turns out they do need information and where it turns out they don't. And then you'd have rather than us basically arguing somewhat academically about what would be good and what would be bad, we could say, this is what would work best for us because now we've got a little bit practice, we've got a hands dirty. Actually, I had in mind to write one or two use cases, but I put that on hold until we discuss the template and not to write something and then according to template, then there is a lot of other ideas. So I can certainly proceed with that and maybe if somebody else would volunteer and proceed with the additional one, maybe following partially or fully the template and then exactly what you said, Jan, get the hands dirty and then simply say, okay, we had this struggle with this template or we couldn't fit this or that and then we adapt it. We can leave it as a pull request. I can bring additional commit with a concrete example. Yeah, sorry, I'll tell you. The template doesn't, or I'll say the update to the read me, doesn't say use of the template is required. It's not, we're not demanding that. So the template is to help people if you have no idea what you're doing, I guess, for building a use case or try to provide answers to questions. So I'm not opposed, I'll say, to moving forward on merging something. Just so if people want it, if they want to build a use case and they have a lot of content, they don't know how to format it and this helps them and that would be fine too. We can always go back. One thing that I would suggest is if we can link out to references for the standard definitions for use cases and user stories would probably be good, maybe at the top of, or somewhere in here, so that we're not, we don't have to come up with our own thing. These are old terms and there's probably a lot of templates. Yeah, I guess. So I was already putting the comments, plus one for committing now and perfecting later. I guess maybe my suggestion is it sounds like both looking in, like both have use cases that they are considering writing up. Maybe I propose try using this template and come back next week. And if you don't have any major issues, we say this is our first draft of the template and this is what we're going with for now, but obviously it's completely open to be perfecting later. We can always change things. This isn't just a static document that keeps on living. So I think maybe we, yeah, so we try it out if there's nothing wrong, then we say this is what we're using for now. And then as we find things we'd like to change, modify or update, we can do that in the future. So rather than getting stuck on is this template perfect? Being like this is our first step and then kind of moving from there. Yeah, I think I would go a step further than that. I would say if at any point in the week we think this template is good enough, if it hangs together in itself consistent, then if everybody's happy, we can get it in as well. There's no need for it to be perfect. It's sitting in review forever is not helping us. It just gives us somewhere to kind of needle, work and basically point out all the shortcomings of the document, that's not helping. So I think there's a, I don't know how many comments really do sort of point to strong need for change, but if we go through that, I think we could probably have this ready for certainly next week and possibly in the week. Now, does that sound like a reason? A main item to address side of this that there didn't seem to be a big disagreement was about the actors or personas or whatever I want to call them the rules and being able to break that out. Well, if we got nowhere else to put it right now, then why don't we put it in here and then break it out in a separate commit, which is a, you know, and then fine, the actor list will be maybe not have perfectly considered opinion, but again, if this is a place to start with the use case, that's fine. And then we can put more consideration into the actor list and then just refer it out when we put the actor list committing. That sounds good. Okay. So if you had comments and this PR that you're asking for changes, then go back and... Well, I just, I haven't reviewed the document yet, but I just saw a few HTML entries. So you can remove those as well, like all the PR entries. Yeah, those ones. Oh, yeah. Like... Yeah, just for formatting. They're not visible in the, if you view file, go to view file in the three dots up. Yeah, they're not there. Three dots. Oh. No, still see three dots upper, right? Yeah, view file. Then it's actually breaking the lines. Go up, they were here. Oh, yeah. I think the writer of the use case will anyway remove the content. Okay. Yeah, I guess if there's any HTML stuff, I mean, yeah. If you go down, it's past the linting on merge requests or pull requests. So I wasn't too much upset, but thanks, Victor. Great. Then I guess this kind of discussion goes into the next one about like user stories. And I guess this issue is like, there should be user stories too. I guess my question was, do we want to close this? Do we want to have a separate thing? And it sounds like kind of from the previous discussion is that we see user stories as like a different way to justify a best practice. So we should have use cases and also user stories. So we should leave this issue open for right now. I'm just going to comment this on the issue too. So we have that too. And then this next issue too is also the issue for defining the actors and their roles. But as we said before, this is going to be in a later PR. So I don't know if somebody wants to volunteer to take that up. Feel free to raise your hand right now or otherwise we can wait. Is anybody interested in taking the first stab at defining the actors and moving forward with that? I think Taylor's got a proposal and I've had some thoughts on this. So if we take it together and we can have a proposal, we can put full request out. Okay. Sorry, Taylor, I'm volunteering you, who are you right now? I'm good, you're on that. Okay, I'm going to sign both of you on this year right now. Invoke if you want to review or talk with us about it, let us know. Okay, great. Then the next thing is, so this is after the comments and discussions last week around like the governance, we tried to define things a little bit more. So I think there's some confusion about what all the roles do and what they all mean. So we tried to like write something and obviously this is, I mean the governance is up to the groups. This isn't like how it, saying this is how it is. So this is, it would be great to have feedback on this. So one is, oops, wrong link. One is around defining the max representation. So saying that one company can't come in and kind of control the whole control the whole thing. And so what this is is one person from any company can hold a chair roll and also one third of the tech leads can be from one company at a time. And I think Taylor, where did you pull this from? Is this from Kubernetes? Yeah, I think that was the, I don't remember, it was a Kubernetes or TSE type of thing. Yes, this is pulled from another project. Taylor, do you mind if I, because Ian's comment was there's talking about members of committee, but we don't have members of the committee. So in this case, it refers to tech leads. Are you fine if I commit this? Yeah, absolutely. So we don't have a committee, actually. Yeah. So I think Ian, that should resolve your comments too. I need to give this a review properly. I think that, yeah, okay. Yeah, you're, I mean, I see no problem with your diffs. That's fine. You've taken out the reference to the word committee. We've worked out what we're drawing people from, but maybe not what they do quite yet. And so that's fine. We're solving them as separate problems. I think it's good. I don't have any problems with this. So maybe I'll leave this open for one more week, just that. Well, if we don't hold it open on my account leave, let me just give a quick skim and see whether I like it. I guess we have four approvals right now. One, two, three, four. Give me one. You're about to get this. Okay, I guess then, I guess, yeah. If there's no more major disagreements, I think we can probably merge this too. So thanks, Victor, for merging that. So last chance. I think there's might still be inconsistency with the terms company and organization. Is there interchangeably? Company and this one is. So is it all company now? If that's the situation, then it's okay. Yes, it's all companies now. I don't see. Yeah, there's no organization left. We don't organization at all? No, we just say company. I think the other PR for the voting does say organization. Okay, so maybe. It seems like. Company slash organization. I gave a link to the, it's a Kubernetes steering committee. There's other ones too, but that was one of the main ones. Okay, yeah, you're right. Is it easiest just to change just the company slash organization? We're getting to the point that we're being paranoid here. If we actually start reading it, we hope and pray that these rules will never kick in. But if they do. If they do, then we interpret them the way we want to interpret them as well. So we've got a little bit of options. And there's no lawyers in this. Yeah, that's if it goes to that, we probably won't be on the call in. There's a committee again. We're definitely having a committee. That's very clear. Committee. Editing. Yeah. Entire company slash organization, companies, organizations. Yeah. Okay, let me. I'll refresh and commit this. Or do you already get it? No, you can, you can commit those. It's fine. And then, yeah. Thanks for pointing that out. And then also related to that is around the PR approval process, because I think there is, this wasn't defined anywhere. So this is, I started this as a discussion because I didn't want to start it as a pull request because I think this is like open of kind of defining what each of the roles do and kind of like what, I don't want to say power, but maybe responsibility that they have. And kind of the way that I thought about this was kind of right, though the lowest bar should be like the easiest. Oh, thanks for the comment. Yeah, we can, if you want to, you can go in and put slash people, but I think company slash organization is as far as I'll go today. But essentially, so right, the use cases is the lowest kind of like let's say bar with one tech lead and two community members. The charter updates is two chairs, one tech lead and three community members. The best practices is two tech leads and three community members. And kind of the idea here is showing that, like tech leads are really important for doing this because they're the ones actually like deep diving into this and neither the chairs nor the tech leads completely have like the final say, we want to have community input in everything that we do. So while it's important because they're helping kind of like, let's say organize or like lead the group, they're not, they don't have saying like, this is how it is and this is exactly how you do it, but it's also driven by the community too. So this first idea I'd like to hear like some thoughts on like these different roles and responsibilities. Can't tell if silence is good or bad. I'm not sure that those numbers necessarily work, but on the other hand, I mean, if we've got a group, then it seems like a quorum and then a majority would make more sense for charter updates, but you know, conceptually the idea that we deal with this in a separate document and we basically put thresholds in place seems perfectly logical. You know, this also feels like it's a little complex as well. It's hiring number has to. Yeah, if you go back to, again, my experience with the open stack, I know it's anathema around here, but I'll just give it as an example, then it would be good. Most pull requests would be approved by two core developers agreeing and that was maybe a little centralized, but it wasn't a terrible idea. Seems to me that there's not necessarily the use case and the best practice side of things. There's not necessarily any great value in having them differ. The charter updates, I think, is the one that needs to stand separate. And that would seem to be define a quorum and then define a majority. And to be perfectly honest, stick it on the tech leads because the community leaders, the community members are electing tech leads to represent them. Yeah, this is what I know. I think we should consider the option of just the veto power for stakeholders. So for in our case, service providers, the users and the ability for them to maybe have veto power on their best practice and some of the role for just that veto power and they don't have to vote for it, but they can say no, maybe a quorum. I would put, I guess, tying in with what Watson is saying, plus, I guess, both Ann and Frederick, y'all were talking about the complexity. The two things that I think are the most critical to care about with regard to getting approvals are the charter and the best practices. So charter, I think that one's probably easier to say we wanna be careful on what happens there and the chairs are supposed to help with that whoever's elected or that's one of their main things is trying to keep that moving forward. The best practice ties in with stuff. Ian, you've talked about and other people, the best practices eventually, if they're adopted, we say as a group, yes, we have consensus enough to say, this is a good breast practice. They're gonna go into RFPs and stuff. That's gonna affect companies and organizations that are developing and it's going to be part of what service providers with Watson is just mentioning. So there needs to be something about the best practice. I think it's important enough that we maybe differentiate that. Even if all the rest, like remove use cases, maybe the simple one under it is, we want some number of approvers before something goes forward. But the best practices I think is equally as important as the charter because of the impact on adoption. Yeah, I think my point though is there's a separation between the kind, the personal group that creates things and then there's a separation and then there's another group that is affected by those things that are created. So you could call those that second group stakeholders if you want, but that second group, there's certain limitations they should have on what someone's creating something. Maybe the direction maybe is probably not the best place for them to be, they can create something if they want but they shouldn't be saying, oh, don't create this kind of thing. But when it comes down to saying, oh, this is the best for everyone and you're the one consuming it, that affects you. And so that's where getting a stake, the veto power from. It can be abstracted away from this and put into government and things like that. Who is it that's affected by someone polluting the water but someone else is the person that does irrigation or does all these other things with the water, they're not necessarily experts at mining or managing water, but they do want to say, no, you can't do that in my neighborhood or my city or something. And do you think that city councils have enough knowledge about mining to make a decision like that? They have enough to veto it. They don't have enough to say, here's how you will mine or here's how you will, they don't know anything about innovation of mining but they can say, yeah, don't pollute my water. That's okay, but that's some kind of an external interface but I think they don't have enough knowledge to say like what kind of a drilling head you should use. Definitely, definitely you're right. And then we are talking about this kind of best practices also. Yeah, so having the stakeholder or in our, you know, in our example, the citizen but you could say the service provider or whatever, they aren't saying, go ahead and move around or go ahead and here are the very specific kinds and they don't have power over here the very specific kinds of drilling, for example you're saying, or very specific kinds of technology you're gonna use to solve the problem. But they can say that they wanna, oh, microservices that is something or microservices, no, that is not something that we want at a higher level. So it's more of a, and it's a veto power, it's no, it isn't yes. I mean, and they have veto power anyways, right? They can say, no, I don't wanna buy your stuff anyway. So it's not like, you know, this is getting information earlier. Yeah, that sounds like a minus two in the open-style world. So I guess it's perfect, okay. What is the, if you have a, some, I guess I'm thinking like in a justice or law where someone disagrees, it doesn't block but it's noted so that it's public notice that there was disagreement on something moving forward. I can't remember the term for that. A complaint box that no one reads. No, it's like a big controversial law and you talk about the dissent, so dissenting view. I'm just thinking of if, what you're saying. So the first is you're saying veto power and no, which means if a best practice proposal is put forward and you have, let's say, most of the community, the San Francisco community is like, yes, let's do it, but you have someone with veto power that says no, does that just block it and we don't adopt it or would we want to put the note that here's the problem that someone had with moving this forward. So it's a part of the proposal. Well, there's one individual saying no and there's a quorum. So I like that quorum. A lot more sense. If you had a, so you now have a role, so this SP, it could be that we're saying this is all going towards SPs as the end users for the product of the best practices. So applications and infrastructure, whatever is developed following set of best practices, the SPs are gonna consume that. And now we have a quorum of SP representatives that say, no, we don't want y'all to adopt that. We would prefer not to see it. That would make sense. So we don't have that role right now. We'd need to figure that out, but it makes sense to me what you're saying, Watson. This is about the PR practice, a PR going in. So I'm not sure what you're thinking. Do you have any thoughts on how that would tie in with this or that you could add into the discussion otherwise later on, Watson? So I just have one comment. This is the best practices. Go ahead. Oh, yeah. Just referring, this discussion is only focused on the voting part. Because I guess we're assuming that NEPR has to address all the comments and doesn't have any inter-issues or things like that. So we are considered those as part of the approval process or it's just, we're just assuming that those are going to be there. We should definitely wrap this down. So this is only for the approvers. This says approval process, what we should, it really could be the discussion is how many approvers do we need in the PR process before we approve a merge? Okay. So it's one item out of all the rest and all those other things are important. Yeah. This is a good conversation, but I'm going to push it to the GitHub discussion until next week. Cause it seems like we still have some more ideas. So I'd like to hear kind of other people put their thoughts in here. Cause I don't think we're going to come to a conclusion today. So it'd be great to have some more thoughts in there. Cause we only have five minutes left for today. I just wanted to get through kind of like the last couple of things on the agenda. One of them being the voting process. So there is some discussion here, but there hasn't been kind of anything since last week. I just wanted to check in if people had had time to look at this, if they had any more questions, things like that. Cause I think this is kind of like an important thing cause the elections are going to be coming up here. So just reminding people to look at this cause it would be great to kind of come to a conclusion and get it committed next week. Is there anything anyone would like to bring up about this PR right now? I mean, obviously feel free to on GitHub too. Okay. So four minutes left. I also wanted to bring to everybody's attention that the self-nomination period is currently open. And just as a reminder, in case you forgot, there's also a link to here to nominate yourself for either a co-chair or a tech lead position. Please send the information to the mailing list. We'll get it approved there. And so far we do have nominations for a co-chair from Jeffrey in the service provider co-chair from Ian for co-chair in the CNF developer co-chair position and also from book for the co-chair or tech lead. So he's nominating himself for both. That means we currently don't have anybody yet from the Kubernetes community who's self-nominated themselves and we only have one tech lead. So all the conversations we were having earlier about the PR approval process would be for not if we may have one tech lead because none of that cleared the bar. So I encourage people. If you're interested, please consider running. And I know I've talked to a couple of people who have who we're interested in running and just haven't submitted yet. So if you have any questions, please feel free to reach out to me or Taylor to chat about if it's you're interested in. Yeah, are there any questions about the self-nomination period? It does end next Monday. I'd like to propose extending that. We've had a bunch of questions. Okay. Trying to address some confusion. So extend both of them by at least one week and maybe extend the tech leads. We had more interest earlier and I'm trying to get some responses, especially on the Kubernetes community. There was discussions before the holidays and there's been some calls after. Maybe extend that one a week out so it's staggered. We have the chairs come in but then we could still have tech leads. And I know that there's some of the people have said they're talking internally. So I think there's the coordination internal to get back with us. I must admit I'm a bit confused about tech leads because I'm not sure I know what the tech domains are. And so every candidate kind of defines the domain and then proposes themselves as the leader. But can we try to somehow flesh out ideas for what are the tech domains that we're looking for leaders for? Yeah, so this is the part of the reason, Bill. I wanna extend tech leads further because of the confusion. The short would be we can have more than one. There's no limit on the number of tech leads. Although probably everybody shouldn't just go for it. The main idea is if there's an area that you think is that we need to, that's important to focus on for the CNF working group and you have time and a passion to go into it, then you can put yourself forward for it. We don't have to say a specific domain. You may say, I wanna help with use cases. So that could be general or you could say you wanna help with a maybe a best practice area like handling state in a cloud native way. You're like, I'm passionate about that because we're building applications that need to deal with state. So I wanna go into that and that could be a focus area. But we're also talking about nominations for both chairs and tech leads that are going a year, I believe is the same, isn't it, Bill? It's a year, but which means you may be focused on let's say cloud native state because that's an area that you care about now but three months from now, that may not be the focus but you probably have multiple things that are gonna be happening. So you need to be able to shift your focus and not just think I'm doing cloud native state for a year. You'll do it as long as it's something that's relevant. I don't wanna lock you into one, anyone into one specific small area as a tech lead. Yeah, I was more thinking about maybe trying to get more people involved and I'm trying to get some of my colleagues interested. So it would have helped me if there were already a few areas or domains listed as areas that we're looking for, like security, for example. Are we interested in somebody with that kind of expertise? Are we not? Absolutely. Yeah, I mean, actually maybe a good first place to start would actually be in the, oops, where, oh, where I can't find it, would be the different areas outlined here. Right, so those are based on categories trying to take a lot of the cloud native principles where I can amend the various categories and that's really what we're saying. So anything, if we go from cloud native principles and you start going down into an area, you can be at a higher level and save security. I wanna, I care about anything security. Well, that's gonna cover a lot of things where you could start getting down and go deployment issues with security. So it's whatever you want on that, but definitely the cloud native principles would be the first place. And I gave another link, fundamental concepts that I would say even a little bit higher than what this is, but targeting cloud native principles. So yeah, so we'll hopefully send out some information later this week to clarify what the different areas are. I mean, we'll also extend the nomination period for a week. So we are a bit over. So thanks everybody that could stay on the line. I appreciate it. Unless anybody has anything else, I think we can probably close for today. Okay, thanks everyone for joining. Thank you, bye. Thanks everybody. Thanks.