 How do you fix? I think the meeting notes have the wrong zoom. Just me. Right. We'll do the usual wait until five past to see who turns up. If you have any agenda items, you can add it to the meeting notes, which are posted in the zoom chat in the calendar invite. Or if you're having problems accessing, you can verbalize them here. Right. And we're off. Usual rules add your name to the meeting minutes. The link is in the chat. Taylor's posted it for you. And again, as he was saying, if you've got any agenda items, we haven't got very many right now. We will start working through them. So there's an upcoming event entry in here, although there isn't a great deal to say about it. We've got a meeting. Our companion group on Monday, August the second. So stick that in your calendar if you intend to turn up. I certainly plan to. Both the coupon and the ONES call for papers is now closed. So we're all done with writing those up. But we don't know what the schedule is going to be or which papers will be accepted and we won't find out till the end of the month. So that's a waiting game. And we'll just have to see how that goes. The first item of at the moment only two in the meeting notes is what is our timeline for determining best practices. I would say firstly that this is an ongoing process, but actually I think it would be useful if we did set ourselves a goal for putting at least a handful of best practices in, whether we choose them by name or we simply head for account. I don't know if anyone else has got any thoughts on the subject, or if you're just hiding through sheer terror at the idea of committing. I don't know. Anybody out there. I wonder what what would be the point of setting the deadline. I mean it will be ready when it's ready if we set a deadline. Is the point just to get us working faster. To give us a bit of motivation would be one point. And I think actually it would be useful as well to have some example work to that we have completed by ONES and coupon, in fact, which is, you know, we've got some time before that happens. But yeah, I mean I think it's more a motivation thing than than anything else at this point. Also some people in external communities are looking to see the deliverables of this work group so I've been so far reluctant to point them anywhere because I treat everything here as working progress but it will be useful to have something marked as a 0.1 or whatever version that we can refer external folks to. We've, I've been hearing that as well Ranny. Everybody's asking to point and similar to what Ann said examples so it can help other people get started if they have an end goal. They may have use cases that they talk about but if they have a goal for why they're talking about a use case, then it could help. Or it may cause a best practice discussion to pop out of a use case because they start having that framework in mind. I want to reiterate something we've said before, but even the best practices, whatever we say a version one or is a release or whatever you call it. They'll all be up for updating in the future. If things change and a best practice doesn't match the current reality then we will update it to match reality. One other thing there is, you know, our processes we've outlined it is going to be use cases, designs and best practices and then a baseline which we give a version number two. And, you know, a set of use cases more than zero gives us the opportunity to actually complete that so that we know the full cycle of the process and then we can, you know, set a timeline for going to the next version afterwards. And then everybody will understand not just what we're delivering but how we're delivering it because we'll have worked through the entire set of work items. Let's put this a different way. If we were to put some best practices together in relatively short order and again this is timeline of months not like by Friday, which ones would we like most to have finished which ones do we think are most do you mean based on the use case being complete or do you mean is it sort of pick and choose which ones we like. Which ones we will not basically continually argue over I suspect but yeah which ones do we think we have the most hope of completing either by, you know, having a solid justification, or because they're relatively straightforward. We don't have to be based on existing use cases. So if there's a practice that someone thinks of and we have no use case, then we'll start creating a use case to talk about that best practice. I mean I still feel yeah, we haven't got much work on this and I think I could do well I know I could do more because I haven't been I haven't had much time for this but I think something on, you know, how to apply least privilege would be my personal favorite. It's quite technical when you arrive at the recommendation, but the justification for doing it is relatively straightforward. And honestly I don't expect anyone to comply with it, you know do not use privilege of any sort or, you know, find ways to dodge using privilege. Based on CNF side worked with I suspect that would be actually quite hard to achieve but on the other hand, the point of recommendation is to give people clues about what they can be doing differently so I would not necessarily have a problem with that. Yeah I mean otherwise the only thing I would say is I mean, and maybe this is the wrong approach but I think if we have use cases that have been approved, or you know been merged then at least that's a starting point for that we should consider, you know, trying to derive the best practices from. Yeah. So I'm still working on my very large best practices document about operators and CNF's. It's work that I would do anyway, and I'm working on it anyway. I'll be happy to have it aligned with whatever we're doing here but I have no doubt that it will create arguments so. I don't think we've come to a conclusion that we both like at the same time I have to admit, but. So are there any, you're saying there's going to be a whole set of practices under operator usage so are there any, in particular that you think are more agreeable to a larger set. Another thing that we could say is, if it's very agreed to, or fully agreed to within Kubernetes community, and everybody is on other applications are saying this is the normal practice you should use in this situation, then that would also be a good one to look at. Well we'll see I really hope to be done with it this week I keep adding more sections. It's, I'm not following our structure very closely it's more a discussion of architectural considerations versus practical considerations and main uses I'm looking at our stateful components. So integration management and disaggregation, which is more architectural. So I, I don't know if anything I write will really be objectionable but I think it will have to be shoehorned into the format that that we have here. I'm happy to I'm contributing it anyway to to the universe and you know we can maybe use it to grab things or start a discussion or see where it goes it's just hard for me right now to commit that this would be a deliverable at a certain time, but I'll throw it into the pipeline and see what happens. Yeah, I would say with that that you know it may be the structure I mean because I've had thoughts about this as well it may be that our structure isn't exactly right for expressing some of these ideas because, you know, I do this exactly the same as you do. Sometimes you arrive at a conclusion from studying the technical problem rather than the use case. And I think there's a little bit of both thrown in here. You know it's both what we need to do and also what is practical to do and whether or not, you know you work with the world is or, or, you know, you view. How do I put this UV view best practices in isolation and see whether they make sense for us. You don't always drag your every bit of information to come up with a recommendation from the experiences of an operator. So, yeah, it doesn't surprise me that you're coming up with a document that doesn't entirely align with the way we've structured things but that maybe that the structure needs a little bit of looking at. Well, look, I'll be happy to show it at some point and hopefully soon, hopefully on next week's agenda if I can get it done in time and what we'll just see where we go from there. Hey, this is she tell Taylor I have a question for you. How do we see the telecom user group CNCS group right and this working group. March or will they stay separate. We'll have a reason does be separate. What do we see any conversion strategy. The near future. There's no plans on merging the telecom user group and the CNF working group. But CNF working group has a more narrow focus than the telecom user group. Okay. Looking at best practices within the CNF work group or looking at best practices for running networking applications on Kubernetes based platforms. So that would tie in with cloud native best practices that are applied to a Kubernetes environment. That's the first goal. And we could expand from there. And the telecom user group would be more open discussions. So there could be looking at a particular project that's interesting in the networking space for running on Kubernetes it could be operators or some other thing that's just a very specific technical solution. And we're not looking at saying this is the one solution and the CNF working group we're giving the general best practices which people can implement them in many ways. Similar to CNCF is all a cart for projects and that's, we're kind of giving the bounds around that for best practices. Does that help. Yeah. Yes, I asked the question because I guess in the white papers right where we have the cloud native network functions definitions can we tie it back to the definitions that we were working earlier, couple of weeks ago in this working group. That's the main intent whenever we have the work, the artifacts and the best practices use cases produced through this working group, can we leverage some of those under the telecom user group. Sure, I mean everything that we're producing we're hoping is going to be useful outside of the group. So one of their areas could be the telecom user group at a wider, maybe, maybe white papers articles blogs whatever discussions, and then potentially some of the information like terminology and other stuff make make it up into the CNCF global glossary, which we've been looking at some contributions there. Thank you. That led to a bunch of useful sort of discussion of which I've got a bunch of links to go read now. Tell was that you adding the open shift stuff by the way. Pleasant on the container should execute the process as an honor user. Yeah, that one. I added those. I don't remember who came up with it originally. I was in a another list. When we were working kind of a collaboration with Aniket and a few other groups and the tag is for the I think you had mentioned some of this maybe the SE Linux I think I may have found the open shift and some other things. I've certainly seen this practice in fact I've used this practice so I'm actually not, I'm not objecting to it my comment is more. Can we find the objective way of saying why it's worth doing versus shift requires it or it shifts to barely significantly benefits from it. So if we can find that objective view that will make it easier to write up. Yeah, sure. I think there is the maybe some of the documentation and the bit Nami. One was gave a good overview, but I think it could be generally applicable written to be generally applicable and we can definitely find other references to supplement. Was this specifically for SE Linux or was this on a different topic. There's a potential best practice about not executing a process executing a process as a non root user. That makes sense. I have an idea for a very low hanging fruit best practice that we can choose. Maybe that might be an approach that we could go for something. I'm going to go out here see what do you think it's something I got into recently where I had to implement STP and Kubernetes now. It's a fairly new feature in Kubernetes that Kubernetes services actually support the STP protocol in addition to TCP and UDP. But there are aspects here that are unrelated to Kubernetes. The question is, does the operating system itself have support for it and there are actually two approaches to implementing STP and Linux, one of which is using a user stack user mode stack. And there are also kernel modules that could do it as well. Now, when you write your applications you target either of them. They're not the same API. A user stack would be trivial to deploy everywhere and would be able to fully support Kubernetes, but if you rely on the kernel stack, you need requirements for the actual infrastructure for the host for the module to be loaded. So there's a pretty easy, I think, way we can come in here and offer a best practice. This is, again, a fairly new feature in Kubernetes that a lot of people are excited about. So it might be an area where we can say something smart coming from our understanding of networking and where performance is needed in the kernel, etc. Yeah, well, I've seen models of using STP that don't require Kubernetes features and benefit from that as well, which, you know, if you have a second interface and the kernel modules, then you just go and use STP on your second interface and Kubernetes has no involvement in that, other than the platform as a whole has to have the kernel modules. So questions we could ask ourselves, firstly, is would we expect the kernel modules to be present on a platform that is running, that is going to run CNFs? And the answer seems to be to me, why wouldn't you? I mean, it seems like a logical thing to basically build that module in even if the CNFs happens not to use it. It's no skin off anyone's nose to actually install it. The other one, which is a slightly bigger question is, is there one of the other one or the other of those paths that is better or alternatively should we make sure both of them are possible? Well, it may be removed from certain environments because they're in security hardening, they're trying to reduce the attack surface, so you may actually see some environments where it ends up being removed. But it is good to call out to say that if you want to use STP with Kubernetes or within the kernel space, then these are the type of things that you should enable. But I would be a little bit careful on that. It would be good to check if GCP and AWS themselves have STP enabled or not, because it is likely we're going to see some deployments into those style of environments, especially when you consider the things like Anthos or Outpost as they continue to gain more prominence. We'll start to see more edge deployments with that. Exactly. I'll even mention that RHEL disables STP, blacklist the module entirely exactly because of its security issues. So I don't think it's trivial to assume that you would always have it available. In any case, it didn't mean to start a whole discussion about it, but rather offer it as a potential low unit that we could attack. Maybe not as low hanging as we were hoping for, but still, on the other hand, you know where the mines are in the minefield now if you want to get something through, so that does help. Well, you know, if we choose things that are too trivial, well, what contribution are we making? I think this group, we expect this group to be a melting pot of expertise, right? Yeah, well, it's true. And we might be lacking a spot of expertise here because one question I would like to know from CNF developers, which obviously seem to be in the minority in the group is, have you used STP? And how have you used STP? And why did you choose to do it that way? That's true. If we don't have enough people here have the expertise, then it's not an area we should go. I mean, it would be, I'm willing to, you know, recommendations ideally shouldn't be ill-considered, so getting that expertise is perfectly useful, but that's fine. You know, it doesn't necessarily mean it needs somebody on this meeting every week. What it means is that you need to survey your audience, you need to talk to people who are doing this. And I can think of people from Cisco that you might want to talk to on this subject. I can think of another couple of companies you might want to talk to on this subject as well. You may even have your own contacts. Yeah, I mean, we could go and do the research too. It's not like, not everyone of us knows everything about everything. Okay, well, that was a conversation. Now, I threw in CNF packaging for delivery. I'm not saying this is necessarily easy, but I think some of the use cases we're already talking about, about, you know, initial startup, start speaking in this direction. A CNF is a collection of containers. It is hypothetically a Helm chart. It doesn't have to be a Helm chart, but you know, we would reasonably assume that it would be a Helm chart would be involved in bringing it up for the first time. That Helm chart is going to have parameters, those parameters could do with being more than just open to free for all, at least some of them you would think would be, you know, commonly expected. In the case, I wonder whether there's anything we could do about starting up CNFs. But the question I come on to here is, it's very easy to cross the line between making a recommendation and making a brand new standard. And I don't know what we should do about that. Should our best practices include shiny new standards or should we just at least put them on one side so that they can be recommended independently. Let's write them up and see what it looks like once it's actually. Fair comment. I mean, they writing the standard and then figuring out what to stick in is pretty much what Tal's trying to do I think with his, with his operators stuff. So, that's probably the right answer. I would say I'm. There's a delicate point here. We're not a standards body. I don't think this group. We all participate in other standards body, and I don't think we want this group to be a standards body we definitely don't. Our best practices guys aren't supposed to be standards recommendations if we, at least I don't think so. If we do reach a point where we want to suggest standards then it could be an output from this group that goes elsewhere but this doesn't seem the best place to do that. So, so it's more about looking at the ecosystem what's available so you mentioned helm helm is very popular, at least right now. So, standardizing on helm would not be something that we, I think should suggest right it's, it's more a question is if you're using helm, if you decided to have a chart repository in your deployment environment. Well, here are some suggestions that we have. Yeah, that's fair. I mean, I think, you know, again, this is more about how we'll write standards than it is about best practices but every standard needs an out for this technology will become outdated and when you have the next one this is how you use this standard with them with the with the next technology you want to use. It's been, it's quite easy to do. It's quite easy for instance to basically have a package that basically says there is a helm chart in there alternative there's a thing in here that you've never thought of but we added like three years later. So, certainly there are ways and means of doing that but you always need to make sure your standard has an escape route for for when the standard itself becomes somewhat outdated. Right in the end I think it's more about a general approach so I agree with how you started this when you said that when we talk it when we think about packaging in the end it's these manifests right that are usually in YAML although they could be adjacent to, but these these manifests can be generated from something so it could be a helm chart it could be some other tool. But the point is it's really focusing on those resources and what they are, enumerating them managing them thinking about them together. So those are general best practices that would work for whatever specific technology you want to do. Yeah, perhaps not generated from but describing the fact that such a thing is in the package and how it's supposed to be used but yes, your point is valid. So we're saying that if a packaging format were to exist. We don't necessarily have to define the packaging format but we could say these properties we expect of it including there is a manifest the manifest will contain this information. Then we can go and take that and write a packaging format that's compliant and stick it somewhere that isn't within the CNF working group. Right, exactly. Yeah, and the cloud native aspects here are important because as you pointed out delicately there's a difference between day one and day two you know helm can do one and not really the other and yeah there's a lot of thinking there it's it's packaging is not simple. But I think we might be able to make a contribution and specifically for CNFs and not just generally. If you could write a document that told me how to start any CNF that I found from anywhere, then I would hug you if it wasn't social distancing. I mean, seriously, it is a problem that I keep encountering that any two CNFs literally no idea how to start them and then you have to go and beg for the document that tells you how to start them and then it's a new exploration into a new way of doing it because it's never the same as anyone Exactly yeah I mean this is where operators can come in workflows can come in so the ecosystem is quite broad and I think what we can do is maybe take a more high level approach and look at different ways you can think about it so you can think about it as okay here manifests and then there are instructions and how to raise it. But you can make your components autonomous. So the idea is that they self configure and self manage right this is the kind of idealized cloud native approach in which there shouldn't be installation instructions right once the pods come up. They should do what they need to do to stand themselves up. Right so you know there is always a bootstrap phase here right I can walk backwards well what brings the pods up oh well the operator brings the pods up well what brings the operator up. Oh well yeah and then what puts the software in a place where the operator could even be brought up and so it may be less about worrying about the stages in between which are theoretically optional I can use an operator I don't have to use an operator there are benefits using an operator but how would I get that first sort of you know there is always a first step where I have a shiny new Kubernetes cluster with no software on it and I need to put software on it if we could work out what the first step was so that following steps could happen then you know and if that will help right help me the perfect reasonable way of making an operator happen then that would get us a certain well it would get us further than we currently are at least. Yes I'll true and I'll point out that again you know what's special about CNFs in the telco environment is that we usually have OSS BSS on top of this so the day one day two is has to be integrated in some way into into the larger network orchestration. Yeah although there's nothing to that makes a special there in the sense that you know all applications start with a chunk of they at least have to be kicked to begin them and then there is at least an outside chance they take later configuration. So yeah I mean both of those things are not exclusive to us we're not special we have opinions but our opinions fit into the fairly standard run of the middle of what you do. Hopefully. Okay that was a long discussion it involves lots of items it might be a good idea if we had a chat on the channel afterwards and see if we can actually pick some items that everybody promises to work on for a couple of hours this week just because I know for well I'm terrible at committing time to this and probably better if somebody holds me to it. If anyone else wants to work that way then we can we can try and figure it out in the channel later. And I'd like to go back to what you started before on this whole conversation it was about getting some best practices out. So if there's some topics that we think are agreeable more agreeable like the least privilege, then I would personally like to help try to get some of those out. I think it'll get rolling for everything else. So you, you and I, I think we're happily kind of, again, we could do some work on these privilege this week and see how far we can take it. Let's worry less about what we produce and more about actually spending some time on it. So if I promise you half a day of sitting there and beating on these privileged documents. That would, that seems like a productive way of going about this. Sounds good. I'll block the time out. And if anyone else wants to help on that one, or if someone else has a, another area that they'd like to focus on, then let me know. And I asked and found that basically holding ourselves up in a meeting and sitting there, effectively typing at each other does actually, it's one reason the good way of making progress. You know, you can all play that game if you want to basically find a partner and work with them. If that's not your way of working then so be it. I'm just saying it works for me. Let us move on to the pull requests and with apologies because zoom hates my laptop so I'm actually on my phone I can't easily share the screen, but I will have a look at the pull requests and if anyone else wants to basically take the lead and share what share a website you're welcome to. We have three pull requests sitting here one is onboarding CNFs. One is updating the glossary and one is adding 5G ran use cases. I'm inclined to start from the bottom and work up because I think the ran use cases have seen the least discussion so far. Has anyone got any general opinions on this at this point in time. Anyone want to pass judgment on it. I think it's a good starting point. All of these can be dived into with a lot more depth, but it's a good starting point. Yeah, I have to say use case one as and I told you we shouldn't number use cases by the way but still use case one and the synchronization and timing. I suspect, oddly, I mean I know it's technically in depth and it's probably not a care area we have, you know everybody knows what we're talking about but it should be one where we can basically be quite straightforward in writing it up. You need synchronization and tiny and propagated by the network with great accuracy. There is a perfectly good way of making that happen in the kernel. There is a perfectly good way of consuming that from CNF processes. So the best practice is actually there is only one way of doing this, the best practice is really easy to write. That one independently of the other one should be pretty easy to deal with. Use case two. I think is the standard you need more than one interface for not pod, which is really the way multis thinks about this, but you need more than one interface for CNF, you know different traffic goes in different directions and gets treated differently by the by the network. So my personal opinion is that use case to treads in areas where we know that things like you know exist and there's some finding exactly the right thing to say is difficult. But use case one is probably not terribly contentious because it's really just one way of doing it and writing it down. But actually the most useful thing we can do, you know, you will run PTP for our, your CNF will keep checking the kernel clock because it will be tightly tightly bound to the clock that's distributed over the network. We just write it down, and that would be done. Someone needs more accuracy than this provides. The one thing we could add in there is a lead back to to this to this repository to say open a new issue, and we can also investigate to see if there's a more accurate path if they would like to basically a path in the collaborate, because it's this is how long is a piece of string like this is probably accurate enough for most, but probably not accurate enough for for everything. And what's what level of complexity do you want to add into the system in order to achieve your, your level of accuracy so Yeah, someone has to ask for more accuracy before it's necessary to provide more accuracy there is. Again, my experience with ran here and it's ran that requires this level of accuracy is that they ask for. They ask for PTP or sink here the network and they ask you to run PTP URL or sink here for L and then they rely on the system clock which actually funny enough they never tell you but if we spelled that out and said, this is what you do in the in the platform to make it available and this is how the CNF consumes it. And we've got the things that the relevant audiences should be doing in order to get an accurate clock and again if it proves insufficiently accurate. I don't think we're going to be the ones here to say what accuracy means I know that sounds weird. But you know if I were to go and grab the system clock, precisely how many nanoseconds from the absolute truth is it. Well, that's a very difficult question to answer. You know we can just say this gets you. This is the best practices for getting an accurate clock if somebody comes along and says well it's not accurate enough then our first question would be, what is accurate to you what does accurate mean so that we can write a better use case. But yeah, I mean, I think use case one can be concluded. That would be great. Maybe we end up splitting the poll request into two because it does contain two use cases. The other one, personally speaking I need to go and revisit it's been a while since I read this stuff. So do you, we've had this open for quite a while, and I don't think that we've made much progress since the first time it was shown. I think we've had issues come back and I don't know a couple of months. No, but it doesn't need issues to approve it it needs us to agree that it's good enough. So that's. So we're talking about a use case and not a best practice. There's a few formatting things that have been committed. This item that you and Frederick are talking about for virtualized or non and to talk here. Is it a blocker for a use case versus a best practice. This is a situation that's being put forward. Yeah, situation is fine that's what we wanted to use case. Right, so that there's comments here which is fine if we're just saying it's discussion but is it actually anything that we need to change. I think that is just a wording issue. Funny enough, I've learned more about this in the last couple of months. I think that's just a wording issue. I think I can possibly make that wording a little more explicit. All right. If you really want to know about the kernel VDSO I can tell you horrible things but yes. I'm just wondering is if it's a blocker before we merge and then have another PR to update. It's not magic without fixing that wording but I think what you're saying is, I think we could have a revision of this for review next week. How's that. That sounds good. And if I can, I mean, I can add a little bit of clarity here by what I meant by virtualized as well, which is usually when you look at the time and Linux. You can do some sort of get time it's usually based upon some timestamp that's within the processor itself, and there's actually multiple clocks within the, within the processor with with each core that gets incremented with each with each every time they do perform a lock over every time you have a, every time you have a certain action appear within within the CPU and we've actually had issues with this in our systems before where you might have two threads running in into separate cores, and they become desynchronized enough that the order of timestamps to get synchronized and not not matching what you would expect so you can have something that it came afterwards that appears to have happened earlier in time in terms of timestamps so there's a couple of sort of a couple of inaccuracies like that that tend to occur from that so that's why I'm saying that these things are not are not virtualized but there there is sometimes depending on the so where you get your time that there can be issues of synchronization there depending on the hardware architecture. All right, maybe you can work with Ian on on a revision of this. It seems like you'll need to do a fork of this one. You'll probably have to go in and and fork this tree if you're going to do it or split one use case out from the other so yeah there'll be a use there'll be a PR that's half of this use case but yeah, yeah. I think this this particular one we were talking about hard specialized hardware that helps with with that as well so much. I suspect much of that goes away, or it gets constrained enough that it doesn't really doesn't really matter. Yeah, you need PTP suitable hardware whether it's the the nick or another device, and you need a device driver in the kernel that offers the PTP interface but then everything from there goes. So we can write this down. Some of this is really a step by step deployment thing. I wouldn't be averse to writing that down in a best practice but I think that would be auxiliary information I think the best practices the network has the timing information on it each shall be offered to the application this way and then here's the details you need to know that will help you get through that. I don't see it's bad thing that best practices offer people a bit of help. Okay, Ian, I can work with you to maybe create a branch and we'll update this PR to not go to main but instead go to like a working branch and merge, and then we could split it out to keep focusing and iterating that way we get. Yeah, get on something that we can manage. Alright, what's next then so this is the first PR. The second one working upwards. He says confidently having lost his window and update glossary. Oh no. Yes it is. It's but but Jeff isn't here so we should be able to get through this. And. All right. I don't know if we've hit all of the things at this point let's see. We have tons of requests we have more update request than we had the last time I looked actually. This is your poll request. Do you want to try and resolve some of these conversations that are sitting here in the over the next week, would you like to resolve some of the conversations that are sitting here in the in the commentary. No, I can click the resolve conversation button but that's not what we need here we need to to discuss I think the big one here is there are two different approaches to defining what a network function is. I don't I don't know what to do with this poll request anymore it's. I think we just need to continue to discuss until until we reach an alignment that that's basically it. And I would like to do it on GitHub but I think very very few of us here are looking at GitHub so I think these meetings are the right place to to to get feedback from everybody. I'll try to help you both places tell. I hear what you're saying some people are into the verbal here and some will be willing to read right with you. So I put a pretty big one, I guess I'll speak to this, and it has to do with. Before we move forward, I just wanted to ask a quick thing it's got to go here. Would it make sense to break up the pull request to smaller chunks. I don't know, like, if they are not depending on each other than maybe we could like discuss one or two terms, come to an agreement put it up in a pull request if anyone wants to comment in the next I don't know week or two they if there are no objections just merge that one and then move over to the next month so we don't have to nurture one big full request and chew on it for months. Yeah, that might be a good idea. The problem is that they do enter late some of the terms. So, and to an extent it doesn't matter, you know, if we resolve issues. These are many pull, many issues right if you resolve a conversation that's resolved so when it's finally done it'll be merged. But nobody is putting a gun to our head and saying merge it right now so it'll be, it'll be ready when it's ready. Yes, it would have been nice if, if in the beginning I could have divided in into multiple, but they did come as a set. These are the terms are interrelated and they refer to each other so it'll be kind of weird if we accept one and not the others. And in any case, it is what it is at this point. Yeah, no, no, it's a good point and we did discuss this last week and, but yeah, we are where we are right now. All right. I agree with separating and there may be a point where we, we want to accept some of the stuff and I guess it doesn't matter we can come at this different way I may come and take the ones out that we want and create a new PR. I think we're out of here. Kubernetes, we agree on that one. Sure, I don't think that's how you don't have to go back and split it up. But if anyone else wants to split any of these similar to what we're doing with the 5G, then we'll do that. And my computer is just freezing up. I think this whole request is that people came in and did other edits that have nothing to do with my original pull request. So for example, Kubernetes I did not touch that. But other people use my pull request to continue doing at it so it kind of a little bit grew out of control here that's true. That's true. And I guess from that standpoint. You could always say I don't want any changes and then someone else can come in. Not saying that you're actually communicating that but anyone putting a PR. If you're working on it and you're like no, I disagree. That's fine. Someone else can come and copy everything and make the changes in another PR. Similar to open source, fork it and do what you want and put that forward. And then in the end, as a group will decide on which direction we like. I want to bring this back to just the discussion on the main items that were problematic. It's what Tal you were pointing at the different approaches to defining network function. This one, I believe is what you originally put forward. I don't know if it's been modified. I don't think it has. I think this was what you had for a CNF. True. And it's a very small edit over the original. Yeah. Yeah. So I don't think we actually had a CNF defined in the terms yet. So you, you were putting it in. It was, we had it somewhere else in the, in there and you pointed up to the, the global glossary which is new. So that's fine. And that's good. The, my thing which I was pointing here with regards to network function is when people are coming to this group, particularly, so if they're looking at the group, they're looking at best practices and other information that we put out, then they're going to go Okay, so y'all are the cloud native network function working group. So what does that mean. Well, that means this. Okay, it's a network function. Okay. Well, then what is a network function. So immediately they're starting from the point of your group is about cloud native with, you know, these, whatever this, it's a cloud native application. That's what it says a cloud native. It's a cloud native application developed using cloud native principles, and it's a network function. Okay, so that's must be. I'm without knowing anything else I guess that's a type of application because it says it is a cloud native application. So now let's actually go and see what a network function is. It's a functional block within infrastructure and maybe components of network services. So this doesn't to me sound like a just a regular application. I mean, there's a lot of there's more terms what is a functional block. What is network infrastructure. And I think the very last one I put in two commits so we've had a long discussion. I'm not going to go through all this someone wants to, if you're interested go read it. This is really the last part to relate to the current CNF definition that you proposed. So trying to phrase net that definition for network function to be related and application providing a unit of network functionality. To communicate what do we mean by a network function or functional block. So it's functionality. I don't think we need to define that and network there's potential I know there's there's some debate around that but let's say network functionality. The network function now that we know what it is could be coupled or decoupled from the underlying hardware and I put this because there was a lot of discussions about whether we're saying it's virtualized or not and all those so trying to and whether you are directly still requiring hardware. So it, it tries to keep it open to a lot of cases. But it's not saying it's cloud native. The network functionality may be provided directly as a network service or be components of larger network services. So, Frederick's bump in the wire firewall. I would say, which for those that you haven't seen it's there's a discussion item, and you can go look at the diagrams that you had. A bump in the wire, small transparent firewall can be providing a network service and it's a singles, it could be a single small network function or application that's providing that service, but it also could be one component of something much larger like maybe the convergent charging service and a 5G mobile core, and you're going to have a lot of different components but say okay this whole thing is what we're saying is the network service that we're providing. But it contains a lot of smaller components which could run standalone they just happen to not be. So the idea that was to build something have something that relates to your CNF definition. It's fine I feel like this is network function is not very controversial. I made the point here that you know in the end some of these terms we don't really own. It's, you know we're not going to find the best definition of network function in our group we're not the right place to do that specifically. It's something we accept as a given network functions are used these terms exist out there. So, I, somebody commented that we might as well just site Etsy or someplace else. That could make sense. In the end these terms should be useful for us so so Taylor we started with this user story of somebody coming to this page from outside and not knowing what a network function is. Who's that person. Yeah. So, again, let's start with. Let's commit the definitions as necessary one by one that we are not arguing about cloud native network function oddly we seem to have settled on even if we can't define network function. It would be nice to have a definition for network function, but I would live without if we've been quite honest, and there are a handful of others so if we can go through them. And I'm sorry tell I know this falls on your head and I know you very much tried to do a good job here and get everything done. But if we can try and get them done just one by one in from least to most controversial that would be forward progress whereas at the moment. This is a very much a monster comment fest. And the discussion has been useful but it's not going to conclude as a whole in a while. So, maybe you can do this in peace wise. Sure, I'm not sure really what to do here I mean I can just click resolve conversation when I feel it's resolved but I think what you're asking here is to get some sort of agreement among committers for it which I'm not really sure how to do do you explain me to reach out to them personally or what do you want to let me take an example. If I took the definition of cloud native network function that we have my through in that it doesn't mean containerize because I think that's useful context if I took the definition of virtual that function that we had, which I think became quite clear and the discussion did help clarify it. Would anyone throw their arms up in the air and say that's wrong at this point. I'm not sure I'd have to see that when I feel like the virtual was also good and the cloud native and I will agree with you on adding. It doesn't mean containerized that I think those are good, but I disagree with strongly is trying to use an existing definition from other groups, which don't have actually it's an entire Etsy standard if you just want to go to that. So it's not one line. It's a large set. So there's a whole understanding there and I disagree with using it. It doesn't help with new audiences if we want to get them involved. I wasn't asking that question. I was simply saying, there are incontentious and more contentious problems here. The uncontentious ones can't we get shot at them so that we can focus our attention on why we have problems with more contentious ones because, you know, the fact that we're having this, you know, we've gone from point to point to point down this means that we're not committing any of it. Okay, so just focusing on how do we do the others. So, I don't think that there's a problem. Let me look through other than yet so virtual network function, there is no contention right now on this definition physical network function. There's also no contention. The last comments, if you read through these, they're just general conversation and nobody is specifically saying let's modify physical. I don't know. I haven't looked to see if who said to remove or not, but I think we should remove cladified. I don't think it helps. So let's see containerized network function. I'm going to interrupt Taylor but we're at the top of the hour I think. Yeah, I'm afraid we do I've got to move to another meeting as well. Again, I might my request to you all is if we can work out what is not contentious and put a pull request in for just that, so that we get it done. And if there's anything else that is contentious then, you know, the subset of interested parties can argue to the heart's content but other people can work with the definitions that are actually, you know, foundation, honestly foundational to what we're trying to do. So it gets moving forward. I'll say I'll resolve network function I'll just take your definition Taylor because I simply don't care I don't think it matters how we defined it so if there's something that you prefer. I'm very happy to give you that cladified network function is more complicated. Let's discuss. Okay, that's it. So anyone that wants to read. Those are the two to go look, look at if you want to put a plus one tell on the network function. There's two grammatical mistakes that I'll just fix but I'll fix them. Yeah. All right. Thanks everyone. Thanks. Thank you everybody. We'll see you again next week.