 Thanks everyone for joining. I'll put the link to the meeting minutes in the chat. We'll get started a little bit after the hour here. Thanks for joining today. Hi, thanks for joining. We'll get started at about five after. The zoom chat should have a link to the meeting notes. You can add your name to the attendees list and any agenda items. Okay, it's five after. I think you can probably get started. So once again, in case you're just joining, I dropped the link to the meeting minutes in the chat. Feel free to add your name. This is the weekly meeting of the CNF working group. We meet every Monday at 1600 UTC. Before we jump in, is there anything that anyone would like to add to the agenda? Hearing nothing, we can jump in. So the first thing I wanted to talk about is the voting. So thanks everybody that's participating. Does anybody feel, first of all, did anybody not receive a ballot and think that they should have? And second question, will anybody not be able to vote by tomorrow night and would need an extension on the deadline for voting? Okay. Hey, Bill, I put the time zone next to midnight just so people are tracking it for whatever reason, they're cutting it to the last minute. Okay. I'm in my. Yeah, thanks. Yeah. And then the other thing is so once we have the coaches elected, we can start to tech lead elections after that. Does anybody have any questions about the voting process so far? Anything that I can help them with? Okay. If you do, please feel free to reach out to me on the CNCF slacks. Super happy to help. Just trying to make it as easy and as transparent as possible for everyone. Okay. Second one. We have a look from Ericsson. And he previously presented. You know, which is, I think the external network orchestrator at the tug meeting. And now he's interested in putting together a use case for Kubernetes network orchestration. So I'll give it to him to just give kind of like a quick update. Let's say maybe like three to five minutes about what he's doing because he wants to put together a PR and is looking for people to help out. So over to you. Good morning. Good afternoon. Good evening to all. Yeah. So we presented, you know, that is the external network operator in the last telecom user group. Many of you might have joined that meeting as well and have gone through the proposal and the idea which we are kind of trying to float in this community. And I had a follow up discussion with over the email with Bill and talk about how we can take it further. And one of the suggestions which I got based to write a proposal in as in like a use case. There is a template which is available in the CNS working group repo. And we just followed the same notations and moment later and been writing the proposal. It will be available in couple of days one or two in in in the form of PR in the repo. But so if if anyone would be interested to be as part of reviewer please let me know. Maybe over the slack or just in this meeting I can add. I'll be happy to add them as a reviewer. And yeah, that's it. I guess from my side. Cool. Thank you. So looking forward to that PR and use case coming out. So if anybody wants to be added as reviewer to the PR, please add you. Get help handle to the. Meeting notes and I can add you there. So. Any questions about that or we can keep moving on. And thank you for the people that are volunteering to be reviewers for the PR. Yep. Thanks a lot. Yeah. Looking forward to that. Okay. Next one is the clarifying the chairs for lots of responsibility. Taylor, did you say something? Yeah, I was just going to ask if. I think that one's going to be a pretty big. Use case and discussion. If. A discussion item could be added to the. Get help repo. That links to the PR so that we can. Continue that conversation. There's been a lot of stuff on the email and, and other slack channels. And I think it'd be good if we capture more than what, what the PR is the rest of the discussions. Could you create a new discussion on. Get hub for this. Use case that you're going to do a PR for. Sure. Sure. I can do that. Yeah. That would be a good option. Yeah. Thanks. Okay. So the next one is clarifying the chairs responsibilities. So this is a PR. From Taylor. Essentially. So that it kind of clarifies that the chairs are for facilitating kind of the groups interactions. And we've quite a few approvals here. I just wanted to check in this meeting. Any last comments with this PR. Otherwise we can merge it. Okay. Cool. So thanks Taylor for that PR. The next one is. Adding the glossary to the contributing. This is my. Or this is, this is Lucina's pull request. So thanks for updating this. This is. Adding. Essentially just a link to this and the contributing documents that as people combine or wondering where they contribute, they can add to the glossary. So I think this is pretty straightforward. And unless there's anything else, I'm quite fine with merging this one too. Okay. So thanks Lucina for that. The next one is Ian on the call today. I don't see him, but. In case people had missed this one, this is about the. Rules. This is about how do we do. How do we see what. Companies are associated with each other. This is out of the discussion about the voting rules too. We have two approvals so far. I guess. Does anybody else want to like look at this. Or be added to the reviewers. I think maybe we wait another week. Until a couple more people had time to look at it. So does anybody want to be added as a reviewer? I can just do this right now. Can you add my name there? Yeah, that's a victory. Yep. Thank you. Okay. Cool. Thanks. Anyone else. Okay. Cool. I think much of this is clarifying. Cleaning up more than anything and moving a lot of it into one shared area. Yeah. The next pull request is around. I'm a timeline for the interested parties just for legal departments that want. To be more clear and people can give people deadlines. This is essentially a. One line pull request. Actually don't know. Is this going to go. Because Taylor, you pulled out the interested parties into a separate. Into a separate file. Will this go into that file? That would make sense to me. What. That would make sense that it should go over. Of course, I think with the merge, this would probably say. Something like go. Look at the file and then interested party. I don't know why the subheader hasn't updated. Yeah. Okay. This is just saying that the interest is parties can be added at any time. I think what needs to be added is. To the sentence can be added at any time to the list and you point to the list. But the, but the statement is still belongs here. I think it's one. Sentence up if you go back to that conflict. Yeah. Okay. Above each organization. Yeah, right where it says each organization. Yeah, this is where the interested parties is. And then I guess it would go. If you wanted to put it maybe in. In that paragraph for any contributors. But that is about the, that is about the elections. It is not about interested parties. I think what is it. I think you need a section of interested parties before you have a section on elections. And it should say that you can add interested parties at any time or whatever timeframe you want to specify. And where that list is. This is in the election section. This only says each organization shall have one vote. That's what it is. Right. Yeah, but the definition of what is an interested party and how you modify it. Needs a separate section by itself. Just a thought. Right now we've, we've removed that what are interested parties and everything. And I, we've already said that we would like to. Look at changing the whole voting as well as representation. So I don't want to do a whole lot of work on this. I would say either. Remove it and just kill this PR for now or do something minimal like what you're doing. Bill, you can put it in or. Yeah, I get what you're saying. Pankaj, would you be okay if I. That's fine. That's fine. Yeah. Yeah, add it as is. And then add an issue that the. The election process should be separated out. Okay. So. There's still a conflict in here. Did I do this the wrong way? I'll add a note that we should. File. So we'll create an issue for that. Cool. I saw that you commented here about this. Yeah. Really, it's not. I'm just saying. My opinion and other people no doubt have other opinions about what a use case is. It shouldn't say. A use case should not say, you know, is great. You know, does this, you know, is marvelous. A use case should say here is an abstract problem I have to solve so that you can show that you know is great by solving a problem in a separate document. Sure. I took a note of your comment in this lecture and then definitely will put along the lines. Yes. That's fine. I mean, I guess I've got my skepticism is about whether he knows right, but here's your chance to prove that you, you know, demonstrate it to me. But I don't want you to perfectly. If you write ENO is a thing that we will be using, then you don't really get the chance to prove how great it is. That's the thing I want to see. Makes sense. Yeah. Okay. I don't know if you heard Ian, but this, that, what you're talking about is one example of why we need a, a GitHub discussion so that we can add more comments and just the PR. Yeah. I mean, I would take either, but I totally sympathize with what you're saying. I'm not going to say don't do it because you're doing it in, in administrative slightly the wrong way. But, you know, it just might mean that the PR doesn't get accepted, but yeah, either way. Well, on this topic though, right? Like the use case should be network orchestration and should be like completely agnostic than a best practice using ENO would be a proposal, right? Like the whole discussion versus PR system that like, what use case are we trying to fix? That's a PR. How are we going to fix it? That's another PR. Yep. That's where I was going with that. Yeah. Speaking of that, we do have one use case on the table right now. This is from a book. So this was about the, what happens when you need to manage the infrastructure life in the city, and what happens to the city enough during that. Jeffrey, I saw that, that he comments nine minutes ago, but we're also looking for more people to add some use to this. So is anybody else interested in reviewing this? And I think the process of like how this gets like approved and managed through, I think we'll become more clear once we have some tech leads that will kind of like help shepherd this into the reviewer list. Yes. And I was planning on reviewing it as well. If you add me as a reviewer, I suppose that's a reminder. What do we think the best practice would look like when it comes to the end of this? Sorry. I think this is a use case and that would spawn multiple best practices personally. And so yeah, I did a couple of last minutes. There was a few that I forgot to hit submit my review. So that's my bad bill, but I did a pretty sizable commit. Like I talked to book and just did some like basic, like editing and stuff. But I think there's a lot to unpack in this first one that we'll put up. I mean, there's stuff around testing. I think there's best practices we should write around testing. There's best practices around like resiliency that could come from this based on like some of the things that book laid out. There's even like best practices. And I don't think we would necessarily cover this, but just like the interface between an app team versus an infrastructure team. Like we talked, I know you and you and I have had a lot of conversations around like what SLAs look like, what is like the mutual relationship between people building the app, people hosting the app, people running the app. And so I mean, I don't know if that was books intention, but he put quite a lot into this first use case. And so I think that once again, to the earlier comment about, you know, it's like a use case, you know, is in itself just something that we're doing. And then one or multiple best practices could potentially, you know, try to address said use case and invokes instance. I think it would take like almost a baker's dozen to unpack everything. Which is fine. I'm good with that. I mean, it seems to me that one of the more important things we get out of this is this is what you should expect the platform to promise you. Or, you know, this is what the platform should promise, you know, however you want to, whichever lens you want to view that in. So, which would be really useful. I mean, you know, someone to actually declare the platform is this reliable and no more would be very, very helpful. Sure. And in reverse though, some of the stuff that book puts in there and he's obviously coming from the bias of being someone who, you know, provides a platform is these are the types of things that we need to do. And we're expecting a CNF to be able to cope with them. Yeah. Sorry. I'm just trying to write these down in the background. So that we can get them. So I'll add these after the meeting because I don't think people want to see me do that. So thanks for the people that have raised their hand to review that. Definitely super helpful. I don't know if people have more comments about this use case today or want to have like a little, we can also think it might be helpful to have some more people look through it and generate some more discussion before we dive more deeply into it. Cool. Next one is creating a pull request template. This is an issue from. We've seen something we might want to consider to help out people that want to contribute. And so the type of PR, the description, the motivation contacts, and I think we can actually probably use like some of our, some of our templates to. So if anybody wants to take a first habit, creating like a pull request template, looking for volunteers. If not, I'm actually also interested in this too. So. I'll sign myself unless anybody else is dying to do this. Okay. I can help as well. Okay. Thanks. I'll, I'll run something by you later this week. And say have something. Okay. The next one. Ian, I hope you don't mind. I numbered your BGP use case. You're a terrible person. I didn't break anything. That's fine. I have no problem. Maybe if someone wants to just like look through it and make sure I didn't mess it up. That'd be good. It should be pretty straightforward, but that's when all the accidents happen. Yeah. The next one is so Taylor started out. He broke all the. The checks that we had, but now fortunately they're. Well, they're not green. So he won't be super happy, but he has a draft PR. Cause we've kind of, we originally talked about conformance. Now we're switching to best practices. So if people want to like help out with this, feel free to jump into this too. Taylor, I can't remember how it does and you'll have to read it. I don't know if you can read it, but it's a link check to check the valid links. And in a, in drafts, it may well be that you intentionally have broken links in particular. Sorry. What am I talking templates? You might well have broken links intentionally. You don't want them to work. I think you can put exceptions in for them by putting a comment in the markdown, but you would have to go read things. I'm afraid. Yeah. Yeah. I'm going to go through some of the files. Oh yeah, that would do it. Yeah. Yeah. If anybody wants to help out with this draft PR, I'm sure Taylor would welcome the help too. Yeah, for sure. I'm trying to go through all of them. So if. If we, as I'm going through, I'm basically clicking on that branch, that rename conformance definitions branch, and then I'm going to click on that branch. And then I'm going to click on that branch. To fix links. To fix links. Like you're saying, Ian. Some of it's going to be. Pointing to existing new docs. And some of it is going to require renaming stuff. Like the. The actual best practice name, which is. We have conformance definition proposal. So that'll rename that. Folder and other things. So. So that'll be the basis of. Wording that's still using the other language. So yeah, anyone that wants to help. I appreciate it. So does this mean that CNF conformance? The repo is now CNF best practice. No, so those are two separate repos. So if I go to CNF. Conformance. This is actually a separate repo. I didn't realize that, but if the. Is the test suite still a conformance test suite? Or is it a best practice? Is it conformance against best practices? I guess. Yeah, exactly. Okay. So I wasn't bringing it up on this. There are plans to. Split up. If it's scroll, can you scroll down, Bill? Yep. I'm going to scroll down to the read me until we see the actual. Content. No, you can keep scrolling. There we go. You're right. So something that's confusing on this is. We're talking about the overall. High level conformance program. Or the efforts to. Have potential. I guess we'd say best practices, but the overall program and efforts. And then we have the actual software, the test suite. Which right now is focused on best practices and giving feedback. There's no certification. So we're planning on splitting these up. And that would be similar to. The Kubernetes conformance. There's a repo and a whole conformance program. That's completely. Autonomous and runs. And then we have the actual software, the test suite. Which right now is focused on best practices and giving feedback. And then we have the actual. Autonomous and runs. Separately as far as like the governance and decisions around that. From the test suite. So if you're, if you're looking at the Kubernetes. E to E test. The decisions on what's, you know, covered and stuff in that. That's done completely separate from. The conformance, which is a selection of the test. And so we'll do the same thing. And it'll be a lot more clear. The CNF working group. Our focus right now is what are all those best practices. That could be tested. The test suite could test them. And then a conformance program. If we move forward with all of that. Would be saying, here's a way to. Say that, you know, you're, you're following all these best practices. So we'd all come together. Does that make sense? Cool. Thanks for that Taylor. And then there's a couple formatting issues from Ian. I guess. I know you created the issues. I guess. Do you know of any solutions or these. Like things that we should just take note of and. Add to our contributing docs. Well, to be honest, it's got to go in the contributing docs before we put a check in. And the moment that actually gets done. I'm a bit ambivalent about that line length one, to be honest. The editor I'm using, and I'm guessing that it's, you know, visual studio code doesn't seem to like the idea of auto wordwrapping things. It thinks that you should leave lines long and then it will wordwrap things, but it makes the diffs absolutely horrible if you do that. I imagine a line length check is, you know, a hundred lines of Python to actually make the check happen. So I guess we could write one in short order. I would prefer to make sure that it's not just my opinion on the subject before I actually go out and do that. Because otherwise I will be hated for making everybody wordwrap their markdown because it forever fails tests as opposed to everybody signing up to yes, I will do 80 character markdown because I like your ideas. I guess question is why 80? Is it an arbitrary number? Yeah, it was really, it's just a number that basically allows individual line diffs to work. Because that doesn't work right now. And again, you're welcome to tell me it's a really bad idea and you should never consider it again. I don't think it's a bad idea. I just think 80 is a bit short. But you know, my green screen console only has 80 characters across. I'm not going to comment on that. If we were just writing and sharing stuff, I'm all for doing it on an old green screen and limiting it. At this point, though, for everyone else, I would say let the technology do the wrapping. Well, frankly, it's, it can sit there. You can pass comment on it. Think of it as a very low level issue that we don't have to give any serious worry to. If it basically links around for another month and nobody really feels that it's compelling, then we'll just close it and be done. Okay. Maybe we should find an example of a short and the long line diff so that we can see what the readability looks like in GitHub, because I think this is going to come down to the long line diff. The long line diff. The long line diff. The long line diff. The long line diff. GitHub show long lines. You have to scroll to the right because it's because of GitHub's lack of auto wrapping or does it allow you to show that in a really nice way. And then we, it's becomes a non issue at that point for, for most of the users, though, it's a non issue. It's a non issue. It's a non issue. That'll be a minority of users who can build their own tools to auto wrap it. Try to work on that. Okay. If you're really passionate about this comment on the issue. I don't think we need to. Take a ton of time to discuss this. Yeah, this is not our day job. This is just a nice to have that would make our reviews a bit easier. Cool. Thanks, Ian. And yeah, Jeff, I also added that to the issue. So it's recorded. The other thing is the web links and dock point to the GitHub location. This is what you want things to be more like relative. Yeah, it just needs relative, relative links. Otherwise what's going to happen here is any branch that you create will link back to the, the trunk documentation, the master documentation. So nobody will be able to review it as process markdown for one. Forks repose. Yeah, it just needs dealing with, but basically our links want to be relative. And I don't think the link checker is clever enough to work that one out. Okay. So maybe this should be added to the style guide. But it's also, this is a really good first issue. Anybody wants to tackle that one. Another one just related to that is also updating from master to main from like the GitHub thing. I guess I haven't looked at, I haven't read into the documentation, but I'll probably do that later this week. Or if anybody else wants to or has experience, I'd love to hear kind of their experience like switching other repose over. What are we trying to do here? Switch the default branch from master to main. Why? I'm, I'm up for taking that on. It's pretty straightforward. And we're trying to do that on all the other ones. Like all the other repose. Do you have a link in there to the. Yeah. CNCF or is it, I don't know if it's CNCF or LF naming. No, I can add that too. I think they have something in there. Yeah, but this is the documentation from GitHub. Yeah. Okay. Thanks, Taylor. Getting rid of language that's rooted. And. Wherever problematic because of its background. So master would be one of them. And that's happened, I think, multiple years ago for. Yeah. It just hadn't. Gone across all of CNCF. Yeah. Okay. Thanks, Taylor. Project. Thank you. Recently opened a discussion. 15 minutes ago. Would you like to discuss? Sure. So the basic idea is to propose a bump in the wire. Actually, I should say a hello world use case. This is something that I had spoken about a month ago or so here. But the idea is basically to put together a use case where we have an advanced use case, which Ian gave an advanced use case that we can focus on, but also to have a very simple use case that we can ask the question that as we're solving problems for the advanced use cases, are we over complicating best practices for a simple use case. And a bump in the wire firewall is. A possible easy use case we can focus on that. That basically serves a specific, that specific role and the idea was to basically have it set up as a, as a transparent firewall. There's other transparent things that we could swap firewall with as well. But the idea of a firewall was understandable enough that people, most people who are non-net workers that they're coming from an enterprise background or similar. They understand what a firewall is. They may not understand other forms of, of packet treatments that are, that are there. And the transparent portion on this is descriptive of. A scenario where it doesn't modify the packets. If it doesn't need to, but simultaneously, the more important part is that it's, it's a, is that it's not a rattable thing. It's not, you're not able to address the firewall in the middle of the user plane, despite the fact it's still getting applied to the, to the user plane itself. So in short, that's the, that's the recommendation is to have something in, in bad respect. Other areas where this could be useful as well as when you are looking at like whole two use cases. Then the, in L two, you can put in a bump in the wire, ARP responder, or when you're looking in some security products, you may decide to put something other than firewalls, such as an intrusion detection system, or some form of a data loss prevention. So in short, that's what, that's what this particular thing try, tries to represent is that bump in the wire firewall that lives within Kubernetes. Cool. Any questions, comments, thoughts. So I think this one will be interesting and tricky, depending on like how we describe the firewall and what the firewall best practices are. I can tell you like this thing right here is something where non CNF stuff, but just typical Kubernetes things. If you look at books use case around being able to provision new nodes and, you know, paint nodes, migrate pods, all this kind of stuff, do upgrades, things like blue, green and whatnot become really tricky. When you have legacy, like firewalls as a bump in the wire, depending on how you pinhole. So, you know, like if you don't like, she's got a firewall controller there. So assuming you're doing everything programmatically, then maybe it's part of like a bigger workflow, but I think this one's use, this use case is interesting because it sounds very, very simple, but it causes heartache depending on how you provision things. And it's like things that are uniquely complicated to Kubernetes versus how I would do things in a legacy, you know, way. So that's my comment. I think that we say this is, this is simple, but like you'd be amazed when you try to spin up 15 new nodes in a new subnet. And if your firewall team is not part of the cloud team, what does that look like to get those new prefixes added to the ACL? Like, it can be on the interesting. Yeah, I said simple, but I didn't say easy. So I know this is a particularly tricky use case for, for Kubernetes. And if you're, if everything is done through, through CNI, you're just following CNI policy, then you're in good shape. But the moment you try doing something that's outside of CNI policy, then that's, that's where these things get really, really tricky. And the Kubernetes form of networking doesn't lend itself well to this form of transparent, of this transparent communication. So, so I thought this was a pattern that it wasn't just going to be, oh yeah, we supported already hit the checkbox on everywhere. We're good. But there's some, there's some, there's definitely a gap here in terms of how do you achieve this within Kubernetes? But I think it's also something that we need to work out how to solve properly, because we're going to see this pattern appear over and over and over again. And the risk is when we see other things that are created in CMS, besides bumping the wire firewall, we're going to see this thing reinvented over and over again. So establishing a clean set of patterns and working out when they do or do not apply around this use case, I think would be, would be valuable. Yeah, we should probably throw another use case or two at that service addresses or another one that crop up. So I've got a service. I have multiple up links, the up links have individually interface addresses and so on. Basically, it's the same. I've got more than one root on a link kind of thing that I think you're talking about. Yeah, I agree. It's a perfectly sensible thing. Yeah, this, and this one doesn't cover additional advances on top of that. Like what do I do about load balancing? What do I do about if I want to chain more than one thing? So there's still other complexities on there, but I figure we start something that's, that's simple and then we can work up the chain of complexity over time. But definitely add it to either the document. I've moved it to a suggest note so we can track the, the changes. But if you add it to the document or you add it to the discussion that's linked to this thing to it, then I'll make sure that gets added to the document. And once we're happy with where the document is at, then I'm happy to convert it to Markdown and submit it as a, as a part of the repository. Yeah, one last piece on this too. This kind of will pull together several points. One is the concept that a CNF doesn't necessarily need to be a data plane intensive thing. So I can tell you like coming from like the service provider bias. We run things like network orchestrators and Kubernetes that have really weird and picky egress requirements right. Like they need to have reached a certain parts of our network. So a best practice could just be egress gateways or, you know, something like that. Like I think this is interesting because I think multiple best practices, which is another point we were discussing earlier, could spawn from this depending on the type of workload. So this comes back to the glossary. Hey, we need to define what a CNF is. So that way we can talk about how a best practice, like actually applies to it and then be, I don't think a CNF is just what we typically want to like focus on, which is like some, you know, data plane accelerated, really cool high performance network function and just simple things like, I have a network function that has layer three requirements, which means that it actually cares about the node IP addresses its source. So then if I have this transparent firewall in the way, how do I do basic cloud native operations? When layer three is constantly biting me in the butt. Yeah. That makes sense as well. And this, this also becomes very relevant when you started looking at some of the, the 5g use cases. When you look at the next generation of packet core that, that's they're trying to do create. And as we start to look at some of these things, like some of the components around authentication and authorization are decomposed into multiple parts. And some of them are just, this is a database that has state. And this is, this is something that'll perform some authentication action for you. And then the result of those programs, a, a data plane somewhere. And so over, over time, like that, that thing can look like a bump in the wire firewall to whatever it is. It turns out to be a tunneling protocol or something similar, but to the, but it still needs to be addressable in a way to the rest of the infrastructure so that you can still get that control and, and manipulation. And this is one of the reasons I try to avoid the term. CNF in the discussion. Was to avoid the argument about what is a CNF versus what isn't, but instead to focus on the heart of the matter of what's trying to be, what's trying to be sold. And one of the things we've done in the network service mesh community is we stayed away from the term, even though we use the term CNF, but when we start talking about it in a concrete area, we talk about things like network services, something that provides a network service or an end point, something that you actually connect to. And multiple end points can, can provide a network service that you can then scale up those end points up or down, but they're all part of the same umbrella of network service, whatever you're trying to connect to. So, so I tried to use something that along those lines as opposed to something that's a little bit more, I don't want to use the term ambiguous because it's not really ambiguous, but it's something that there hasn't been a clear definition around as to where do we want to draw the line between an application or, or a component. And then Victor just commented. I suggest we start using the voting feature of the GitHub discussions to protect prioritize items like this. So, I'll talk about that too. Cool. So thanks for kicking off that conversation Frederick. You're great to have other people jump into. I think that's all we have on the agenda for today. Is there anything anyone else would like to bring up or discuss before we close for today? Well, the only thing that I was just thinking about is like the numbering of the use cases. Did you think that could be a good idea to keep numbers? My concern is like, I don't know if eventually we can confuse like using numbers to on on the use cases can reflect priorities or confuse those things. I mean, the other thing is like which number you can give to the use case when you have to multiple use cases at the same time, like the merge, the merge use, the merge number or like the number that you use when you submitted or things like that. I think eventually we can avoid using numbers could be we better, I don't know. On this point, Victor, we did say in the past that best practices would need to tie to use cases. I think it's safe to think that certain best practices could potentially tie to multiple use cases too. So some type of metadata is probably warranted so that way we can have some mapping and maybe like use cases and best practices get updated with like a little table at the bottom that say what they apply to you. I don't know that might be over complicating it. But the big thing is is like, you know, I look at a use case and I'm like, okay, how do I solve this? What is the metadata that leads me to the best practices that would help me overcome the challenges, especially if there's not a singular best practice, but maybe there's multiple ways that the group at large teams is valid, you know, means of solving it. We probably want to plan for that. Okay. So do you think that using like a number we can group or at least? I don't know if that's the right way or not. I just know that metadata so that we can track what goes to what is at some point going to be relevant. The longer we go without it, the harder it'll be if, you know, we have lots and lots of stuff that we didn't start saying, how do we map all this together? Yeah, I guess we originally started giving numbers because it's something a lot of like in Kubernetes, the caps are all numbered to just, yeah, to make it easier to keep track of. And in terms of like merging them, I mean, if we're having like hundreds at once, it might be a problem. I think at the scale we're at right now, we can still kind of keep track of the numbers. I mean, if Kubernetes can keep track of the numbers for a couple of weeks or so, I think we could probably come to if we find that's a problem. Maybe rethink what we're doing. Yeah, I don't think it'll be an issue with merging, Bill. I think it's just, you know, let's say I have four different ways to solve network orchestration. Like how do I know which best practices I could go and look at to figure out like the one that I think that suits my use, like my flavor of the use case, like, we're going to have to worry about merging or this and that. It's more just, you know, how are we going to map use cases to best practices? And they have a file name, file names that you need. Robbie had started on that. Jeff, Robbie had started on that with the document around best practices. And I think when it gets to a point where we're saying someone is interested in finding best practices, they can go maybe the, what the routes you're saying. They can just look through, but hopefully we have hundreds. And that may be too much. So they may go, let me go into the document and I want to go down to a category. And then you say, oh, there's two options listed or four options. To solve this problem. Let me read on all of those. And then I'll pick the one that fits me the best. So we can organize it. I think as they come into place. I don't know if this is it. Yeah. Yeah, that's fine. So, yeah, I guess that's a good point. Like, how do we want to map it kind of to this? So if you have any ideas, it'd be great to hear them. Or a better way of doing it. And with the, the idea with the best practices, every best practice should link back to a use case. So if you're going in that way, but you could also do the other way, we could, we could always update a use case and reference best practices that have been adopted. So we, we can point to those and do a PR against an existing use case, maybe make a section on those. And, and point to one or more best practices. Yeah, I don't think we have to solve it right this second. I'm just saying at some point, like books, books PR, like I said, is going to spawn multiple best practices, I think. So then making sure that there's some type of mapping to all the ones that come around platform life cycle management, et cetera. And yeah, even if it's just retroactively, like there's just a list and you just put the links in, I don't know, or file names to Ian's point. It doesn't really matter to me. I'm just saying. Assume you're not someone who regularly frequencies calls or works and get with us and you come in. And then you're going to be able to do that. Because you want to figure out how to do something. Right? That should be like our target audience that we're really trying to make this consumable for. I, I, I agree. And, and maybe it's going to be multiple target audiences. Just someone that's. Actively doing very specific development may come in and go, I'm looking for this one. I'm looking for this one type of thing. They make a right into the best practice list. And then someone else may say. Here, what's the closest use case? So I think we need. You know, the big specific list. As well as the higher level. And maybe even another one would be. If you have. A list of. Use cases that we don't have, but. Are kind of related because some of the topics, including what. Frederick was talking about for the. The inline firewall. There can be more complex ones. So if someone's coming in and saying. Here's the type of thing that I'm having problems with. And then find their way down to what we've written this is the most important. So the other thing that I was thinking is like, this seems to be like a change in the template. Maybe we can, I mean, if the new use case are not at least having a one best practice. I don't know if that makes sense to include as part of the best practice. Right. I mean, just talking about the new, the new use cases has to have one. Yeah. Yeah. I'm going to say that again. Victor, are you still there? Yep. Sorry. What was the question? Oh, sorry. Can you just say, say that again? Or did you. Oh, no, no. The only thing that I was saying is like, maybe we have to modify the template that we have it. Probably. Include that like a section where we. We need to provide the best practice, which is implemented in the new use case. Yeah, the way. Yeah. We can surely things. Okay. Yeah. So maybe that's something to think of the future, how we like coordinate them together. Cool. So we are at the top of the hour. I don't want to go over just reminder. If you haven't voted yet, please vote by tomorrow at the night Pacific. Any questions, please feel free to reach out to me. Otherwise. Thank you for joining today. And have a nice week. Thank you. Thank you. Bye bye. Everyone.