 Let's try that again. Hello. Good day to everyone. Hello everyone. Good morning. We'll get started at five after. Can add your name and any items to the meeting agenda. Meeting notes posted in the zoom chat also in Slack. Hello all. We'll get started at five after. Meeting notes are in Slack and zoom chat calendar invite. Hello all. We'll get started in a couple of minutes. Five after and add your name and any items to the meeting notes. Turn the zoom chat and Slack. All right. I'm going to get started. Meeting notes around the zoom chat. You can add your name and any topics. I'm not seeing any other new ones right now. Does anybody have something they'd like to add specifically? That's not yet on the agenda. Anything have anyone have something interesting from Kubecon they'd like to talk about? Yeah. There you go. Tell. Okay. Well, I'll just have that on there. All right. I'm going to hop right into some of these. So we have a few more things that we need to discuss. We have a couple of. Call up of love. The closed items. Interested party. Take it. Added. This one. Let's see. Oh, this is the main one. I'm going to jump right into the actual. So the interest of party for those that haven't seen this. If you weren't in the last few meetings. company or that they're with, and this could be used for multiple purposes. One of them was the voting originally, but it's communicating the different groups and people that care about these things, which will be helpful when we're talking and collaborating with other groups so that they can say who's involved and how does this relate. So please add yourself there. I think there's a PR to add some reasoning at the top, but I'm not seeing it here. I'm not going to worry about that. Go check that later. Tech leads, we've removed those for now until they're needed. Let's jump into the open PRs. If you have been working on some of the PRs, then you may have seen the checks that are happening. There's multiple types of checks, including linting, and the PR process has been updated to say at the moment, we would prefer that everything passes linting, but we've been going through the whole repo a lot of little updates, so it's not a hard requirement. But if you get whatever file that you're working on passing, then I think that would be good enough. But if you notice other stuff, of course, fixes on those things would be good. Taylor, Vuk is speaking actually, I'm just going to comment for the number 95. Yeah, I'm going to open that one. I looked at and got some errors from Markup or Markdown-Linter, but they were not verbose, so I could really not pinpoint where it was. The issue. All right. If you check. Sure. This might be helpful for other people that are trying to create the PR. This lint. Yeah. Super linter. All right. So this error is found, that's not very helpful, so you got to actually work your way back up. Well, there's a lot of contents. Okay. So here's, it looks like there was a big, pretty big failure. That's interesting. Context. So this is talking about headers have to have a blank line around them, surrounded by a blank line. I'm going to go back into the content. It looks like most of them that I'm seeing are there like that. So you need a blank line above and a blank line below? Or the blank line, actually. There's three strict checks about how many spaces or whatever off the end of a line, so you might have some lines with spaces at the end. I think some of the template has some problems already. So I jumped into this problem as well when I submitted my PR. So this one would be something like this. If we do like that, now it adds a blank line. Yeah, I'm not going to go through the whole thing, but I will try to do it in the background. All right. I can work with you and get all those in. Let's see, what else do we have though on this one? Because this is one that we've had open for a while. Are we at a point other than those, I'll say minor linting issues? We could even, I would call that one minor. Those type of things is minor and we can almost come back and do a second PR. What I would say is if we're getting lint failures, we don't actually like very much, then I'm sure we have control over what rules the thing applies. So if we want to basically get rid of rules because they cause us problems and I have no benefit, then that is a perfectly acceptable approach. That's one thing. The other thing is, I think you've already identified that the linter produces terrible error messages. So either we figure out how to make it produce better ones or conversely, we give people some clues as to how to read lint output one or the other. Because I mean, you're not the only one I had the same problem when I was looking at this, I got to the end of it eventually. But realising firstly how to find that a file has failed and secondly, that that message is just a summary and there is more clues higher up, basically giving you indications of what the failure is. That one itself was a bit a leap of deductive reasoning that took some doing and it sounds like you're doing exactly the same on this call that, you know, okay, eventually I found an error and it wasn't even the error I was looking for I wanted another error. Yeah, sounds good. There's the way to adjust the output would be nice for especially like errors for me on a test testing framework. Usually you'd have a little bit more information at the end but this just says you had an error and it doesn't give you any context you have to scroll up but we can look at that. Yeah, basically I was looking at the error message directly and was they have experience with Atlanta. Now I would be able to I'm not sold that we should turn it off completely. Is that Victor. Yeah, the other thing that I was thinking about is, I included like the make file. So, if you, you want to run locally and don't wait until you submit the change and in the data infrastructure you can run make link and that is going to run the inter locally. The other thing that might be nice is for. I don't know if it'll do it but some test output, you can have it not show so detailed on the ones that pass. And then it shows it only shows the information when it fails. We're not really looking at like an entire pass fell for, I don't care about all the positives that's which ones actually didn't pass. All right, but we can do that off and maybe just a ticket and do a round of adjustments on that we've heard a lot of the same feedback. Other than lending. So what are the other things that we can work through. I'm seeing some stuff here is, is this something for this ticket, or I mean PR do you want to open something new. Essentially, I went through all suggestions and I accepted my edits or committed the changes that were proposed by a couple of people here so I think the only locking issue is again I didn't make it with this link code base. The only thing that I am seeing here is one change requested by by you Taylor, but I think this might be an outdated thing, because I accepted made a commits. All right, so I have the option grade out. It looks like is this one already split open split apart this Jeff was asking about this and I think I made the suggested it based on what his feedback was. Did this one already make it in. Yeah, I committed that one. So I don't have any more than the option. All right, I'm going to resolve that then. I think this was just a comment from Jeffrey to maybe we obviously could have a lot of follow up discussions and maybe some use cases. branching out of this use case and then drilling down in some some details. I would honestly prefer to leave it like that and then come back to it in in in our discussions and then drill down into some aspects. So you can consider this as a bit of kind of umbrella use case for a life cycle management of the infrastructure and to that related behavior of CNS. Yeah, absolutely and best practices could point to more than one use case, of course, since they can be used and more than one use case so this one may be as you're saying like an umbrella larger one and then we may have a best practice that also points to a more focus small use case that, for example, test case even if it gets down to that. All right, so I'm trying to find the one that you're saying there's still one open. Oh, is this no this is the one I just made. I'm just going to commit that since it's a lint fix outdated you must have already done it and I'll resolve it. I found my linter problem. I think the last standing one with this blank lines. Yeah, because I skipped so is there it should be in in shape. So what what is the one that was still in question. You said there was one item left that we haven't addressed. Scroll back down to the bottom, and then just click on what where it shows like approvals and what you just jumped it back up. So go to the bottom where it shows like who's approved you hasn't and just expand your thing that says reclaimed chess requested and this is what and then you go on three dots. Well, I don't think I can do it. It's probably looks different for you than me. Let me see to look at them. I'm not seeing anything that's like a committable change that's no remaining so it may be that you've got everything and I can just mark the request. Let me see see a review. It is related to the six years six days ago. If you look at the history six days ago. Go from the bottom up. Yeah, this one. No, this is eight minutes. This one. This is showing it's already it's showing outdated. So you may have already completed to approve. I think this. Yeah, absolutely. So I can. That's what I'll do. I'm just you go you go down or go. Yeah, I guess I could have done it from there go to the bottom and then on your. I'm I'll just do this way. I think I'd. That is looking. So we need one more to merge this so that there's everything else has been addressed. We, I think Jeffrey, we committed all the changes that you requested. The remaining ones I think were comments versus changes like we split one of the paragraphs to be our sentences to be easier to read and stuff like that. So, let's see, and you've already approved it. Do we have any other approvals on the call. Is anyone. I know that a lot of people have been tagged over the last week. Rob is something happened with the configuration that are no longer able to approve. Okay. Don't know how it works now. Have you guys changed. I don't know. I've just read it to you. Does anyone else want to approve and you're not on here. Hey, Rene, you're there. While some of these maybe coming back with a with a feedback, I just noticed is the super linter is really painful. So it's now complaining about multiple trailing spaces or no trailing spaces. Yeah. I don't see anything except for spaces around stuff so I'm willing to merge it with with those and then we can go back over and fix all the length issues on another PR, which would be a minor change only requiring one approval. You're already on this. We need one more approval. I can approve it. I mean, I can review later. All right. We'd just like to get this one in since it's. It's been open for a while and we keep approving and then there will be weeks later someone will have another comment. And what we really want to do is those type of things should be another PR or add comments to the existing stuff rather than keeping it open for forever. All right, and I think Ian, if you can go through it too. So maybe you have to refresh the page. Okay, you think we have some more. Let's see. All right, a whole set. Thanks, y'all. Let's merge it. Go into a squash on this one. I don't remember. And some other folks I think I'll make some comments about. I would recommend it honestly otherwise you just end up with a bunch of commits that send to say someone did a two line change but I'm not telling you what it is. All right. Change history a little bit easier to kind of walk back if we do. I'm going to make like this then. This was that was me. I went and made a bunch of like grammar changes and whatnot. Okay, cool. These that don't say anything I'm going to leave off. And then I'm keeping. Okay, we don't need to three victors. I don't need another victor. All right, that doesn't seem right. Feels like there's a lot more on there. There are two times your name there. I feel like I think that will populate if you like actually did like the inline and suggest and comment. Yeah. If book accepted it then it's like, it pulls in because then you went directly edited the document. All right. There we go. All right, we did it. Thank you. Let's see. This might have been the interested party thing. Oh, it is the one that I was referring to earlier. Okay, so there's a few other things and the contribution. Comments around this. Let's see what's interesting. Meeting stuff so if people are trying to encourage people to come then where the meetings are happening. There's a lot of information involved from issues, first issues. This is about the lending stuff saying that how to do it, including the make file that Victor mentioned earlier, if you want to run it local. Then the main things. Okay. I don't know why this is not visible. I'm going to skip that. So the main reason this PR is in place was this top portion. So what is interested parties about expressing an interest in these topics and add your name and organization and PR. And then communicating that it could grant you some rights, including capabilities to vote if you're listed. But it doesn't imply any obligation to you or the organization, including legal, just to make sure if people need that from your side, we've added that. And I think the rest are kind of like links and typos. I don't know how they made it in here. So we need one more approval on this one. Let's see if anyone's done that well I've been on this. No. Any objections comments about this one. Could I get another approval, maybe approved in the past and got bumped off. What was that. I'll approve. Okay. Are you on here already Simon. I may not be. Let's see. Oh, and there's five. I don't know what this alpha states about. Yeah, it seems like last night I paper. Well look at all these people on this one. And we didn't have hardly any on the last headers this headers things killing us the blank lines before and after. Okay. There's a new one. Simon, you're already in. Jeffrey, confirm and merge and delete the branch. I forgot to do that in the last one. All right. Jeffrey, you ready to talk about this one. See enough definition. Nope. But I will. All right. Let's see. What do we have right now? We have three. Approvals. Agenda. I'd like to really quick too, since we're looking at this. We've always had this issue of chicken and egg where we use definitions that most of us agree or illy defined to define some of our own words. I think that's the release of the CNF, or sorry, CNCF glossary. It has things in there like cloud native application or whatnot. Can we maybe put something in that says, we are going to adopt those. And if we feel that they're inadequate, we would work at that level for some of the more non CNF specific terms. It would be good to try to work with the global as much as possible. I'm actually supposed to have a call with Catherine and this Catherine and Jason right here Jason Morgan who are leading on this they had a talk during QCon, so I wanted to get some feedback on what they're doing and talk with them about the cloud native principles papers and stuff, but I think it'd be a good idea to try to push as much upstream so it's global to all of CNCF. Yeah, I think if we disagree with those terms or we don't feel they go far enough, we should be. This group should kind of advocate across the CNCF holistically to get like you know our thoughts once desires out there, but then it's a lot less work on us and we don't have to deal with conflicting points of view. If our glossary is as CNF specific as possible, and we just adopt terms where it makes sense. So this one is still about, or the PR is about the CNF definition. And I think the tie in with this would be what you have here a cloud native network function is a cloud native application. So then what is a cloud native application. And there's some of that over here. What is this is a cloud native app so what is a cloud native application. We go on to be explicit and say it's this application is implementing network functionality. So there's lots of applications out there. And this one is about network functionality. The CNF consists of one or more much services. So here we're really expanding on what a cloud native application so it's good say and they don't they don't have all these details but we're going to be more explicit. This still could be good. Jeffrey, I'd like to hear your thoughts, because we are talking about best practices, and they're not really getting into best practices so we could say that we're expanding on what they have so taking advantage of cloud resources and scaling capabilities and all these things, and then how to do it. This would be the best practices and thinking cube native. So a CNF consists of one or more much services which can be delivered and has been developed using cloud native principles including loose coupling and mutable infrastructure declarative apis and a repeatable deployment process. Do we have any more approvals will we're sitting on the call are there more comments and thoughts. I guess I wonder why we need to talk about microservices. Are we referencing a specific architecture. I just pulled that out of the tug white paper. So I don't know. Once again this is the whole. The gloss rehab what a microservices. I mean you could look at an entire like full network function itself as a microservice within a network ecosystem right like a switch is providing. So I mean, you get into all these weird layers of abstraction. I don't care if we pull stuff out I just grabbed stuff. First from the principles paper then from the tug paper. At some point though, I do think we should be more explicit like I like the glossary definition. It's kind of the stuff that Ian always harps on around it runs in a cloud, which is good. Like at a broad level but then I'm, you know, what is the CNF itself, just saying it's a network function that runs in a cloud. I mean, that is technically an accurate definition I don't know if it's a useful definition though. Well, that would be a cloud network function but if we want to specify what makes it cloud native specifically. I don't know if the architecture is part of that it's more about behavior, but I, I don't know that this could be a starting point and we can keep iterating right. And I mean, I agree that maybe it talks about the verbiage could be cleaned up maybe maybe we don't approve this right now, or we do we approve it and then we do more stuff but maybe it could be, it should be more instead of consist of one or more Microsoft can be consumed as a microservice, right. And, but I mean, things like loose coupling. I mean, that it doesn't say that your services inside have to be loosely coupled it just says it includes loose coupling and I'll be honest, I'll fight that one that it should be in there like all these like statically maps service change all these statically mapped services etc, like makes things really really hard. But I guess this definition if the glossary supposed to be definitions that we're already including possible suggest best practices for reaching, you know the goals but I didn't I, in terms of accepting this PR or not, I'm actually in favor of accepting a lot. I, we can always add more and more PR is later I. My advice would be to iterate quickly and keep adding more and more iterations. So, even if I don't, I'm not entirely happy with what I see here I would still approve it and think of it okay this is a contribution. And it's a good contribution and we'll keep moving forward. Honestly, I would rather we make attempts to work with the definition and see how it's shortcomings causes difficulties. Then basically endlessly arguing the poll request even again right I have my own reservations in terms of any CNF definition but I think the answer that is there probably isn't perfect definition that's part of the problem. I'm going to make it. Go ahead. I was going to say like, it's good to discuss this stuff though because I mean, I just pulled that out. I mean, yes, I like help build that original in the job but I agree that it does force architectural opinion in there so maybe we just move all of the specific references out of there like microservices loosely coupling or declarative API's and we just boil it down purely to it falls cloud native principles and those can be discussed offsite and that I do think that I'm it being, you know, a repeatable deployment process that is a behavior that we want out of it that's not a specific implementation thing. Yes, let's narrow this down right cloud native principles are two different sets of things that people tend to conflate one is what it does and one is how it's built now repeatable deployment is a thing that it does but microservices is a thing about how it's built. I think the former is actually a lot more useful than the latter. If you look at some examples. Didn't we say that we would link to the CMCF definitions for now. I know we did. We've talked about this. And I'm a vote against because I don't think the CNCF definition defines cloud native. I think it defines things that you recognizably see in cloud native applications in today's world rather than defining what cloud native means. So it's a work in progress, the new definitions, not the main CNCF definition doc at the top level this glossary project, I think is the reference that we have never really talked about this because this is brand new. I've already had multiple people that are working on this say that it's just a start. It's not. I mean, I know this says completed but it's not covering everything that we've we've already been going into. I like what you said earlier about iterating quickly. You know, when when kind of picking apart this definition or what Jeffrey gave right is, it could be argued that if you take an example like a control plane network, essentially, like Calico or something like that, that is comprised of microservices. So it's somewhat easily arguably, but easily linked to kind of what network looks like existing and it could be iterated on later and kind of the mindset that a contribution is a good contribution and sparks debate at least. So I'll add another point specifically about the other glossary. That's a work in progress Taylor as you said I think it's good for us to define cloud native for the terms of the workgroup so I'm actually not necessarily I'm in favor of referencing maybe the other glossary but I think in terms of defining what a CNF is, we can define what cloud native cloud native means for specifically for CNS because it's not just a regular application. And I wonder, I wonder to you know I'm thinking out loud here that it could be a matter of degree right there's not a, there's not a clear suddenly look at a network function okay this is a true CNF or this is partially cloud native or it's cloud native in some ways and not very cloud native in other ways. So, maybe the definition should be about criteria, even a list of criteria that that would work in terms of okay, you know we either we either cover all the criteria for network function or not. And to an extent it could be aspirational in terms of becoming a very good, a very cloud native network function right. And I'm not sure myself I'm thinking out loud and maybe I'll turn my thoughts into a PR as well. So we could. It would be great I think it multiple people took a stab at this, and maybe we can kind of come together bring together different ideas from different people into something that ends up being helpful in the end this is supposed to be a helpful definition. Yeah, so on that I took a bunch of stuff out real quick. I'm a fan of the move fast but I also don't want to just put junk in there so I stripped a bunch of stuff out with the hopes of us having a more neutral starting point, we can just put more PRs against it. I don't know if this helps definitely helps. Probably, we are writing definitions and some documents, but we are still on the GitHub and if you look at how the code evolution happens. Actually, it's exactly the iterative process the first commit is always something that's maybe half baked and then it gets expanded by community but it doesn't prevent it from being a commit or being pushed. I would vote in favor of really having a decent. So not the garbage things in but having a decent well rounded definition input, whatever we are committing and then iterating on that. To be clear, this is not garbage. I think this is. This is useful I think this is a useful starting point we're already discussing it so Yeah, same, same for my side. What are you saying you would accept it. How it was written. Jeffrey put before or Oh, I. Yeah, I'm accepting. I like Jeffrey. The current suggested change that we're seeing by Jeffrey is the one that I prefer to remove those architectural elements but Yeah, and we don't even have to squash things right because it's kind of nice to see the history as well. I'm making a meta comment here I think everybody who makes a contribution makes a commit. That's good you know it's okay to have a long commit log. We can see the differences and we can see who contributed what exactly like source code right. All these properties are stuff that are listed when we if you dig through the glossary the definitions over here. And they have all sorts of stuff including talking about microservices and loose coupling and immutable infrastructure is all part of this. So these would be properties that you would see. It doesn't mean that I guess if you had a single. Well actually these are all high level so you may not use every best practice and I guess it may not have every property if it's not actually part of it. But if if you are implementing a feature. And there is a property that you would expect to see in a cloud native application that's implementing that feature, then it seems like those would be there. I think we gotta we gotta take in mind like scope and audience. So when we wrote this for the tug. It was when we were trying to intentionally opinionate and provide context with the definition. Versus I don't know I mean I know why you want them in there. My hope would be though that like the best practices that feed off of this would be where we, we have you know best practices that show you should be loosely coupling. But I mean, unless we're giving a very, very verbose definition and trying to shape opinion within the definition itself. Like the news are we reporting the news or are we giving a syndicated opinion on something kind of deal like, what is our goal with this glossary is it to just provide baseline context, or is it to kind of shape influence opinion from those outside of our small collective here when they come in and read this stuff. I actually would prefer kind of more the just generic news standpoint. But I've had time to stew on this, and then let the best practices try to guide people towards loose coupling and mutable infrastructure, etc. And I did leave cloud native principles, you know, as a development consideration in there, which I think should also kind of imply that some of these things are followed but I see what tells coming from where like a definition that's already subscribe or prescribing architectural considerations kind of put you in a box when you start to go out and explore and decide what you are and aren't going to go right. It sounds like your is your PR so I'm going to commit this here at Jeffrey, and it sounds like your approach because this is your PR. The, your approach should be to address. All of the properties that would be principles what are what are the cloud native principles, not whether these are best practices general for networking application. What are the best practices, if you're building a cloud native application. Would you just lose Taylor. I'll use that record. I'll go ahead. I was, I was going to say I reserve the right to change my mind in a week from now and put in a new PR is that how iteration works right. I believe so. I want to add a point to what you said Jeffrey about you know reporting the news. And it goes back to a point very early on that chain made where you know he's, we had this big argument of CNF really means container right and it doesn't, but we also have to acknowledge that people use the term CNF already very, very widely. And often it simply means a network function running in Kubernetes. That's it. It doesn't talk about if it's running in a good way or if it works correctly with Kubernetes or or anything else. So I guess I'm saying that for our purposes. It should be descriptive right and should describe how people are actually using it and then we can say well how do you build a good CNF. And that's not part of the glossary that's one of the goals this that this whole work group is aiming for I think right. Do we have Taylor back. Yeah I'm back I have no I don't happen with my connection there. I've committed that change. It's, I don't know where I cut out but it sounded like your approach Jeffrey was to tackle all of the properties that would be part of cloud native applications and the best practices. As those are going on, then we those get added immutable instruction everything so. And to have something like this cloud native application a link, there's a reference to linking like that. So real quick to before we do this, let's chat with the group here is, do we want to do in band links like that, or if the main thing you know we put on a little. glossary but this is the glossary little index at the bottom, you know linking like for like the kubernetes definition, I go my link to kubernetes.org, their docs and stuff, just to show people that I didn't create my own definition to kubernetes. I don't know if we want to do in band citations with the links like that, or if we want to like point to something at the bottom, I have no opinion as long as we're citing our work and showing that we're not just you know, pulling stuff out of thin air. Why not in band link it works relevant so people can follow the, follow it in context. That's fine with me, and then I say we commit this Taylor and then we do a follow on PR to him. You know just get that consistent with the other pieces. I'm going to try to write a PR for this to I want to take a stab at trying to do this. We'll see how it works. Did you accept my invite so I can add you as a reviewer. You said you're ready to approve. I'm sure let me check. Did you do that just now. A little while ago. I should have accepted it let me let me see if I can approve. Brandon I think you said you're ready to approve so I've added you. I'll approve it. I think it's wrong in the definition right now it's ends and then there is a period and a new sentence. It just says a CNF has been developed as a part of the definition. We need to relook at the sentence. Where is that. In this definition. If you go and look under the definition. I'm going to go under. So it's two sentences now. And the first sentence is fine. The second just starts and says a CNF has been developed using cloud native principle. We are defining and allows for and that but should should the sentence start with something else because I think if you just simply change it to a CNF has been developed or should be developed. I'm sorry. Exactly. Yeah, that changes. It's the it's the context. That's all. Yeah, thank you. Yeah, yeah. Perhaps not has been or should be a CNF is developed or. Yeah, that's fine. You should be or is. Yeah, fair enough. Ian is language just is I mean. What's what's going on. The concept of. Odd passive voices and future will be used doesn't really make a definition. That tells you what a CNF is which is what we're trying to do in a definition. We're right that's still passive voice, but take anyway. It's still better than has been so. Okay. for repeatable deployment process, why are we keeping this last? Isn't this last part of the planning of principles as well? Yes, it is. No, that's a desired behavior though. Yeah, that's the place for desired behaviors. Is that, isn't best practice the place for desired behaviors? That's the whole point. Right, that's what I'm thinking. If we're removing all the rest and remove the... No, so I mean I'm not saying that we have to keep this in here but a desired behavior is not a best practice. A best practice is an implementation to get a bit like desired behavior. Like me saying I want a repeatable process. The deployment process isn't a best practice. That's just telling you what I want. It doesn't tell me how to get it. Okay, we're actually using a use case. The problem with this is we're codifying things that are neither a use case nor a best practice. Interate fast and get the PR in. We can keep adding to it. I'm done with acting it. Well, we could turn it into an example which I would be good with. For example, to enable a... Maybe we can make some change and I'll put it in the chat just a second. A suggestion. It doesn't like when I do British but... Again, I'll say that this is a little bit... You know, not all CNFs are developed with cloud native principle. We're kind of stating what a CNF should be at best. But again, this glossary is supposed to be useful for us, right? So it's... A lot of times we're going to be talking about CNFs that might not be developed using cloud native principles very well, but they're still part of our deployment and we're still working with them. Those are things for CNFs. They wouldn't be cloud native network functions. Taylor, I put something in the chat of rewording, if you will, particularly using repeated deployment processes as an example. So again, a suggestion only. Well, I guess, well, what is it? If you have a network function running in Kubernetes and containers and it's not developed using proper cloud native principles, what would we call that? Well, it's just a VNF... Appliance, containerized network function. Yes. Bear in mind, a CNF literally means... Well, I mean, this is not the definition of a containerized network function. This is the definition of a cloud native network function. Yeah, I mean, I'm answering to Taylor's comment about if it's not following the cloud native principles, then... I mean, the one angle to look at that is actually why we are at all considering and then looking for a CNFs. And this is the incoming to the point where you have a unified cloud infrastructure in a CSP, which has a certain properties and these properties are like a reference, not a reference, but they are hard reference. And cloud native network functions are those that are able to run in such environment that do not require some specialties and so on. If it's not running on such environment, then it could be called appliance, it could be called silo solution, it could be like Kubernetes-based network function or whatever else, but it doesn't fulfill the purpose of running on a unified infrastructure. Well, I would suggest then that we add that to the glossary. We think of a way to talk about those things and find a name that we all agree with. Can make a take on it in a separate... A CNF is not bad, a Kubernetes network function. Because that also includes things, for example, running virtual machines and Kubernetes, etc. Create a PR for that, Tal. All right. Yeah, I will. Yeah. And by the way, I do see you added me, but for some reason I'm not a reviewer on this PR. Maybe it's because I didn't... I'll add you on to this in just a moment. Pankai had this in the Zoom chat, which merges those two sentences. A cloud native network function is a cloud native application developed using cloud native principles that implements network functionality. I'm okay with that definition. And that can run in a CSP's cloud. Or maybe I would say provide it to network functionality. That implements provided network functionality. I think provide... What? I think it's better, actually. Implements are provided. When we say implements, what does provided after that mean? I would say just get rid of provided implements, network functionality. Simpler. Okay, that's what we already have. I meant to replace implements with provide. That's what I meant, that provides a network functionality. What do you think? Yeah, that's clear. A CNF is a cloud native application developed using cloud native principles that provides network functionality. We've kind of boiled it down to the simplest, but it works, I think. And really, you could get rid of this developers. We're only putting developers in cloud native principles because it doesn't specifically say it over here, but we do want to say that you're not a cloud native application if you don't follow cloud native principles. You can be a containerized. You can even run on Kubernetes, but if you don't follow the principles, then you're not a cloud native application. And if we're getting really finicky about this, it's not so much a matter of being developed using those principles. It's a matter of functioning using those principles. Exhibits those principles. Right, exhibiting those principles. Correct. How do I know why? Exhibits are native properties, then. You can't exhibit the principles. I think developing using the principles is fine. Exactly, you can't exhibit a principle. Just refresh, yeah, there you go. OK, Tal, you're there. I added Brandon before. Oh, I see you're still here kind of Brandon, you're on there. Yeah, I see it now. So I need to refresh. I'm going to refresh as well and make sure I can modify that if we're down to the last, hopefully, iteration. If you want to add me and approve it also. Implements, this is not the version. OK, let's try it again. Here we go. That provides network functionality. Or did we decide to change developed to? I mean, we can remove that whole developed using cloud native principles. It's it's simply the simplest definition. It's it's a cloud native application that provides network functionality. No, no, no, no, I agree with Taylor's statement that if it doesn't, if you haven't developed using cloud native principles, then it's not cloud native. I think that's the whole. Well, we're linking here to cloud native application. So it right, but they don't say that in their definition yet. They may by end of the week after I work with them. But right now they don't. All right. My name doesn't have a Y then it has a J sorry. Sorry, what was that? P and K, J, not Y. Ah, sorry. No, no, that's OK. I think, yeah, on the keyboard, let's type out. OK, all right. So did Jeffrey drop? Yeah, yeah, to draw may have. OK, what is this? Simplifying. All right. That's there. Hopefully, I'm going to check one more time. That's what we want. Cloud a cloud native network function. OK, it's a a cloud of network function as a cloud of application linking to the absurd global CNCF docs developed using cloud native principles that provides network functionality. I probably should have put a comment here. But yes, to separate that and to be consistent, maybe cloud native should be lowercase and CNN. That was my mistakes. Yeah, I'll make that change. I hate to do anything else. We're at the top of the hour, y'all. I think we should drop. We have enough approvals. I'm going to. I'll send this to everybody, but I'll make the change for the capitalization to be consistent and have that in the commit. And then I think we're good. The next time we're here, maybe we can talk with folks about the new use cases. So we have a stateful and a 5G use case. OK. Thanks, everyone. Thank you, Kyle. Thanks, bye.