 Good morning. Good afternoon, wherever you are. Good morning, Taylor. Good morning. We'll get started in a few minutes and Ian's leaving today. He should be joining any minute now. Morning, everybody. Good morning. Right. It's five o'clock. It's time to start. Okay. First question. I know what my vote is, but I see we've got a holiday coming up. The Labor Day holiday on the 6th of September. Anybody feel that they want a meeting on the 6th of September or that they don't. Being as the agenda is empty even for today. It seems obvious. Right. Well, we'll take the, we'll take the skip. Okay. Good, so all right. We're good with that. Lovely. All right. Standard thing that keeps coming up. Kube common ONS in Los Angeles. I don't know who's going and who's not, but we do have our deep dive session on the working group itself. If anyone's got any other sessions, they think are going to be relevant to members. Then stick them in here so that we all know what's coming up. Yep, it's it's there. Don't forget about it. We also have the Mobile World Congress Los Angeles coming up at the end of October. I have no idea who's planning on going to that even but if again there's any interesting things going on there that you think are worth letting the members know about then do go ahead and tell us what's going on. I do have a general question about KubeCon. I've had, I've never had luck with KubeCon right now I had two different talks that were not accepted one which was a joint talk with Ericsson. Any insight about you know how KubeCon is willing to accept telco I have a feeling they think oh the telco stuff should go in oh and yes. But that just might be my guess. I really don't know. Does anybody here have some insight. It's always been really difficult getting telecom talks into into KubeCon. So your experience there is not is not isolated. Yeah, I think you have to remember that KubeCon's audience is very very broad. So, you know, we're always a disadvantage they're talking about very small subset of users compared to the entirety of what's going on. Mind you you could have said the same of OpenStack and OpenStack at least we used to manage to get talks in. So I think the terminology is a block or two. And I've seen a few of the submissions that that it looks like it would go into O&ES. And I'm guessing OpenStack being that there's a lot of development that was happening at the time you'd have known terminology. But if you have someone that's doing reviews that doesn't even see where it fits in. Yeah, well I also KubeCon's twice the size that the OpenStack summits were even at their peak so again it's much more overloaded with talks I think so they're looking for broad appeal to try and you know get to as many of that audience as possible. O&ES obviously is much more focused on specifically the users that we care about, but obviously less focused on specifically the software that we're dealing with so it's also an odd combination but that's where we stand. Yeah, I mean I totally agree. And I don't know that I don't know who does the reviewing of talks for KubeCon or how they select that panel. Perhaps next time round we try and establish that a little bit earlier or maybe maybe get our fingers in the pie and get a reviewer on the panel. That would probably get us a bit further. Yeah, so I've I've been a part of these particular of a couple of these things for KubeCon and they usually will pull between six to eight people through the industry to do a vote and then they'll get two people to chair it, who then do the the final selection, but generally there is a networking track, but one of the things they did they did historically which should help in future KubeCons is they finally split service mesh from networking. So networking would only have would have a relatively small number of available slots and then when you mix it in with service mesh, it was pretty difficult to get anything that was actually networking related into the network and track. So I think there are some things that can improve but they do have a, they do have a process for for feedback on some of this stuff so I would recommend that we develop a little bit of feedback on some of the things that we're struggling with and respond to them so that we can get a better structure in the future where we can, we can get talks and that are related to to this particular industry. So as I'm on the inside, what have you got to say in the subject. Yeah, so I dropped a link in the chat talking and this is from the latest KubeCon, it's talking about the selection processing kind of like all the numbers behind it. I think what Frederick said is like also true that it's. The numbers, the acceptance rate is low but I think it'll be helpful if they split out now that like service mesh and networking are split out because they're two very different topics. Okay. I'm going to keep that for later, later examination, but let's see. Right. So the ONES obviously is a better target for the things that we're talking about in in one way. So, again, I don't know if anyone knows speakers at the ONES or specifically relevant talks, but again if you want to get them a bit of free advertising then make sure you tell us what's going on. And we will keep an eye out for that, then we can go and heckle. I also don't know how many of you are actually planning on attending in person and I suspect anyone's plans at this point in time are subject to change. Speaking personally I'm likely to be out of the country at the time that it happens which may have been arguably poor planning but we'll see how this works out, my plans might change just the same as everything else. Okay, since nobody wants to talk about anything else I stuck in a note there about least privileges because Taylor and I have been riffing on this for a few weeks at this point to try and establish the whys and the what's. We've got the review already out there for the best practice. But the best practice obviously didn't have any justification it was just here's the best practice. And we'd like to have use cases that speak to best practices. I'm not sure the document we have is exactly a use case yet but it is a wide variety of thoughts on the subject, and I have a link for it. I hope. Maybe that one. Yes. So, this. Taylor you said you've made that public did you. Yeah, this is in the same effort and Google Drive. Right, it's got all of our notes from from the various meetings we've had, because we've been talking about this sort of offline for a few weeks at this point. But we tried to break this down to at least some of the whys and the where falls. I think what's clear here is this isn't a use case in the sense of this is a specific thing that a telco would want to do. It's more a use case in the sense of these privileges and accept it is a widely accepted principle for the purposes of security, but also stability. And we were trying to basically frame that up into in terms of the advantages it would bring in the specific problem space that we have. And the reason that the problem space makes it difficult to to deliver. Based on the fact that we're doing specific networking applications and they bring a range of problems where privileges often called for. To begin with, these privilege. The reason I would suggest that it was, it's important is because if you're trying to work with a platform and a selection of applications, then you break isolation if you give any of the higher privileges that are going on what, you know, we would call a privilege container is obviously a privilege but it's only one form of privilege we've talked about root users in containers as well. Both of them. Well, specifically the platform privileges tend to break isolation between applications and application platform. And if you do that then you start to lose the sense of a boundary between components and without a boundary without establishing what a component is trying to deliver. Then you run into the difficulty of working out where problems arise when they come up. It's a privilege application and it's got power to change all networking in the system, and then my basic CNI calico, whatever stops working. Then do I call the platform team because calico is a platform component do I call the application team because the application could have broken calico. If I call the platform team how do they establish that the application didn't do anything untoward that led to that breakage. Least privilege basically isolates applications from each other and from the platform to the point that when you have a problem you can point a finger at a team and say, this was your component you were responsible for it you are the one who will be able to fix it for me who will be able to find the problem as soon as possible. So I think that's an important reason why sticking to the least quantity of privileges necessary to get things working is beneficial protection. I mean this one's the one that's been coming up in the, in the use in the best practice more but it's only one part of the problem protection is basically saying that if problems arise then least privileges a means to stop them from, you know, a small security breach to all of your customers basically being sold on the dark web, which apparently is a popular hobby at the moment since it's happened to see two service providers in the last week. And yeah, if you try and keep components within their boxes, then there is much much less likelihood that they will get to data that you thought was well separated from from the box that's been compromised. I think we've established previously that these privileges hard for us to implement. There are a lot of things that we want to do with networking that tend to lead to asking for privilege, particularly capsis admin as one example. But other things are set up in such a way that having root privileges over the containers file system is, you know, necessary to get things working. It doesn't mean to say that those things can't be fixed by relatively straightforward means but I think we have to establish to begin with that they do need fixing that simply grabbing the root user and having right right access over the whole file system, or file access over the whole file system is is a dangerous thing and not 100% necessary to making your application work. So basically, educating developers, and I think developers here are one of the larger audiences for this educating developers that there are options available to them that isn't a blanket statement that oh yeah just grab privilege because you know you'll never ever be able to work without it. I've been out some of the things that came to my mind and Taylor as well I shouldn't take all the credit here for problems. One of them is performance, the performance of an application in a networking world is tied up by the fact that you've got a lot of packets coming in on a regular device that you have to get rid of before more packets come in because you know the world doesn't start from traffic doesn't wait for you to process it. So there is a calculation here that I've done in front of people many times before now within my company and two customers that I work with, but I thought it was worth writing down here. So it's a very academic thing to consider in the sense that you know yes I have to basically do numbers and make calculations and you can rework these calculations for yourself if you want. But effectively, we are not serving websites where a user will you know accept anything that turns up within a second. So moving packets and if packets don't get moved in milliseconds then packets get dropped. That isn't the level of performance that platforms are typically optimized for because that isn't the level of performance that anyone else requires. They almost certainly won't say no, but it's never very high on their shopping list to get things turned around in half a millisecond. So that means that you can prioritize your components to the tuning of the application and it typically means that grabbing high level privileges so that you can prioritize your components over your most critical components are is, you know, often seen as necessary. And then a wide raging list of networking behaviors. I'll explain this in more detail and if I sit here and talk through the entirety of the document, you're all going to get bored with me but those are the ones that have a section in this document at this point in time because they tend to be the ones that come up that we've at least in many cases previously discussed in these meetings and in the chat to say that these are reasons why we grab privilege because we're trying to do things that are out of the ordinary again. But doing them requires us to lay hands on rights that aren't necessarily well widely available to Kubernetes applications. In summary I would say that it isn't so much that you can't do these things in Kubernetes it's often that using those platform grade privileges is necessary because there isn't a finer grained way of getting exactly the right you need in order to get the task done. So if I, if I want specific fine grained scheduling behavior I have no way of asking for that for the platform from the platform and the platform offers no concrete guarantees that it will happen as a matter of course without asking for additional behavior. Now, we discussed this last week STP as an example, typically has a kernel module that you require in order to enable it. There's no guarantee that the platform in actually loads or includes that kernel module and you were saying that in fact in your case, you don't like to include it because you consider it to be a security concern. Not me personally but Red Hat. Yes, true enough. I am judging you by the company you work for. You can always leave if you don't like standing for Red Hat on the call. So it's often the case that what we're trying to do here isn't necessarily impossible. It's just not practical in the current world that we live in. It may be that certain areas of the platform need enhancement to make this, if not, you know, not just possible but beautiful elegant from an application design perspective. And I think that's perfectly acceptable to say no one's saying that Kubernetes is is polished and perfect is never going to change. But yeah, without setting down some ground rules like as an STP is an example that all platforms would load that module and include it. Or alternatively that there is a means to ask for the level of functionality that you're looking for, then you get into difficulty writing applications that consume it. Again, I can talk and talk and talk on this. It's an interesting topic, but this is a meeting where you're supposed to do the talking I'm supposed to chair it so I don't know what your thoughts are on this, or whether you want to give this document more study either now or later on and see what you think. So I read much of it and I think it's a great document this is really useful. I like these detailed discussions because there's a lot to discuss. You know, if we scroll up I think the two aspects you identify that the principle gives us which is isolation and protection. Well, least privilege does provide those but if those are our goals there are other principles that can provide that right if our goal is isolation. And say we do need to use I don't know the root user for some reason. Maybe the trick is not to think of it in terms of least privilege but in ways of how can we increase isolation so just an example is caught the containers right that's or or Google's g visor. Right there are, if our goal is isolation and we can't achieve isolation using least privilege maybe there are other things we can do. So isolation and protection as I keep pointing out the whole field of security is far far more than this principle right so there's a lot of ways to achieve protection and all the things that that are mentioned here you know in terms of I guess I'm saying these two topics isolation and protection are worthy of discussing in and of themselves without connection necessarily to this principle. I wouldn't disagree with that I was trying to find arguments for least privilege not arguments that these privileges the only way to do certain things. Yeah, absolutely. What we want to end up with at some point is here is a practice that someone can implement. And we can get to the many different practices that you can have out of, especially if you said we want to follow security practices well that's going to be a wide set so we're trying to narrow it down so that we can end up with some. But it doesn't mean as a group, we must focus on least privilege and we must focus on non right. That's just the first of many things. I mean, taking up your points about cat containers and G visor, then the question would be in both cases. The experimental method here, which is why people not using these things to influence CNS, which I don't think they are, I mean I certainly haven't seen it. But if they are the right thing to do, why is it that it's not occurred to anybody. Could you implement a CNF with them. So, you could take that forward and ask yourself from an experimental basis what's putting people off from a practical basis, sort of tied to the experimental but more more again academic in nature is. Can you implement a CNF with either of those technologies, is there something that completely forbids you or prevents you from, from writing a CNF using those technologies and certainly it's not going to be as easy there are certain hurdles to overcome, like the way again in which we access the network, could you access the networking with either of those technologies in place. But those are topics, again we could explore independently. The point is correct though that both isolation and protection, you could ask yourself for something that nominally provides isolation or protection. Is it a reasonable option to give you a better platform than the one that we're currently looking at. So to keep it on topic of you know in this specifically privileged principle. We're not talking only about not using root user that's one way to reduce privileges but for example to make sure that all your files are right protected or you know that the, the, the mod attributes are all you know just for your user things like that there are a lot of little things that you can do that are easy. Right. It's different than you know wanting to. So I guess I'm separating there's the notion of the privilege keyword right for pods that makes them privilege containers. But we're also talking about a general operating system privileges right right. This section is the general tell right if. And can you scroll down to the section Thursday June 15. She could also find the left, but yeah, there we go. To tell this section has a whole list of potential practices that are all somewhat related to this area. So no written container or just be one that we picked right now, running a container with the privilege flag, or not running it would be another practice. But there's a lot of different ones pod should not mount host directories as volumes or these are just practices. And we have them. If we don't need to go through all these sections but whoever wants to read it. The other sections where we're talking about police privilege or non rude or whatever a topic may have thought may have come up like what you're saying, Tal and saying, what about this and this will write those down. The, this principle of police privilege is the general. Yeah, probably end up with a whole set of practices that reference, whatever this is called we did. Like, Ian was saying it's not exactly like a user story right now, we may end up with some user stories in it, but it's, I think what we're going to probably have more than that is a write up around the, the general principle of police privilege. So we can have a whole set of practices that come out of that and maybe references to other, other topics around isolation and protection now, we could have those just reference to other documents. Isolation itself may be like a focused use case on the need for isolation and protection. I mean, you know, because you've seen what we've been presenting over the course of the weeks you'll notice that we've been working backwards, pretty much from the beginning, right. We should not use routine containers therefore there's a reason for that and we should figure out what that reason is and so on it's kind of. There's a strange way of approaching it but the problem is that you kind of, I would say as a developer I the idea of using the least quantity of privileges is is ingrained in what you do at this point in time. You know you should. Sometimes it's a little difficult to articulate the reasons why you feel that's a good thing so you know because it covers a whole bunch of stuff so having. You know routine containers, you can see, if you follow the timeline up from this meeting that we had a couple of weeks ago, back upwards then you'll find well it's right okay so that's one point of least privilege. What other least privilege practices amount to, again, least privilege. Here's a long list. And it's like okay well now let us work out the broad statement of why these privileges sensible, which is the document that we, or at least the skeleton that we have in the latest Brown that we were discussing which literally was half an hour ago at this point. To get to why these least privilege rules are actually being helpful. But yeah I mean, it's a broad topic. And can I point another interesting tension here that I think it's pretty obvious but everything we're seeing on screen right now which is a great list. There's probably even more things we can add, but it's none of this is specific to telco this is just good. This is a good principle for working on Kubernetes. And of course, much of this document to we deal into well the specific requirements with telco with networking etc. It's attention here right in a way this this part shouldn't be worked on just in this working group that these kinds of this idea of how to apply the principle and tips for doing it are general tips for Kubernetes right this shouldn't be owned by our working group to an extent. But then the telco requirements have to do with well sometimes we do need privileges. The telco requirements I think emphasize the need for security separation least privilege, because, again, we've got requirements on performance where privilege will mess up any guarantee you can promise. We are, and I know you've debated this particular point as well but the general assumption here is that the platform is separated and supplied by someone different from the application, which isn't generally true of applications in the wider world There's plenty of application teams and again we pick an open shift here but I think you'll find that people paying for platforms from third party vendors are often then developing that you know they're the application team paying for the platform, not an independent they're paying for the platform and an application from two vendors which is the concept that we're kind of expecting in the world of CNS. And also the idea that we're running multiple applications from potentially multiple vendors and or development teams on a single platform. So these are the things that emphasize the requirement for least privilege over and above what other people might see but you're absolutely right that most of these are best practices they're just not so emphatically useful in other people's problem spaces. I'm not quite sure what to do with that though because we tend extent I kind of wish this list what we're seeing on screen right now would be open to other members of the Kubernetes community I know that's very huge you know other industries that are involved. This is an area where you know it, it seems perfect for collaboration I have no idea how to manage that exactly. I wonder if it's in the general topic of the Kubernetes security, right, I think there's a secret for security. Yeah, and if you look at what Falco is doing then it's quite interesting. It's more on the auditing the first do it then check it kind of side of things but absolutely it's clear that people have looked at this sort of thing before yes. Yeah, audit and remediation, like if you start a shell in a container not expecting then it can kill the pot as an example. Yeah, which you know trust but verify is a perfectly good thing. But firstly you need to know what you're trusting them to do and I think this is again maybe not the entire set of rules but a set of rules that's quite useful for that. So, well, that it that being the case then we're all basically talking without necessarily close insight into what's happening in the security community. Does anyone assuming that none of us are actually there then do we have any contacts over there that we go and sort of pick the brains of. I go to every one of their meetings and I'm involved in that space so if there's a specific thing you want out of my group I'm happy to make introductions. I think yes I'm not sure it's specific I think it's more a general question of how we could benefit from their learnings, assuming that they've gone studied this rather more directly because it's their immediate focus then I'm thinking that as tell says there's probably more people out there and more to the point this list is not just for us necessarily. What I recommend is, you put together a short talk maybe five to 10 minutes worth. Put it on, put it on their calendar, the way you put it on their calendar is by opening a full request against the, against the security technical advisor group and give a talk and then ask for ask for help and see what they say. Okay. Let me get some minutes written up but please keep discussing while I type, don't let me stop you. The, the two people you can actually three people you can ask for help there. The first one is Emily Fox, the second one is Brandon loom, LUM. And the third one is Andrew Svega, and any one of them can help with. We're getting involved with that community as well. And Andrew, who. So, Emily Fox, Brandon loom, LUM. Third person is Andrew Svega, and one M on. What's me for LUM it's just one M. Perfect. And Andrew Svega is involved, he works on as fire and spiffy stuff. They're project wise on the sick, the tag security. You have folks that are working on Falco, which is the was originally from sys dig security company. They. It does run time. Security checks as well as like pre checks. The people from the open team. Are also on that. The tag security is one place we could also reach directly out to the projects. Test suite. We're actually trying to talk directly with a few of them because we're wanting to get. Utilize the tools for testing specific things. Falco has a. A privilege like the non root user checks. Checking for any root user and any process for all the containers running. Yeah, yeah, I don't want to limit this to exclusively run time checks. I think if we can get static analysis. As well, because static analysis is. If you spot something going wrong at runtime, it's too late because whatever you're running is probably not going to deal well with you just murdering things when it thinks it's about to get started. But yeah, we need both parts of this. So they've also published two white papers one on cloud native security and the second one on supply chain security. And there is a security controls group that let me say I can find the spreadsheet for it, but in short they have a spreadsheet that they're developing it's not finalized yet. That goes over the variety of different security controls. There are the purpose of that one was initially so they can give two groups like auditors or people building baselines so that they can work out. A lot of a lot of people who are who are in that particular chain are not Kubernetes experts and so when they say something like is data and transit encrypted. It's like where do you start. Or if there's, if there's a policy saying you must have firewalls, and then you're running Kubernetes and there's no firewall on the edge of Kubernetes. Then why is Kubernetes sufficient. What controls are there that sufficient that could help replace a firewall, which might be your ingress controllers or other similar types of things. So there's so there's a security controls group that is relatively new that is also putting things together it'd be good to go over the documentation that's been produced by that group to see if there's any other security related things that we could tie into it. Yeah, and I think you have to be careful with some of these statements because, for instance encryption in motion as an example is widely counted as an answer to security problems. But it isn't always appropriate, depending on what you're doing if what your main job is is to move traffic as fast as possible with the least amount of CPU and encryption and and the traffic is moving over a network where it's mostly not encrypted before it comes to you then encrypting it, you know, between your components as an example gets you absolutely nothing. What I'm saying is that all security rules, you have to put into context they don't necessarily apply just because they've been written down once. Absolutely and that's that's something that those groups are very aware of, but it's how do you articulate this in a way that someone who is not in that particular field. We actually see this problem in the zero trust space quite heavily. It's like, you have one camp that says why do I need this. We have sufficient defenses already and then you have the the opposite camp, which is literally, wow, I can put dates, I can put dates in every single component of my system and check them every single time for every piece of communication every, every moment of every day, and which then you end up with extremely high granularity of or unit with very fine grain controls, but you also end up with something that cost so much from a from a runtime perspective that you end up killing your availability and your cost goes through through the roof. So, and then there's a wide spectrum in the middle, where there may be trade offs you can make on either side that land you into a secure or not secure but into a more secure stance than we have today without sacrificing security or cost, or honestly maintainability because obviously encrypting everything gets you less and less insight into what's happening every single time you do it but yeah that there's always trade offs in this. Well, actually, that's the wrong thing to say there aren't always trade offs in this the ones that we should be recommending as best practices first the ones where you're actually not trading anything. Yeah, and you have to look at what's called the residual value at the end of the day, which is, what is the thing you're defending. What is the cost of defending it what's the value. When you put those two of them together, and like what's the remaining value of that information or data or so on. And so it very much people think oh it's just a technical thing know it very much ties into a business and if the security costs that are required to put in exceed the cost of doing business then in some scenarios you may even ask should we even be doing this in the first place. And so, or you maybe you, maybe you go back and try to work out why is this thing so expensive, because maybe, maybe there's a better way to do it or maybe the value the place on something might be wrong so we have a lot of different places you can look at that in short, all of this ends up tying to to the business at the end of the day because some business leader has to make a decision on whether or not they accept the risk, whether or not they accept the cost, or, or other stances that that are other types of actions are present. Okay. So, next steps. Who wants to prepare that time any briefing. I think we can safely answer nobody. Well, to be honest, the document that you and you and Taylor created is a great start, if it can be boiled down to a few slides. I think if we could focus it from away from here is a shopping list of things that we would want to do, because frankly, I think we'd be teaching granny to suck eggs at that point and keep it to the high level of why it matters, or what is most important in a telco space which they might not have considered, then that would seem to be the way to present this we want to be teaching things they don't already know. So yeah, by the way, that together in the future and maybe this is something we could do through here I would like to eventually do a more depth talk there. That discusses things like the various 5g protocols and the security deficiencies that exist in some of them. And that way that people become informed and they can then become part of that perspective so, for example, the, the, the 5g user tunneling protocol that we end up using ends up the whether you're logged in or not is a bit. This user has been successfully logged in, you set it to one and then the gain access and unencrypted. So, so, so the protocols themselves need to have something else that's that's attached to them or there needs to be some out of band thing. Or you accept, like I said, you can always accept the risk. And that's a good idea and that is probably not the idea. But yeah, in short, it would be, it'd be good to raise some of these types of things into those environments because then the, the, the security community at large could then brainstorm ideas that we could effectively do in the environments that would move Kubernetes from being just a hey, we can run this at higher density and lower cost, presumably lower cost to we can run this thing with all those benefits but also get a more secure stance because of things that they would bring to the table. And that would be a very powerful message to push forward to the latest environments. I would, I'd like to get this first best practice put forward with maybe a write up on the lease privilege that we understand into the get up repo. And then we could present that to tag security and say this is we're trying to apply this to networking applications and take all of these recommendations and put them out there, and then ask for their help on that, so that we can say we're taking steps and would like to get your input versus not having a, any type of a finished thing and saying we're waiting for you to do it or something would be different. Okay, so I think we could probably do this in parallel to see how it works out, we can get this right up framed documented committed. And in the process of getting it framed documented committed we could be writing up a few slides for the 10 minute presentation, see how they come out as a pair rather than necessarily saying one then the other. Would that work. Yeah, I mean, definitely write up, like, would do a presentation and sure like, what are we doing, what are where are we trying to go, and then, and then actually give an example of here's one that we're working on, and we've published. I'd like to add more and get your input on the ones that we're doing. They can happen in parallel, the work can happen in parallel, and I'm happy to help with presentation as well as. Yeah, writing five slides is going to take us very long, I think writing five, the right five slides might take us a bit longer but if we, again if we. If we make the attempt we'll see how far we're getting we'll see whether having any success. I haven't read the document but one thing that I noticed is, I haven't seen any examples of you think that it's important to have is one code example or something to use a way to exemplify. Is it the best practice or something or you think that the way that it is is good enough for anyone. I think what you're asking for is effectively the best practices that this suggests. Yeah, I do think having examples is a good thing that look here is what we often see a in practice here be is what you could be doing and here is how to get to be. Yes, absolutely. It sounds like a best practice because then we're making a recommendation of you should do this. But yeah, I mean, I agree with you. Examples are great and that's what we should get to we, if we write documents that are not comprehensible, then obviously nobody's going to use them. So, the simpler we make it the better it will be. Right. We have nine minutes remaining. We've talked about this. There's nothing else on the agenda, but I wanted to throw it open to see if there's anything else people wanted to talk about or any work they've been up to that they would like to kind of mention here. I've started working on my discussion for a networking orchestration but nothing that I'll show public quite yet. It's still very early. I'm really interested in that and I very much like to see that as soon as you get the opportunity or as soon as you basically have something that you're not going to cringe with by every time you present it in public. I think that would be worth doing. Anymore. Okay, one thing I think that came up in passing there's something Frederick mentioned that, you know, some of these things are probably worth a, you know, could benefit from a technical presentation of however long. We kind of get tied up with the idea that technical presentations have to go into Kubecon and therefore we can't get into Kubecon so we never get to make our technical presentations isn't upsetting. In a world of being online and working from home all the time and wondering whether or not we're ever going to be allowed to attend conferences again anyway. We can do technical presentations whenever we want right we can basically have someone make them set a time for them record them. I'm sure Bill and his team will happily put them on YouTube for us as well. There is always that option we don't have to wait for the perfect moment. So, if there are any technical presentations either people want to give, or they want to receive, then I suggest we start making a list of things that we might be willing to, you know, put ourselves out there for an hour and actually produce. If you really want to ask on that I was looking for a tug presentation, and I couldn't find it on YouTube I think YouTube hasn't been updated in quite a while. I expected that all these meetings were automatically be added but I guess it's by request. I can check or bill if you want to check that some of the people that we're doing that we're out so they're just, we may have like a queue needs to be worked through. If you have a specific, if you can go back to a specific date and request, like say, I don't see this one. Yeah. Okay, maybe I'll check again. Thanks. Yeah. Well, if you don't find it tell them just reach out and give the specific date for and whether it's tiger. We should I reach out to bill or are you either one. Okay, thank you. And we seem to have come to a natural pause if no one's got anything further to add then I will give you five whole minutes back so you can run to the bathroom before your next meeting. All right. Thank you very much everybody and I'll see you again next time, which should be next week shouldn't it we that's the week after next. All right. Next Monday. Have a good week. Thanks everyone. Right.