 Okay, I think we can probably get started. So thanks everybody for joining today. This is a CNF working group we meet weekly on Mondays at 1600 UTC. So the link to the meeting minutes is in the chat if you want to add your name at the top just so we can keep track of who's here that'd be great. Before we jump in, is there anything that anyone wants to add to the agenda. Okay, there's nothing we'll just dive right in. So the first one is a idea that Ian brought up in the Slack channel. And basically, he would like to have some basic ground rules for like pull requests, basically, having things languish and kind of having some rules. And if there's no major disagreements, then we should be able to merge things. Obviously, I think this will allow us to kind of move forward faster and make people feel like they can edit things because things will get merged and approved. So Ian, is there anything else you want to add to that? Particularly, I don't think. Okay. Does anybody have any thoughts on this or like ideas on how we could frame this maybe. Just some way of moving them forward so that they don't sit there for weeks. Yeah, this is Watson. Yeah, we did. We have had a problem in the, I want to say the subgroup or some other groups where there were some rules definitions actually pushed through ran through really quickly. There's like low attendance. So I'd rather not do the, like one or two weeks or something probably make use it as like a something that it's not caught in a longer. There's probably some other problem if we're not approving things within a month, let's say. Yeah, so I think the question is how long is a good idea. The idea being that if you've got something worth committing then, or, you know, that you're proposing to commit that it can always be edited after the fact. This, you know, to say that it's in the repository does not mean to say that it's part of anything we would necessarily release, but beyond a certain point it becomes very difficult to kind of propose meaningful edits in a pull request. It's easier to add a pull request on top of something that's already been committed than is to eternally debate something in the pull request itself. Are you talking about, do we have a real example that we can look at? Are there ones that have zero approvals yet? No, we don't. But we don't have ones that are ever, we rarely have ones that are fully approved by every reviewer we've asked to look at it as well so that I think is more the question. Okay, yeah, so that maybe that's something we could say like it needs at least two approvers. Usually the list is just to get someone's attention that when we have eight people on, we're not saying we want all of them to approve. We want some number of them and they're usually just here's some interested parties. So a minimum and I think that would address what you're saying Watson that we're not going to let just anything through, but when there's only a small number of attendees, it could be. Yeah, quorum, some type of quorum, something like that maybe. Yeah, I guess, does anybody have an answer? Oh, go ahead. I'm going to say if the problem is, if the problem is things being hard to edit in, you know, pull request, and maybe it could be marked as draft, or whatever, as we edited, and we can approve it into a draft and it has draft as the name. And then the final approvals takes a draft out of the name. What would determine when draft goes away or when it needs to have drafted its name. That would be the final pull request would be taking draft out the name, and then that at that point we're getting into whatever democratic process or whatever it is that we're doing, as far as saying okay it's accepted. I guess, I would be in favor of keeping things fairly lightweight rather than having a lot of rules and requirements on how and when pull request can be merged, I think, agree with Ian like we should have like some things that things don't just sit around forever but I don't think we need to make it really laborious otherwise I think it's going to really slow down the work of the group. Yeah, that's a really serious point of the quorum. Once that we have defined the roles, I guess that we can use those roles as approvers right. Yeah. Yeah, I think that's probably one of the problem. Yeah, it's probably you also end up in a situation where so small number of people is basically making this all the decisions. If you do it that way. I definitely want to keep it where the only thing with roles would be enough people from groups but not the the tech leads and chairs are not final approvers on any of this it's still community voting. We can go up with some number and then shifted if it. If it doesn't work like the chart charter updates probably should have more people and then other things as they're coming in, adding use cases and and other things could probably have a smaller number. And then we can shift those if it if it doesn't feel like we have enough. representation within the group. Yeah. Maybe I can take a stab at a pull request around this next week. And then we can kind of once maybe it'll be easier once we have like something like a little bit more concrete. How would we approve your pull request. Question. How about this negative proposal bill to talk about in the group. You know, I can drop it in as a Google doc or whatever to discuss, or actually I get have discussion. Yeah, I mean, theoretically, we could just use the process laid out in the pull request to approve the pull request. Yeah, I mean, then be facetious obviously but I think that trying to put it down in paper is probably the right answer. Because it's where they're in once we've got the details and it's a document it does actually look halfway plausible. Yeah. Okay, so I just want to point out, you know, it's a repository. I hope we treat it as a living document it's not necessarily, you know, if a pull request gets approved it's not somebody's power play to define things for the whole group forever. Right. Yeah, exactly. Okay. So, is there anything that anyone else wants to add on that before we kind of move to the next topics. So I think we could probably go on this topic for the rest of the meeting, but until I think we have something more concrete. I don't know if it would be really productive, or as productive as going on to other topics. This is all over I just have a quick comment and I would suggest we don't actually discuss it, but maybe something you can just kind of throw into your thinking. If you if you try to put an attempt, and that would just be around the point of reviewers, and how those reviewers are selected I mean we could we have a list each week that everyone's signing up saying I was attending this meeting. I mean, perhaps there's a way that we can sort of pull randomly from the from the list of people who are attending to ask for review so that it's not always the same people might be might be one way to just sort of just get trigger the engagement from others. Thanks. Great. And so, I think in maybe the comment that led to this discussion was around like this pull request around enterprise VPN use cases, because it has been sitting here for a little while. It is. Yeah. But it hasn't actually been sitting there that long we've only discussed it once so far so it's not. It suddenly occurred to me that I didn't know what would make it move forward and maybe we should answer that question before we get to something we agree less clearly on, but yeah, I mean it's, it's an example of something that eventually wants that people can propose their own independent changes on it, rather than, again, fighting about it in its pull request so. Yeah. So, I don't know, do we want to dive into it now. Do people have people have a time to look at it. Are there comments about this specific pull request that you made now. And so for everyone that's not familiar with it in made it kind of like a first use case document and just wrote out about BGP on a customer network. I think this is an example of that type of pull request that we were mentioning. You know, almost should just get auto approved right. It's, it can be edited later. Yeah. And it's just a working document. Yeah. I mean, I've been obviously keeping an eye on the discussion and it's another example of what I mean, which is actually it's been in there a little longer than I thought it had it. It's got the comments on it are now 10 days old so it must have been in actually more than one week so my mistake on that, but I don't think there's a comment that anyone has put in there that desperately needs fixing at this point. There's been some useful discussion. I guess I've been arguing that it's good enough as it is. It's got a couple of approvals as well actually so it's not like it's getting any disagreement to speak of. I don't know what to do with the discussion that remains, you know, because there's been some useful points that came up in in that discussion but no particular actions proposed from them. There's maybe it's worth reviewing that to make sure there's not something we're missing but aside from that I mean it's not getting dissenting any meaningful form so what would makers want to commit it. And this Taylor I'm personally okay with the use cases moving forward. If quicker than say a best practice, which if we have a stamp of approval with effect RFPs as you pointed out and some of these things I think when we get to the poor or press process we can label you know charter would become a bigger deal. Like you said this one doesn't have descent so that's probably the biggest thing on any poor question we address all the items, and, and probably go through and if someone isn't available, like we waited on, I think, Robbie for one on a month or two ago there was stuff waiting for all that had comments that we want to be able to discuss in this call if if it's not getting addressed would be good. The only thing on this particular number 60 PR that I saw as you were scrolling by bill was, I think Victor is one or two up. No, let's see. Oh, no, it was right below victors. I just saw it again. Go down a little bit. Maybe it was yours bill. Yeah, on the was it the language terminology. Yeah, I added a section for that you'll notice there's a bunch of commits. Great. So, yeah. You're, you're, you're good then. Yeah, I'm happy. I think I don't know if maybe I forgot to approve it after that. Okay, sorry. That's my fault. Give it approval. And there was I saw a question mark and victors. Did that one get addressed. I put a comment on there, which he's read. So, I think he's read. Hang on, I need to check that. Yeah, I'm here. Yeah, so yeah, I can probably I can approve it because my point was regarding the multiplexers probably open another discussion where we can talk about what what it's going to be or how it looks like the Kubernetes based deployment, the human deployment could include those multiplexers. But my point is, yeah, probably my discussion point is not going to be discussed here. So I guess the use case is fine. Let me just approve it. Yeah, one thing I'm asking myself because I was writing a deployment use case out last night. Someone doesn't do his homework very early. I'm sorry about that. And that one, as I'm writing it is ending up with a bunch of reasoning in about we should do it this way. And I don't like that very much. It should describe the problem, not the solution. This one, I think multiplexers are a potential solution for the problem that it highlights. And that's the point you're making. And I don't know where those proposed solutions go because I think they're worth committing even if we don't accept them I don't think they have to turn into a best practice. But I because I think they want their discussion recording as we you know we do use multiplexes or we don't use multiplexes for these reasons, and there's no obvious place to put that stuff yet. So that might be a topic we want to talk about or add to the agenda. So let me do that. Yeah, thanks. So, unless there's any last raging to send some of this call it I think we can merge this pull request. Can you refresh. I think one of the things that you point out was make sure and approve if you've gone through the discussion use the PR approval process click do the review and click approve. At the top. Whenever you're interacting. And if you're adding comments about the that's specific to the content and a PR. It makes it easier to do the review process and add comments there because it comes through as part of your on that right with the reviewers it'll show that you've done a review, and you had some comments, or potentially a request for changes. And then it'll be a lot easier to then go back and and switch that to approved. Like, like Taylor did. Yeah, I think a lot of people have been doing that. And then, once it's done then Ian or whoever's on the pull request can mark those as approved or resolved and then we know it's completed it down. Yep. Any objectives to merging that one. Okay, too late now you're gonna have to make another pull request. So, yeah, I think. So thanks for, thanks to Ian for putting together a first use case. Getting that across the line so I'm looking forward to see how this kind of move forward. So, hopefully you can have more standards around how we can improve things. Going forwards. Okay. The next one is for people that missed it. There is the self nominations went out to the list on Friday. So, if you're looking to be either a co-chair or a tech lead. And then you're going to have to send a brief pitch which includes your name contact information seat you're interested in. And basically a supporting statement for either the co-chair or the tech lead. So, just reminder for anyone that's interested, please submit your self nomination to the mailing list. Do tech leads do need to be a tech lead to a specific aim or are we just looking for people in general. So, we do say like which part of the project you'd like to be a tech lead for. And so, I think that's, that's talking about like what part of the project would you be most interested in rather than just in general. I don't think that ties you to one specific thing but I think it'll help people understand what you're most interested in. Probably more part of the election part. So, if you're saying I'm good at all tech is not going to be as useful as I, I, I work on a lot of use cases and in this area and I'd really like to help drive the deployment use cases and or something like that. I'm familiar with Kubernetes specific networking and I want to help bridge the gap for the knowledge there or something. Okay, so we'll basically get the nominees and then we will sort of rather than it being quite as clear as it might be we'll try and work out what posts we want based on people's suggestions. The idea would be, do we have people that represent different parts of the technology and other areas that we're wanting so that we can help drive this sections and have representation to help. So, there's our overall making sure we're moving forward with the higher level topics and and people are getting their ideas across and whatever else and then that the tech leads are helping to make sure that we're going into enough details if we're saying, do we know enough on a certain area to start adopting this is a solid set of use cases so that we can break it down. Or here's the best practice have we covered enough in the areas. So to help help with all that before best practices put forward. Yeah, okay. I'm a little bit worried about this specificity of the tech leads right which part of the project. We don't really have a comprehensive list right we don't really have a scope of all the parts of this project and would be applied to each I kind of feel like at this stage at least is probably best that the tech leads would be untitled beyond the fact that the tech leads. Because we have people with a lot of different experiences in different realms it's, it's not like a nominee. Yeah. I'm wondering whether we tie this back to what we were talking about earlier with who is, who do we draw our approvers for for, you know, try and get things in within a handful of weeks. So, you might argue that what we've got here is you want a list of approvers from which we draw tech leads and that would work better. This seems over elaborated this point. I think, well, it means that we don't have to choose our tech leads yet because we don't know what our areas are but it we just basically put the approvers together which we actually do need a bit more urgently. So you're basically defining the role of a tech lead as a commit approver. As the prover of some variety. Yes. You know, we'd expect them to specialize and then they would lead in a certain area once we've worked out what those areas are but right now we just need them to sign up to be approvers that, you know, they are gatekeepers and they give their attention to the backlog. I feel uncomfortable even with the word gatekeeper here. But he is a group here and even people who don't have time maybe to become tech leads would also like to be involved in and have a say I think I think as a whole where gatekeepers. Yeah, I'm not suggesting that just because you don't have a title you don't have a say, I'm saying that, you know, if we want to move things forward then it has to be on somebody's head. So that's, that's the point of having a core group of one variety or another. If it's not going to serve a purpose then this is the wrong answer so so don't assume that I'm saying this is absolutely the right thing to do I'm asking, what could we do that's going to help. Bill maybe you can clarify more what you mean by by tech leads what role you think they'll serve. I think those are the people in the community that we look to that have the deep technical knowledge in specific like to dive into things and I think essentially how that's good time to our conversation from earlier is that like, you'd need at least like one approval from a tech lead and like a couple from like the community. And so like those are the people on the project that have like the time and expertise to dive into like is this like really a best practice or not. Well, it might help to pull up our either our governance charter on tech leads or go all the way back to the TSE or sick security or someone else where a lot of this is sourced. Here's a maybe more specific question that I asked last time. So the networking orchestration task force is that a topic. Should I apply myself to be a tech lead for that if there will be pull request for that area. I think that just when you're saying off the cuff. I'm just off the top of my head right now it's that sounds like an area that would be okay just saying I have experience in this case and network orchestration side and whatever else. And I think this would be a good area for us to make sure that we've covered and we can go into this like if you let's see the wording here. It's a little bit harder. I like the TSE it's a little bit more straightforward, but deep technical dive into an area. I'm going to put a link in the chat bill. So they that has the time and ability to perform deep technical dives on the project. So this is just a general sick level and you can see them all slight variations on on the different ones like sick security and stuff versus six but it's the same idea. So what you're saying towel in my mind could fit so we're saying orchestration is important. So what are some of the areas around that and this is an area that you want to put some focus in right now so that that seems legitimate concern. I wouldn't say it's the lead of the task force would probably be tech lead for network orchestration Kubernetes network orchestration. Right task force is an informal name. Well the task force I would just say that happens to be there but if the task force went away we would still care about network orchestration. So wherever it was done it would be an area that we would want to cover. Well, I feel like I have to think about this I am starting network orchestration specifically I kind of feel CNF working group is a temporary place for it. While we figure out better what we want to do so for me maybe committing to this role and responsibility here. And I'm thinking out loud but what do you guys think you think it would be important to have a tech lead dealing with orchestration in the group. This is a more clear word than simply orchestration. We said more before that there's the orchestration of the CNF and the way the CNF uses whatever the platform provides to it but the point about this is for this sort of thing you need to be working holistically you need to understand the consequences for the rest of this that isn't orchestration. Until we've kind of got through that process that's one of the reasons why I think it doesn't make sense just yet to break that out into a separate group. Because you know if it went off and did it own thing it would basically trample like a herd of elephants over all of the other bits of work that needs to be done to paint a picture of an ecosystem all together. If you so I mean it you know if I ask you how I start the CNF then obviously you will talk to me about how it needs to plum itself into the network and what implications that has. But what you don't necessarily get from that is there are 101 ways of doing that without respecting boundaries between CNFs you know I can just dive in and do dangerous things. And, and holistically, while that gets you past the orchestration problem it doesn't take account of the other areas that it might affect so that's the reason why I think this needs to be looked at with the viewpoint of actually I don't much care about orchestration I just care the whole system works before you start saying here's the orchestration task we need to go off and fix. Sure yeah it's a big category and as you know I, I very specifically want to focus on one specific area right the networking part. The orchestrating CNFs as a whole and network services is a huge component to and. But I think it's separate but but I think I tend to agree with you I think if we start right now delineating all the various topics that we should have a tech lead. That's basically defining the scope of what we're trying to achieve here it's equivalent. Okay, I would refer back to the notes when we had the discussion about the task force and breaking it down into smaller parts and what could be more directly applicable right now and they CNF working group. And then just think about the areas where you think we need to cover and dive into. So, what are areas that we're going to miss in this group if we don't take some time in it. I think those are in an area that you want to contribute then that would be where I would, you could put it forward and say, This is good. I'm already looking at it. I have a passion for this. And I'd like to help make sure that we go deeply enough and look at enough options that we're making good informed decisions. Okay, that that makes a lot of sense to me so I think we we shouldn't treat the tech leads as some sort of comprehensive. We're not picking a tech lead for everything necessary. It's just really people stepping up to lead specific issues. We're almost done and at top basis right. Yeah, and it could also absolutely so if you have a passion about something it's better to do that than say you're being assigned to this area that you don't like it all and don't think is important. And for sure that and the other part in this is, we may have multiple tech leads in an area that are, you may be researching on one topic someone else may say, I'm really want to cover like Victor's been mentioning the multi and other things if we're looking at current solutions and how does that go back, go back, so go we're going to dive into this well there's going to be overlap that's okay. And how does it work do we vote on the tech leads or the chair or. Yeah, the process. Yeah so I can go over to the voting PR now. This is how it's late. This is my first idea of how it could happen. Obviously, this is one idea and I want this to be something that the community is happy with this isn't saying this is how we're going to be voting so I see that there's a couple comments in here. So, the initial idea is to have organizational voting and so this came out of the flu and D project just so that people can have the background, each company organization has one vote. I feel like this leads to unbalanced representation. He's still here. Oh wait, did you ask something me. Yeah, no to Ian. Yeah. Yeah, and I will say the same what did you ask me I didn't catch that. Sorry, you're not in favor of the organizational voting. I am pointing out problems with it. I'm not sure I'm not in favor is quite where I go with that but I mean, I don't see if you want to do it then I don't think you've got enough detail. Right if I turn up and someone else I don't agree with turns up from Cisco who is your organization. Just to give you one example. Well don't we already have that. Isn't there already a voting member representative for for each organization. And how is that decided by your organization I mean there's a whole. My organization is 70,000 people. So that's why you get into trouble with this that's the problem is that who's the sponsor for your membership in CNCF. I get no one on the service provider side of the fence. So, yeah, is that Shane talking. Yes. Yeah, so you're saying the CNCF voting member. Right, I mean that's that's why you have a voting member is to avoid this issue. Well, the other thing I mean about this aside from that, and I see the logic here right it means you can't be overwhelmed by numbers from a given organization and I'm not saying that's a bad thing I think that's quite sensible. But conversely it seems to give a very peculiar power dynamic anybody use from a startup or an individual contributor who's not currently working for involved company suddenly has equivalent power of any large company who's you know lifeblood and day job is this so it becomes a bit weird. And again, this is unfortunately it's criticism without an answer I actually don't have an answer I'm just saying why these are the problems we're going to face with it how we're going to deal with them if they come up. Yeah, absolutely. I mean, that's the problem with systems is there's always flaws in them. So, if you have a different proposal and more than welcome to hear to listen to it. Yeah, I need, I guess we need another proposal then and then we can, well, well the the the other proposal I would have is you get rid of the you ignore the organization side of things and instead you to deal with people individually. And you measure them by what they're doing that they're doing something that they're contributing. Where can make discussions into this group and yeah, okay. Then you allow one or again then you have the problem of, you know, yep, yep, let's go or red hat or whoever, you know, red had several people who are are contributing here should we be allowed to vote more than once. If you're doing work I would argue yes. I mean it sounds weird because I'm on the midnight. I'm on the I'm on the losing side here but I mean, right because that my point is that gives me the exact opposite of the small company issue that you were referring to right is that a large company could come in with 10 people into a single working group, and essentially take over. Yeah, they just say okay this is how much it'll cost us. Exactly. I was trying to say that Taylor without a I'm going to go ahead and put it forward. Thanks though. Yeah. Okay, so one thing that we're going to have to do. This isn't going to be only freeform what we want. We want to be aligned with the TFC and CFTC and there are rules about that. So if we kept going forward there's some type of representation and voting already aligned so maybe that's something that we could go back to. I know on unlike, if this was a project it's even more clear where you can't make it into sandbox and and on from there unless you have a certain amount of representation split between works. There's also a prior example looking at groups like Apache who they say for people who are voting members or maintainers, and you can have no more than a certain percentage of the overall project so it doesn't. So I think it's important to minimize penalizing people companies who want to get heavily involved, but at the same time, also provides a limit on actual number of votes that they can provide and the number I think is somewhere around 30. I think around 30%, but double check and see what's what they do and that might also be another. Yeah, I think this comes back to democracy is the worst form of government, except for all of the other. So there is, there is no exact voting system that will give us all the, that will unearth all the intentions that we that we want as a community. Every single system has its problem so this actually comes down to is which one minimizes as much as possible some of the outliers, all at the same time, ensuring legitimacy of the of the group. And it's a hard balance. You could simply go one vote for organization for the working group. So you take away the voting member issue and active members in the working group, each or gets one vote. Yeah, that is possible as well but then the question that is actually I get the same vote as as all of redhead and all of Cisco and they if they provide multiple people who contribute a lot as well so we do want to be careful with that as well. Yeah. So if anybody has a better idea of how we should do this or they think they have an idea of how we can make this more fair to the community or create a better democracy. I would be very happy to hear it. Yeah. Well probably it's something related but do we have a number of position for this or like how many techniques are going to consider for this. Yep. So, right now, there's not a limit on the number of check tech leads. This is similar on if you go look at the TSC general rules or you go look at any of the other SIGs or working groups, tech leads are open. If people have an area that they're passionate about and they think needs to be researched and step forward. Yeah. And I guess to help make sure someone is there to help go go deep down into an important area and you can rally around it and chairs are the like talk level moderator administrator to move the whole group forward. Yeah, I guess with this model it's what I was trying to encourage is more people to get involved as tech leads. And so, leave it out as open and possible and not not make it lower. I'm not, I guess maybe not lower the bar is the right word but encourage participation from people as tech leads. So there's not a limit on that and it's a not a really high requirement so they just need to get 60% of the votes cast to be elected. So at this point are we really do we really want to elect the tech leads or just have people sign up and we see we have too many in one domain then maybe then we need to elect but it sounds like we may not have enough tech leads at the moment so this conversation seems to be a bit moved. So we may have the exact opposite problem of not having enough people and then this type of conversation could be possibly postponed. And I think the more important question is, is to make sure that we scope down the powers properly like we we don't want these people to be king makers we want them to be facilitators and this this also means that we want that they, not be the, in a role to basically squash things that are that are not aligned with their company and not that I expect people here to do that. But we have to take this type of things into consideration for the long term health of the project so it becomes some, I think that there is something that we have to be a little bit careful with in terms of how much power we we give these groups but also make sure that the group has the correct set of antibodies that if we need to move on we need to make a decision that something is been as as that there's a really hard decision has to be made that I got it. So we want to scope this thing, this particular, this particular path out like how do we want to make sure that that we can at least get some forward momentum without without giving one group the power to squash squash others. I think that's actually might come back to our earlier discussion around what are the rules for approving and merging pull requests. Once we have that it'll become more clear what each of the roles actually is able to do. Okay, I know we're running out of time so if people couldn't like add more comments or somebody has another idea of how we should do elections, please add this let's come back to this next week. And maybe we can do the some of the discussion asynchronously. So next, I don't think is welcome call. No, so I haven't heard all message him about the use case templates. So we have an update. Also, is anybody interested in helping creating a PR to define the different actors that will be speaking to know this one's been here. This issue has been open for a while just so I just want to check back in. Okay. And then Ian, do you want to, this is the kind of the discussion from earlier. I guess, maybe the discussion is, it's not a use case it's not a best practice so where does it fall exactly. It's, yeah, the way I see this is we have use cases that say what we want people to be able to do. We have best practices that say, this is our personal preference or you know industry wide recognition recommendation for how it should be done, which might well be simply you do this and it will cost you less to do. Or I in many of these areas is obviously going to be you do it this way because we need everybody to do it the same way in order to get the most benefit. But there's the bit in the middle, which is, I could do it this way, is that a good idea, can we write down our thoughts on this, you know, a design requirements design implementation in some regards. So, you know, per that conversation earlier about multis right so here are my use cases that describe how I'd like to use networking here's how multis measures up to that. Maybe it's perfect, maybe it's imperfect, maybe it needs a ton of changes, maybe it's not the only thing you need. Where do I put that down so that it's on record. We already have a docs directory, and I think we could put any type of documentation that helps spring context. We can put it into there, if nothing else. If it's, if you think there's additional context, it's more specific to a use case but it isn't required for the use case, you could put it in a the use case folder, like within within the sub folder of your use case in the in the use case folder. Yeah, I, I, yeah, okay. And where you want to get in and talk about like, here's a here's a implementation that I'm wanting to talk about and maybe examine how it would work. Then I would say boot those completely out and my first suggestion would be the CNF test bed, which was, it was designed for that so you could have three or four implementations of an idea, using different multiplexers, or using transport protocols like we had some using me my F and different kernel interfaces and flat network and bridge networks. They're all the same top level idea of a use case but implemented differently. And those are, we have it broken up like is this kind of the workload infrastructure pieces or the main part was going into the use case folder there. So it was designed for that. And then if we get down to a very, very specific best practice test, that's what the test suite, the CNF test suite is for, but I would say right now those would be the two areas for code. And if you click on the use case bill. Go and like that top one, three C two in three chains two nodes, I think this one yet so Michael from Intel. This is one that he helped build and you have the communication what is this test case that was built, you know around the use case idea was the actual implementation that was used talking about a more. This was a more specific area, not a big, big use case but in a very small set and what what was the test case. And there was other test cases that implemented this in different ways. And you can see it talks all about it. How was it done. How do you actually test it. It used in a fee bench to run and do the, the packet generation. You happen to be able to redeploy this yourself using the code I mean that was I do with CNF test bed, but we have other ideas that came in here that we're on like the Linux Foundation sees that lab, which were FDF the FDIO sees it so there there's actual use cases in here that were documented. I think the IP sec one would be one that was on both sides. One, there you go. Yeah, Michael helped with this and also I think Peter and some other people from if anyone's there with some of the people on the FDIC said that was tested on both places. I think the answer is, we will need these. There is no point in giving them a place of their own just yet. They might get one in the future it doesn't matter terribly much if they do or they don't. And we can attach them either to the user stories in the user story directory, or we can attach them in general in the docs to the docs directory. And if we decide to move them around in the future we'll just do a bit of a rearrangement, and we'll learn more by doing than worrying about it right now. Okay, we've about two minutes left. Is there anything anyone else wants to bring up before we close for today. Okay, thanks everyone for joining today. Thanks. Thanks. Bye. Bye.