 Hopefully that works a bit better as my audio working now. Yeah, we can hear you. Oh, good. That's good to hear. We seem a bit thin on the ground but hello everybody who's actually turned up nice to see you all again. There we go. Apparently we're all doing at the same time. Right, yeah, so let me just get through the agenda as we have it. Right, so we have a set of upcoming events, which you've probably all seen already at this point. So I'll just recap very quickly. The European version of coupon is due in May. I don't know where we stand with the call for papers but I would imagine it's ended at this point. So for the open source summit in June, which almost certainly does have a call for papers I will go and do my research after this and at the end of those deadlines in the European open source summit in September and coupon and a in October. Practice applies if you've got anything at any of those events that you're putting in or that you would like to make people aware of once the schedules are announced then do tell us or add them yourself to the meeting minutes so that everybody knows what's coming up and what's worth doing. Oh, we do have a call for papers a little there. Right, yes, so the cloud native telco day there at the coupon EU so if you've got any papers to put in before February so that's about what four weeks left at this point. Then we will check the pull request and see what we have in the web pull request, because I'm running the meeting and it's my pull request will open mine first. So the idea of this was basically. It's a how to do the paperwork side of things. I wrote this up with the specific idea. I see we have no comments to speak of. I wrote this up with the specific idea of the best practice but here's how you document the best practices you are compliant or non compliant with because the concept I had was that if you want to be compliant with all the best practices there may be solid technical reasons why your CNF your platform your system can't be compliant for some way maybe you have a better way of doing it or just simply a different way of doing it, maybe it's something you haven't gotten to yet. If you are, for instance in my position, supplying a CNF to somebody and they're giving consideration as to whether to run it it may be acceptable that you aren't compliant with best practices, but it's important that you have a record of what you have and have not done so that they can review it and see what they've done. So you can document. Obviously, a best practice that you are compliant with and any details of that compliance if it needs to be written down, but you can also document a best practice that for some reason you can't currently be compliant with and the consequences of that lack of compliance. So it's more in the nature of paperwork around documentation than it is about, you will do things in, you will build your, your application or your system in a certain way. I haven't done reviews yet. I encourage you to have a go at the reviews skim it for yourself make sure you get what I've written what I was trying to get at. I've tried to keep it short I wasn't trying to make anything particularly complex just simply have a means of supplying that record, so that everybody can review it on their own part as they're trying to build one of these CNF so platforms or whatever and so any comments on that any thoughts. Okay, fine, we'll move on to what else we've got. Dammit. Ian, this is Oliver. I generally understood what you were saying I guess I wasn't really clear though, in terms of where, where is it. Well, I tell you what I haven't read it so I guess I was trying to understand how, how is this to be used, but maybe I will get that after reading it so. Yeah, and honestly it's so long since I've written it I can't remember what I wrote. So we're both having a problem here I think the simple answer is to give it a read. The conceptually, my point was that for a component in a system like a CNF or your Kubernetes platform or whatever, then if you for whatever reason can't be compliant with the rules, then it's better that you write it down and make that abundantly clear and say, well you obviously can't say we are compliant with the list of best practices. So it's better that you document how well you've done and what you've missed. So that when you try and, you know, if it's an open source project when somebody tries to consume it if it's a closed source product, then when somebody tries to buy it they understand what they're getting into. So at a system level if you're at a telco and you're trying to build a system, then when your auditors come along and say what from the best practices have you covered and not covered then again you're not trying to somehow scrape together a statement of compliance from components that simply don't comply, but instead you're actually just cutting it down on a piece of paper saying, this is how well or badly we've managed. You know, the assumption here is that with the next version or whatever, you've got some updates and you would, you would improve upon that compliance and while you're not compliant then you might have mitigations in place. So if you can't for instance make or use a CNF that's fully compliant with all of the security best practices then you might put other security practices in place to manage that non compliance. You know, for instance, if you can't make it as impossible as necessary as practical to break out of a container, you might put something in the platform to detect breakouts as an example. Okay, thanks for that. I'll have a I'll definitely have a look. Yeah, probably better read than me trying to review it for give you the clues from memory because again, I wrote this before Christmas and it's been too long at this point but it's there to be looked at. Thanks. Right. I actually haven't read this one either. I'm not going to do a very good job of this and it looks like nobody else has for that matter. Oh, I tell a lie, Olivier. Yeah, that there's one or two reviews in there. Yeah, so the aim here was to describe how user stories or stateful CNS work. Particularly, things that have to live beyond the life of a piece of software. You know if the software is upgraded rebooted restarted then the data that needs to live on beyond that point that could be simply configuration it could be billing records but the aim was to document best practices around that say this is what you should be doing with that so this is the best way of storing it to get the level of resiliency that you're looking for. And again, I can't say that I've had a look through it. I see it's relatively brief so I should have a look through it. Again anyone any thoughts on this at this point in time. Well, use your rules apply it's there. You should read it you should put your review comments in there I'm sure Taylor and Jeff would appreciate it because this is their baby. Right, this one. We do have two comments on this as well and it's also incredibly brief. The concept of this one is. It's pretty common in my experience and I think that goes for Jeff as well, that if you're running a CNF or any network function in a telco network, then you generally don't hinge your ability to deliver services on attachment to the internet. So you're not necessarily pulling software directly down from the internet. You aren't about to go to the internet to see if a corporate licensing server is going to give you a license today. And of course you don't really want to be connected to the internet and certainly on the management side of things. Because security says that an air gap to environment is, you know, infinitely more secure, the one where potentially an attacker can try to get control of your management network from the internet. So this is best practices revolving around that level of disconnection. If you're trying to put software into the network, how do you put software into the network. If you're trying to, you know, share licenses with applications that require licenses before they'll come up. How do you get those licenses to the relevant pieces of software when an internet connection is not feasible. I don't know how far this has gone. And again, I have a guilty conscience this week. I haven't looked at this one either. But I know that was the concept behind it. Yes, by sort of simply reading the high level description that this was effectively an attempt to get people to think on the subject. What it requires is not just comments but actually extension and quite a bit more information than it's currently contains. And I imagine you all have an interest in this. It looks particularly like Victor already has shown an interest in this because I can see, I can see the comments in there. But yeah, further review required so please do again all have a look at this and see how you want to improve upon it. Okay, and that being the end of very short agenda and only 20 minutes in the meeting, then you're now we're up for discussion so has anyone got a point that they want to bring. Wow Frederick with nothing to say that's got to be a first. He's not even responding to that coming. Okay. Hey, hello. Hey. Good morning. I had a pull request that I created that in few minutes ago. So that's basically to integrate some of the key word no test cases. So I was trying to, I was trying to integrate the key word no tool with the CNF test week. I created a pull request but do you not see that here. So, but if you, if that's a pull request on the CNF test suite then that will be in the CNF test treat repository. Okay, this is the word. Okay. Yes, and let's say no can keep me honest here but I believe that group meets on Thursday mornings, and that is probably a moment for raising it. So what I would say and I think we've had this discussion before is if Kavanaugh can be a solution for best practices if you can take what you're trying to do with Kavanaugh and speak about it in the abstract rather than using the tool name, then that's what we call the best practice so you're not describing run this Kavanaugh command from this, you know, run this in your, in your CI or whatever. What you're doing instead is you're saying that this is a problem with this system, and you want mitigations of this nature in place. I think we did have one a while back which basically did describe. You can apply security, such as effectively active monitoring of a system that's running to make sure that you know security red flags are picked up early. But anything that you consider to be worthwhile in any form including you know static analysis or test analysis of something you might want to be running in CI or alternatively monitoring in production. So if you can bring that into the abstract and say this kind of monitoring should be seen in the inner running system because it's an obvious thing to do and without it then you're at serious risk. Then that's the level of description that we're looking for here. Okay. So basically, so you want like a abstract of what what what problem that particular policy or tool is trying to bring right that's what you want correct. Yeah, so you're making effectively your case for Kavanaugh in the abstract you're saying that. And there's nothing wrong with being very pointed about your use case but you're saying in the abstract here is a problem and in the abstract here is a way of making sure that problem doesn't cause you significant distress. And then from there you would say Kavanaugh is a solution to that problem and for these reasons this is a thing that it does and this is how it helps you. Okay, okay, got it. This is we don't. I mean I have no problems with recommending specific tools but I, this should not be you know if somebody creates another tool in the future which is tons better for whatever reason, it shouldn't be ruled out because we picked a tool by name but aside from that I mean the point of why you would want to do this should always be, you know, true. Yeah, sure. I'll work on the abstract and send it over to weekend. Right. Yeah, thank you for that. Thank you. Sure. Okay. Right and I see. Lucina's got a comment on that pull request for you so and pointed you at the relevant slack which I apparently. Okay. Yeah. Grab that link before the meeting ends out the chat that will that will help you along. Sure. Thank you. Anybody else. Or alternatively, would you like your day to end early would you like your morning to start early. Okay, well, if that's the way we're going this morning then I think we'll, I'll give you your time back and you can go and start writing pull request for me. Thank you everybody for your time. I'll see you again next week. Yeah. Thank you. Bye.