 A quick 10-15 minute talk on how you can make workloads an open ship to the rest of your infrastructure, but at the same time secure them in a fashion that it works seamlessly. So let me do a quick, I want to just focus on the 5-10 minute demo, but to set the context, apologies for that, to set the context, obviously in platform-flip open ship everything is dynamic, right? The IP address is dynamic, Kubernetes spends up workloads all the time. So in a context like this, many of your traditional infrastructure elements, like traditional firewalls, traditional ideas, as ideas, as graphs, all struggle with the fact that none of your workloads are dynamic. And especially as you're trying to connect people with my calls on a side of open ship on version of the seeds, you start to have issues with how do you secure your workload? Let me give you a tip. So Tiger Earth as a company has been working with a type of ecosystem, around how do you enable dynamic, cloud-gaming security, and I think the platform-flip open ship is also working across the range of public cloud. So today, Tiger Earth solutions such as Roger Callaghan and CNX have been embraced by Amazon about 7 cents. It's been embraced by Microsoft this year. It's been embraced by Google, GPD and IBM Cloud. And in effect, what you get is an ecosystem security solution that works across all the fields. Now, not to me it's this available thing of the truth, but these major public cloud providers have chosen this as part of the base solution in terms of what they offer customers. So what you get is an ecosystem network policy implementation that goes across all the fields. Specifically, in deploying open ship today, you get something called network policy, which is something that the Tiger Earth team built for Kubernetes and has been embraced by Kubernetes today. Kubernetes, again, is a network policy implementation that's part of open ship. That said, Callaghan is perhaps Project Callaghan, open ship projects that Tiger Earth sponsors, which perhaps the premier implementation of network policy for us industry. Like I said, it's been embraced by the major public cloud vendors, but also available for Kubernetes. And in effect, you get inconsistent policy implementation with a whole bunch of advanced features going beyond the base of open ship technology. For the more recent to be announced, like that Callaghan policy now includes riskier integration. So when you're security using network and application policy, you actually miss that on the application identity assigned to the workload via Istio. And if you're not familiar with Istio, you have a number of sessions at the event here. Specifically, you now have a program graphic identity that's being assigned to the application by Istio that is leveraged by Callaghan to enforce policy across the open ship environment and also connect it to workloads on the outside of open ship. And one of this is done with more impressed controls, which are a lot of them. And there are CNX is that controls should provide more impressed controls for all of the products on the Callaghan working for the open ship. And specifically, this provides additional archived integrations to impress hierarchical structures. So you can have an inclusive team coming in with a line of developed policy. You can have an input cooperation scheme to provide policies for policy before being developed by the business website. And actually, just to give you a quick demo of that, let me actually switch it over to that one. Showing the intensity of Expo in the future. Callaghan is able to definitely see the network policies that are no longer present in the policies. And these policies are evaluated in priority on every left and right. So for the left and left picture, the priority policy is the higher the priority of that policy. And in effect, this gives you a way to define higher precedence policies organization team that supersede what their own open ship developer might define it. So that way, you're not putting your organization at risk just because of a badly created policy. And it's, sorry, amazing. And obviously, I can certainly learn it. Obviously, I forget to use what's happening with individual policies. So that's what it's all about. You get a network set of stakes and so on. And since it's all using open ship, sort of user identification, user identity, open ship authentication, organization, citizen type, CVC, just for those guys. Some of the benefits of doing with a platform like CNX is that the initiative to just do the basic component is a policy to have an open and fast control. And so when I use it again, I will stress that from this point in the course, questions and follow-ups with CNX, people will have much better magic if you log that in. You have a policy with policy spaces to create policies, to create long-term services and long-term habits. You go back to when it was happening on Sunday of last night, because we can exchange the policies, what traffic to float, or what traffic that can be defined in policy. We can also, now with CNX, we actually support multi-cluster. So you can actually have multiple independent customers who can even spend open ship cluster talking to Amazon, EPS, talking to Azure, EPS, talking to Google, GK, and have policy progression going across all of that which we support in CNX. And because Gallipoli is the policy engine used by the public to my understanding it's the inconsistent policy from CNX, but you can actually focus on multi-cluster. Just note that the government supports and works with the CNX and works with the CNX and works with other companies that are selling it higher. They'll show you how this will be consistently across even cloud services. And this is all being done in cloud. So they actually understand how this will work out there. I don't know if some technical colleagues have said to you, if not really,