 Okay, I think we can probably get started today. So thanks everybody for joining the CNF working group. Just once more drop the link to the meeting minutes in the chat if you want to just add your name there, then we can get started. And before we kind of jump into our topics today, does anyone have anything they'd like to add to the agenda. I'm seeing nothing. We can jump in just two things I want to highlight for those that are interested. The first one is cube con cloud native con Europe is coming up in May. So it's May 4 through the seventh. And something that might be especially interesting to this group is that there's now going to be the Kubernetes on Edge event at co located to cube con says the Monday before cube con actually starts the CFP is currently open if you're interested in using Edge use cases that you'd like to talk about or interested in learning more about the edge. So, I think we can jump right in. So, I saw Jeff Salons is on the call. Do you want to talk about these two pull requests that you have. Sure. Yeah, thank you for pulling them up. So you got I sorry I missed last week, but the group is a large approved an existing pull request for we adding context so specifically like when we start talking about best practices, providing a little context just because a best practice might be very use case specific. For instance, there was in the discussions, a lot of talk, I was using this example of privilege containers. You know the concept of police privilege containers to be defined in route, etc right. And so there are lots and lots of instances where that is absolutely the best practice. There are instances though, like, when we start getting into some of the more fuzzier definitions of what is and isn't a CNF but like it's a orchestration provisioning service comes with the CNF and it's built in and it needs to make requests of the infrastructure underneath to do that it's going to have to have privilege right like it's going to be able, it needs to be able to talk to the kernel make requests. And it still applies. So just because it should only have the privileges it needs but just in general right like saying hard and fast. All containers would never need to talk to the kernel is a little misleading right so that got approved. I talked to Taylor last week, and we agreed that maybe the place that I originally stuck it was a little bit awkward on how it flows with the overall proposal layout. And so we kind of just put it in a spot we think it flows a little bit better. It comes before the user stories, but after the initial pitch. That way you're not adding any like you know, I don't say negativity but basically kind of like already adding like counter arguments to your own proposal before you get to, you know the meat and potato so you get to the entire pitch. And then right before you hit user stories you say by the way you know it's for these specific types of things it might not apply to these specific things, and then you can start building your user stories now that you have the context. So that was just kind of the thought on why we moved where we think context should go, and then conversely, I had waited until we agreed that context was needed in the first place before attempting to go to the actual template and adding it there. I created a separate PR just in case we don't want to move it, we can work on the two independently for adding the context to the actual template itself now that it's been agreed upon in the other proposal definition. Well, thanks. Does anybody have any thoughts on this. Can you click the other view bill. The little rat my viewed. Yeah. Yeah, so it's just essentially moving something higher, and then adding a note in here about adding a warning when obviously not all workload types are the same so there should be a warning when things aren't the same. So one comment to add. The, for those who weren't on the telecom user group, one of the areas of discussion was how do. How are we going to work with what's currently available and and potentially building from there and dealing with current active problems on networking deployment orchestration other things. So, I think that this that bottom area for notes constraints and caveats ties in is to communicate where a best practice may have problems and that's the importance of this. So, a best practice may be put forward but it wouldn't help with a specific type of workload and calling that out for those that. It's not implicitly visible is is a good thing. And that the workload context at the top is supposed to help drive those type of decisions and thoughts on whether or not the best practices useful for you. Why are the user stories optional. I think that probably needs to be changed based on the direction that we've been moving and adding those. That's a. They're not optional when we look at the outside and referencing so it's having some context. Maybe it was just originally we had so many items there Watson. So I think that was like saying, let's not make it optional. But not optional and on the anti context or whatever that section wise where it's saying. Oh, in these contexts it's not this, I guess, that's practice or whatever is not useful or whatever. No, I'd say make it so to where that part is also not optional for those user stories if you're going to put something in there you should have a real reason why. But the user stories make sense for me to say it's not optional. So if you're going to propose something then then you need to be able to say, how does it relate to the real world. Make up a user story. Yeah, have them to where they write a user story and other people for going to have them separate a link to use a story. And then people can either vote on it and make a survey off the user story or whatever this, you make up a user story and has zero people supporting it and that's the strength of your the argument for your best practice proposal. And so, yeah. So on the user story specifically, when you're when you have a best practice that you want to talk about, then, but you're not, maybe you don't even have a full user story but you're saying they're using this type of methodology process or whatever you're looking at over in the Kubernetes world for other applications and it seems like we should use it here but you can't quite come up with the user story. You're probably better off not creating a pull request but instead go create a GitHub discussion and say I'm trying to I'd like to have help on creating the user story. So that by the time we get in and and you say let's create this as a pull request, we think we found a solid, a solid best practice proposal, then you have a user story to find. So I guess I, I'm agreeing and we need to and maybe Watson you could go to a pull request against the, the template and say let's make this non optional. So by the time someone does a pull request we're saying it would be blocked until you complete all the items that are non optional. I want to separate that from the notes and caveat section. So when you get into the notes and caveats that this is essentially a catch all so we may want to break that out and not just have it with all those constraints and caveats so we may notes could just be referenced. And tied in with like the references. So any, any other details that are helpful to understand the best practice. That's what this is for. And I don't think we should have a required note section. But if, if the caveats is something that we want to say is non optional, then we should do a change on this. Are you suggesting that that's non optional or was I miss understanding. Yeah, basically every architectural decision as some type of trade off so you basically have some problem if you don't know what your trade offs are. So it should be in there. I would rather be called a trade off, but copy I work. Right. So then that should be, it seems like that should be split from that section and just not have it at the end that third, third piece that you're there Bill, if you highlight we have three pieces there notes constraints and caveats. And we could make the caveats, another section maybe right right below user stories. And then you have the notes and constraints as optional but you have the trade off or caveat whatever it want to be called. Okay. Yeah. Would you be up for doing a pull request for that Watson just to split that off. Cheers. Thanks. Can I name it if you think trade offs helps with. I'm guessing that you're saying on the language trade off would communicate what you're, you're saying any best practices going to have trade offs, or any solution that's proposed will have its own trade offs. Yeah. Okay, so thanks Watson for making the pull request on that. No, I guess going back to like this PR. So this is just moving something like up above. You know, Jeff, I think you made this just earlier today. So I think I'd be happier if we four days ago. I'm happy to approve it as is, but I don't know if other people want to like have time to add their comments. Or is there any objection to moving forward. This is the first iteration like Watson would you be object to moving it forward on. Just some language added to the existing, and then your pull request come after or do you want. Do you object to moving just forward. Okay. Great. So I think we can probably merge these pull requests now. Okay. Great. Thanks Jeff for making those pull requests and forgetting that Merge in and for Watson for opening up a PR to help change that too. Great. So point two, so making the goals more concise. So it's changing around the scissors in the read me, and it's like, basically changing around the goals of the group. It's a little bit of like wordsmithing. I don't know Taylor, you want to add something more. So the, I guess, at the highest level, and there's two things. Number one, we're moving away from talking about required or conformance type words. So moving away from that language towards this language of best practices so we're putting forward best practices. So that could be relevant to either developers so you're you're developing CNS or you're maybe you're an ops operator ops team, sorry, not just an operator but you're on an ops team, and is this best practice relevant to you so moving forward towards that as far as language. Another part would be thinking about networking in general so that was another earlier topic if you're on the tag call, and, and shrinking that in, and then a little bit more focus around Kubernetes so it's, that's really the language we've been using that uses. So this is trying to update the charter to, to match that. And there were some of these that was, I think from earlier, the early parts of the charter that was put together. And then I see you've expanded a few of those things Kubernetes versus. Do you mind if I commit that. I'm looking I just, I hadn't read those. I think there's consistency versus effectively. There's some comments about even removing some of these because they're duplicate but I think we can do that in another iteration. I'm going to, I'll just commit that I'm good either way. Are you committing most. I committed yours, you should be able to refresh and most of what you're doing is grammar. Jeffrey did a. Yeah, approval. Jeffrey did an approval. Approve on this. Can you do the other view. For the difference. So that's kind of shows, we're met, we're primarily removing. A lot of the extra words. So I think we have four approvals now, unless there's a lot of any objections or questions on this. Well, I just get back to the other view. Yeah, go ahead. Just regarding that in the first bullet you are removing the cloud, at least dropping a little bit about the cloud native principles. Is that okay, like a way that you describe like it's just identifying best practices, but it's not referring anything to cloud native principles is that is that it's not reducing the scope of this bullet or it's keeping the same. That probably is my question. So that's a good comment. I guess the first part would be the rest of the charter. If you look at the whole context and cloud native principles and Kubernetes native best practices is still there. If you look at those two goals by themselves then the change does drop that but that's, that's not the intention. And these are would be identify Kubernetes native and at a general more general level level would be cloud native best practices. So that that could be explicit to identify Kubernetes and cloud native best practices for CNS that would be how I would write that. The main part was to remove the portion on using to be used to demonstrate how well software adheres to cloud native principles. And that's not the intent really what we're saying is whether you're a CNF developer you're developing software that that could be run on that's to be run on Kubernetes, or you're a, an operator trying to find different networking applications that you're going to use. You're handing this over to your ops team to identify this. We're hoping that the best practices will help developers to build better software that runs Kubernetes and the ops team to see software that helps them do the life cycle management they're going to do. So that's what the language is about. So not just saying we're demonstrating that's good, but it's actually helping their lives. But putting the cloud native back in front of identify before best practices could be a good idea. Before where. So, we lost here was the cloud native principles, or cloud native so it would be between it'd be right after to identify cloud native best practices, or cube native whatever we want to say on here but you could put cloud native. Yep, there we go. Does that address the concern that was being voiced about cloud native. Oh yeah, being lost. Okay. And as I said it's not removed from the whole charter it was just removed at that sub award. Any other comments or suggestion objections, any other comments or objections to merging right now. Okay. It's merged. Great. Also, thank you for the comment and clean it back it was that Victor. Yeah. Yeah, thank you for helping out with that. Cool. The next one is tailors. So these one actually these two next to actually kind of go hand in hand. One is the user stories issue. And the other one is the use case folder. And I don't know, Ian, do you want to is Ian on the call. I am. Do you feel like this, what the use case folder address a little bit of user stories or would you like them to be kind of like separate things or how would you. Yeah, I think for the time being we stick them in there. This doesn't have to be perfect apart from anything else but secondly it just confuses. It's not always clear in people's mind when something's a use case and something's a user story but with apologies because I didn't write my documents last week. I was going to put together the a grand overarching user story that pretty much walks through the general deploy and use cycle, saying, you know, roughly operators and architects decide how this works and are going to want to go through the use cases. I'll stuff it in the user in the use case folder, and then I think actually with a concrete example in front of us we'll be better off able to decide whether that's where it belongs or if we need to do something else. So I'm inclined to say leave it alone right now and we'll figure it out if it turns out that things that wrong. And then do you feel like we could kind of close this issue if we can merge this for now at least. I feel like there's this is something you'd still want to leave open. I can't which one that is I'm going to second. It's number 38, I can also put it in the chat. Well that's a, you're saying that get an issue versus the pull request. Yeah, use it. Use case folder. Yeah. We can also, we can also walk through this pull request and kind of go through some of the comments here. So this pull request 46 is like the like the last two, just one iteration so we can come back over this and and add more, just like we've been doing in the pull request itself. We don't have to have it to perfect if it doesn't encompass everything. It's a structure. Can you click on the other view. Again. So one thing to point out is we're using the wording of networking use cases is it's been talked about many times that the networking applications can be used in the taco world and also outside you have the same application that's used many places so we want to make sure that the use cases are restricted where they're going to have a larger application. And then, and I believe in the could have been slack or it could have been on the discussion board in pointed out that there's going to be both use cases and best practices that may not be working but are applicable so even though this says on this, the discussion, I mean on the PR it says networking use cases, the folder itself is use case. And when we're requesting use cases, if you have one that you may not think is networking specific but it's applicable outside then feel free to add something it's, we're not we're not limiting it to just networking, if it's but the first part of this is we're creating a folder just to mainly talk about a very important area. And this is use cases. I don't know that we need a user story, but I do want to point out for those who don't know a use case and user story or two different things. So we may need to expand on this to say, we, if you have a user story or use case, then you can put those in. But this is getting started. So we have this use case folder where we can add larger documents that we want to keep around like in was talking about if you have a smaller use case, and we have it fully fleshed out. Then we'll get pull request in there. If you don't really have anything other than maybe you just have the title of a use case you've seen it someone's talking about it. You know, it would be relevant to bring over here, then probably that first discussion topic, which is linked there at and that first paragraph how to add. So there's we have a discussion long get hub discussion just add add the, add the title maybe a link whatever else if you already know about a yet right there so you can just add to this. Add to this topic and we can sit here and keep adding more as we're going along. But maybe you have a use case already that you can describe, but you're not yet ready with enough details will then create a get hub discussion topic that's that second bullet point under how to add. So add a discussion topic. It's, I'm sorry not bullet point second paragraph under how to add. So create a brand new discussion topic, and then you can put in line images whatever you want to do link to external material, and we can start building it out before we do a full write up and add it into the use case folder. And then once we're actually ready to add something into the use case folder because we're saying we're planning on referring to this from the different best practices we're going to actually link to these use cases. So make sure that we have all the content number one, and then the other point to point out is, whether you have a single file, or you create a folder with lots content. We want to keep as much material within the repo itself, rather than, say, link to an external Google doc. So we don't want to use case mark down that just says, go read the real one over here, or a PDF or something else. We just try to bring the content internally. And I think tooling and stuff around that's like to be determined but just think in 10 of trying to go internal, and as much as possible have the content go in line so we don't want just upload a PDF to the get Yeah, so to expand on that there's two aims there one is our use cases a version controlled because if we change our mind we want to know we've changed our mind if you basically refer out to a Google doc then there's two problems with that one is the link can break. Right, you delete the Google doc because you've moved on. The other is that you can change the document without going through any sort of approval process so anything that's really kind of concretely meaningful to the use case wants to be actually committed so that it's version controlled. And as I say the other part of that is external references links age out we want to make sure that doesn't happen to us if it's got material information that we don't want to lose. So editability I think it's pretty clear right if if the document is if somebody embeds a PDF. And it's not got any source and it's uneditable. And more to the point it's not even difficult. If it's a whopping great binary so word documents will fall into the same category, then you're basically just cutting a barrier to entry and to understanding what changes are being made as well. I can't diff two word documents so if you change the spelling mistakes in a word document I can't tell so markdown is much favored on that. I think we were also having a conversation on diagrams and I'm not saying that we favor a tool over others but I would point out that draw.io. You can embed editable PNGs or editable SVGs which at least means that somebody stands a chance of being able to change your, your nice PNG. If you put it in there so just bear that in mind when you're selecting your tools to illustrate your use case. Yeah, so I see we have a couple different discussions here. I don't know the current status of these. Do you make this change. So, relating real world use cases. I didn't so that the main thing here was splitting off best practices by itself was kind of incomplete but if we split those two went so just completing the wording there. But feel free to base on that last comment. And the last comment and that thread. They seem to agree with that so we just have the relating and not, we don't really need the best practices. So you can do a suggestion. If you do. Can I do it in here. Yeah, no but do it above. Yeah, go back to the very top of it. Where he suggested. It's just right here. Yeah. So, yeah, that works. Just adjust that one part. I think we can mark this one as resolved then. Okay. Then we have Robbie. I think this is a discussion. Do we want like a kind of a template or not. Going for this going forwards for this. I think we should. Like, I think there's got to be some kind of distinction between. This is a use case we all agree, because in the previous call we were talking about potentially using those as like foundational pieces to then start building best practices off of. We were talking about like the orchestration task force, et cetera. And I guess if there's not like a team of we're not going to kind of like expect certain things to describe a use case, then I don't see. They're being very much of a distinction between what's in the discussion boards and what's, you know, drafted in a document and checked in. I agree that we need templates. My suggestion right now is let's move forward with the request for use cases, and then we start building out the templates either next. So if someone wants to take on that, then they feel free to or organically as we start to see use cases. If we actually had, let's say, 10 use case PRs because people are ready. They just said, I have all the content. I have SVGs. I'm ready to create PRs. I'm happy to have that problem. Right now we don't have any use cases fully fleshed out at all. I do need a template, but I'm just saying I don't think we have to block asking for contributions at a minimum contributions to the discussion board before we move forward. Yeah, I guess. Is it okay if we create an issue for it and then just resolve this conversation for now. And then we can come back later with a PR to add the template. Yeah, I'm fine with resolving this comment. I do at the top though, some of the wording choices I would like us to look at it I put some stuff in I think we kind of skip past that one but this one I'm fine with. I'm fine with just getting something down instead of googling forever on some of these initial PRs. So I'll create the issue for that. After this. And then for the wording one. I'll be honest, like knowing me into your page. I've just put a dip in for that. Oh, did you. Yeah. I so I haven't let me finish that review and then I will put it in. Okay. Right now it's in. I hate it when it does that. Sorry I was trying to get rid of the passive voice at the same time so it's not quite the wording that Jeff use is agreed upon is is just awkward. He says, you know, this will happen without your assistance. Don't be worried about it. I mean your people were speaking English before mine so I'm down to take your lead on this. But the, yeah, I mean the big thing you're welcome to submit it in Flemish if that makes you happier. No, I mean the big thing for me it was just a couple things is I think, like, most clearly like, I don't know just. You know, you're new slack means and you don't think it's quite as strong as I just sometimes when you say stuff like that like I just know that there's executives in my company that will latch on to that and then like they just like run a muck. You know when you use stronger language like that and then the other thing is is what you put it in your, your rework is specifically, you know, tying it into like the Kubernetes piece right. I just think there was a little too much ambiguity of, you know, Kubernetes best practice first cloud data best practice first, you know, I know you are sneakily underneath behind the scenes and like well I could just say this is a best practice because we agreed upon and it doesn't matter if it even uses Kubernetes. So just being a little bit more succinct and direct here I think is helpful and I'm cool with what Ian reworded this to. Yeah, whether it says Kubernetes or not I don't think it's necessary but on the other hand I have no objection to it as for the strength of the wording it's more in the eye of the reader than the writer and it's the reader that we care about so again totally fine. Okay. Great. So it looks like we resolved all the conversations on this. So unless anybody has anything else they want to bring up doing we can probably do it. And then merge this one to. Okay, great. We're just clicking right along in this meeting. Yeah, I don't hate to use the, and the, and try it phrase but the, the perfect is the enemy of the good we can always accept these changes and change them again later something wrong with that. Exactly. This is another one that's been kicking around for a while. There's been quite a long discussion. There's a lot about this like defining the actors and I think this will play into the use cases. If anybody's interested in writing up kind of a summary of all these discussions I think there's quite a lot of material here and now we just need to refine it into kind the first draft. Yeah, if there's anybody interested. I want to go with this before we don't as well so I haven't commented on that yet but I think we can. I don't actually have much objection I just think that's very fine grain so I wouldn't whether there's some way of basically summarizing maybe the ones that we care the most about. I would go to the top on that so that not the bottom area. Can I maybe share my screen for a moment on this and then you can talk to it. Yeah. Yeah, okay. Yeah, let's see. Okay, it looks good. So, I've tried to keep coming back and updating the top, and which I think you can see this way if you, I don't know if y'all are able to see yourself when you're on the on the discussion board but if you hopefully can see the revisions. So the revisions are as I tried to merge what everyone was talking about and coming to some type of consensus around it. What it doesn't have is the last updates like it doesn't have this one and it doesn't have I think system integrators are there, but it may not have this one here and then this longer thread. There's a part right here I think Jeff that you added. It may not have those. The purchaser, I think the purchasers probably the biggest one. But if you start here and look at what's there, and then go look to see what questions or comments have been added that's where I would start, because I am trying to keep this updated to whatever is the most current consensus. That was the last one is on December night so there's been a little bit more. So we tried to separate the different orgs from the actors. This context part is, we don't have to do that every time but the point was, you may have a CNF developer that is at a service provider. You may have an internal team, and you may have a ops team person that's similarly they're outside they're inside any of these so we tried to separate those from the org and system integrator they're added here. I don't know where that purchaser would be. But the idea that the different actors those higher level actors could be in different places. I think it's going to be towards something that's more usable across the board, but I go ahead and if you have some direct comments if we want to do this discussion or if we want to have another iteration on this outside. I think it's going to be both honestly but if we discuss it then we'll get the iteration right so I think you're right that it's there are set roles that are completely independent of which organization they're in. And then there are a set of organizations that matter because they tend to define the way the roles communicate with each other a little bit. So for instance if I've got service provider and it's a fairly common example. That's buying in everything right they're buying the platform from one group they're buying them CNS for three or four other vendors. They have a, they either employ a system integrator or they are a system integrator but there's definitely system integration that's happening. And so the roles exist. But what we're actually doing is describing the situation on the ground which we could do separately in an extra section. The roles I think we need to be a little bit more wordy about what the roles do and I would point out and you're going to argue with me that an infrastructure developer is not a CNF developer so that one's just basically slightly the tree is a little bit wonky, but and you might argue, some of these things are not so much roles as hats that a role wears right when a CNF operator is got a security hat on he's looking at it in a certain specific way in a particular with a particular mindset. That doesn't necessarily mean that there is, there is almost certainly a security team I'm not arguing that, but I don't think I think it's better to lump that into operator behavior than it is to try and call out the security person and say that they act in a certain way. So, you know it might be easier to kind of describe the perspectives that a role will have on a problem. Are you suggesting that we have the roles as the main focus and then anyone can step and maybe rather than trying to do it in a pointed list we try and give a paragraph or two to each role to explain how we're thinking of them. Because, you know, two words we know from past experience like for instance, network to take one example are ambiguous enough that you don't necessarily get the detail there. You know putting some words on that basically says, we are thinking of a CNF developer as this. If you want to argue with that then you can put pull request in on this document and if you don't want to then we're at least not being ambiguous about what we mean. I think the end goal of having paragraphs would be where we want to go this this was this discussion and maybe the bullets are. This is all just a start, but eventually what was one of the repository, but do we want. I think the actors are relevant as well but if it do we want to start a new discussion just for the roles or have the roles as. I think if this is a discussion then the answer is probably that we've got enough information in here and common thinking that we could put a pull request together, trying to actually put that into a document because at this point we're actually trying the document so that we're not, as you say editing the first element in the discussion all the time is it's maybe time it's maybe ready. I think is what we're ready to say. I mean even if it's slightly under debate then actually, you know, commenting on the document would probably be the way to further this. I'm wondering as far as the, you're saying that we could have paragraphs for the roles but what are the roles. If we're going to have that and we could have a list. Definitely moving to a document that's possible sounds like we may need to maybe the interest on moving forward on this discussion is here here. And so now people are wanting to have a something that we can update quicker so a Google a Google doc or whatever might be easier, but it seems like we still need roles so the like what is. The roles that we're talking about. Well, I mean, the ones I've been working with are effectively the operator who is actually running a CNF day to day. The network architect who's deciding and describing how the CNF fits into their network long before it's actually implemented. The platform developer who's making the Kubernetes that the CNF is running on whether that's enhancing that Kubernetes or deploying it at both of those really, you know, the piece of software that the operator is going to use. I think the system integrator because there's a whole bunch about how this is configured and poached and prodded when it's running where you can arguably say it's a system integration task because you know you do it for the operator lays hands on it. And you continue to do it while the operator is using it to make their job easier. So those are the roles I'd stick with and then try and, you know, as a question of which companies to those roles live in and how strong are the lines of communications with them which is, you know, you can provide example context. And whether or not they look at things with different perspectives like, you know, the CNF operator needs to satisfy the security requirements of their customers. How are those requests coming in what are the sort of things they're going to be asked to do, kind of. So that would be a perspective an example of a perspective. And that is a proposal for debate so the silence is not encouraging. Yeah, I think. Go ahead. Well, I was, can we add those can you send. I don't know if you're pulling them all off your head I didn't get a matter if you can add something to the bottom of the discussion so that it's written down. And then, okay, we can take it offline and discuss where that pull request, you know where the actual changes want to sit in the repo and get it written up. Cool. Taylor, I guess now that you're sharing screen can you just go back to the agenda doc. I'll stop. Nice. Yes, we have about eight minutes left so I guess we might not have a full discussion on these last couple issues but I definitely want to get to them. I know there's kind of two ones. Actually, I think I'll skip over this one for right now. I know I saw Ruben was on the call and he made this polar cross chance to read me. Ruben do you want to just quickly just like walk through this. Yes, of course. It's very simple thing about the operation of CNF I felt the scope just deploy and manage was a bit was a bit too narrow. Much preferred the way I much prefer the wording of life cycle management. Now excuse if my wording is not English completely perfect. Some other people can turn that out better than me. But I hope you understand. You understand the content. So it's just about speaking first about life cycle management for CNF operators and then give you an example. Because there's, I felt is more to it and just deploy and management config management of great deployment. Remove it and I could think of tons of other things. That's all. Thank you. This is great. I guess, are there any comments on this pull request I don't know if Lisa is also adding saying she likes the addition of life cycle management. I know this just came in four hours ago so I wouldn't merge this day but I'm happy to like approve this but I just want to make sure other people have time to comment on it too. If that makes sense for you Ruben. Yes, of course. Absolutely. Yeah, thank you for that pull request though. So I'm going to leave this open for another week just so that people have time to look at it and if you have things you want to add the pull request is here. The other thing that we have is CNF candidates for assessment. I know there's just some comments here. If anybody, one idea was to start with if we are going to have those like use cases to actually pull down some CNS and see what the problems are. And so, if anybody has any ideas who would be interested in providing a CNF to see what the potential like use cases are and what best practices we can pull from them. So please add it to the discussion here so that we can kind of get for move forwards and start adding some use cases to the folder that we now have. And then so we have about five minutes left so I just wanted to touch on a couple last things. So, last week we announced we are going to be looking for chairs for the working group. We were supposed to have the governance PR, because at CNCF we really believe in open governance, having the governance PR ready for this meeting but unfortunately we didn't quite get it there but it will be at some point this week we'll have that we'll hopefully, and we'll discuss that at the meeting next week. So, that will decide on how this group will be governed going forwards and then after that, we'll have elections for the chairs to lead this group. Okay, let me add to that a little bit so the main, the, just like all the rest of the stuff that we've been talking is iterative process. So we, the charter exists right now we have some information of course already in the charter, the governance section is empty, practically, so that the parts that we're going to be adding into are starting with what are roles, what are the different roles within the governance portion so we'll be adding to that that's the first thing that's going to be built created based on what exists and existing CNCF, CIGs and working groups so if you go and look at the TOC CIG formation roles, where you go look at some of the other CIGs, it's based on that. And we'll be pulling from those to create what's what's we're going to be using. And then the, the other part is about the process around elections. There's many other things within the governance so we'll be going forward, eventually as needed but those are the two main parts that we're trying to focus on. And then if you missed last week for the elections that we're looking towards us on the, we'll do a nomination process, and that'll be nominating for those roles. And then we'll have the election and help terms and stuff like that. Thanks Taylor. And then the last thing on the agenda is, maybe, Taylor do you want to give a two minute summary of what happened in the TOG meeting and kind of the discussion there. Sure, so the TOG topic was around, primarily around a group group that's formed, I guess we can stick with the name right now Task Force, Networking Orchestration Task Force and what that's been about and then how does it relate to, I would say, I'll just say all the rest of the CNCF, telecom and networking focused efforts that we've been doing. And that was, there's, we really came to a decision that there's two main parts one was finding the problem statement around the networking and orchestration and what are we trying to do there. And then the gap analysis other things and how does that fit, and then looking for potential solutions that are there right now and presenting those. So presentation of solutions and other things we're going to have a follow up for a project called Eno on the next telecom user group, probably before next month, potentially. And then the problem analysis and putting forward those is going to move into a discussion topic probably a new one and then maybe become some documents in the CNF working group. So we're going to continue to move forward and on that because it is related to multiple groups. Thanks Taylor. And that was perfect timing so it's now the top of the hour, unless anybody else has something they want to add right now. Thanks everyone for coming today and yeah, have a nice day. Cheers.