 How's everyone doing? Good, Dan, how about yourself? Good, send everybody a link to the agenda. So go ahead and sign in. If you're new, you can leave your, we'll call on you when we go around sort of, you know, go through a bit of a roll call. We'd love to have you introduce yourself. If you don't have anything that you'd like to update folks, just put a little parenthetical, no update and I won't bother you or put you on the spot or drag you out of the other meeting you're in at the same time. My plan for today is to open up a bit of a discussion. I have been, you know, sort of way-laid with, you know, some changes in my career and job and I can care of that stuff. So, you know, sir and JJ have been covering a lot of stuff and, you know, I'm getting back to the motion of doing cherry things. So first and foremost, if, you know, our norms have evolved in a way that I'm not, you know, following, let me know. Because I'm not, you know, following, let me know. Because, you know, we've been doing great. It's a nice, you know, not to have to facilitate all the meetings and, you know, I want to make sure that we're maintaining consistency, not me just, you know, grinding along. I can grind out a meeting. So, you know, let me know. I want to have a bit of a discussion since we don't have anything pressing on the agenda around the role of operators in our cloud-native system. It's kind of opened things up. We have a new end user group that is forming and, you know, I was instrumental in forming a similar group in the Node-GIS ecosystem that's been, you know, really, you know, beneficial and, you know, in that effort, you know, we also, you know, formed a sort of crisis management team that helped us deal with gamergators and folks coming in from outside of the community and either just causing havoc or, you know, trying to gain the system or, you know, to other things that we've been doing. You know, to other things that, you know, aren't in line with the overall objective of the effort and, you know, we found that very effective and, you know, there may be an opportunity as we, you know, continue to grow this community to explore some of that, too. I think I see you have no update with this your first meeting. If I call on you, will you be comfortable introducing yourself? It's not, don't worry about it. I won't call on you. No need to be on the spot. We'd like to get to know you. Okay, I'm gonna go ahead and kick off the intros. Michael, you wanna get us started? Yeah, sure. So we're going through the process of reviewing the CFP for the Claw Native Security Day at Kube County U. I wanna say we have about 54 submissions. Some of those do include capture the flag submissions, which we still kept open, but we're not gonna do a capture of the flag, but we wanted to kind of capture different ideas so that we could use those for possibly KubeCon Boston. And we have about seven reviewers. So that's also an increase from the three reviewers that we had last time. So we'll have a little bit more data points to make better decisions around what talks are gonna be accepted. And then hopefully we're gonna have a meeting or we're going to have a meeting on Friday and hopefully we'll have the final schedule ready to go by then and then publish shortly thereafter as well. So stay tuned for that. Great. So can we put an agenda item on for next week that we'll review that out and maybe dive a little bit deeper into the outcomes there? Yeah, sure, love it. Cool. So I realized that I didn't peer pressure anybody into taking notes. So we usually like to have two. Thank you, Justin, for stepping in and taking on that. If anyone else would like to help Justin, especially while Justin's talking, we like to have two scribes that we can capture everything and can participate. All right, back to the agenda, Justin Kapos. Yes, I have a couple of quick updates this week. One of which is that I've still been trying to get a bit of movement on the mock-up of the changes to the landscape. I've talked to Amy about that yesterday, but I think maybe hearing it from someone other than me because I feel like I've pastored her now about eight times about this incident. This need might help to move that along a little bit, although maybe give her a day or so. And also mostly we've just been dealing with a variety of things related to tough and in total and stuff, tough adoption within the community is always kind of chugging along. We spend a surprising amount of time explaining to people that this transparency log idea, this idea of having what's basically a blockchain or a permissioned blockchain. If you don't like the word blockchain, then a permission set of servers that Google runs in some cases, like keep a history has been something that it seems really odd to us, but a lot of people are kind of starting to, or we've heard people kind of confusing this and thinking it does things that it doesn't do, like actually provide security other than just detection of things. So if, we've been trying to get the word out about that and make sure that people don't kind of get suckered into taking something that doesn't give them the properties that they want. I attached your blog post to the minutes as I had it around anyway, about the transparency logs. Yeah, that's great. That's Trishonk and Marina, two people. Trishonk used to be my PhD student, Marina currently is. And I disagree with some very minor things in there, but it's I think a good post and makes a point pretty well, so thanks. Capos, I think your consternation comes, is in line with the topic that I'm trying to tee up for today, around the role of operators. A lot of what we're building in our cloud data systems are automation and sort of ease of whatever and there's behind some of that, I think a misconception that we eliminate operators. We've lifted and shifted so much of the data center out of that sort of operations into the cloud, but still that new infrastructure in our cloud data world needs to be operated. And I think the types of roles that exist there are just not well enough to find, not well enough understood, especially not at scale. And we'll all be better off if we begin to wrangle the human side of that and try to introduce more clarity there. So I got elected on the TOC last week, so. Grads, you muted yourself. Oops, sorry. Yeah, so I guess also, I guess I'll probably be involved in the TOC interface with this group as well, so. As well, so yeah, I'm sure I'll talk to you in that capacity as well. Great, looking forward to it. All right, dancing, dancing news. Pradek, do you wanna introduce yourself? Welcome to security. What's your background? Sure, are you guys able to hear me? Yes. Yeah, myself Pradek Lothia, I'm a principal architect at Charter Communications, which is an internet service provider. We're starting to work on Kubernetes architecture, dealing with various CNAs, service mesh policy and configuration. So I represent more of the security aspect of it. So that's why I'm here to see what, you know, value, what things are going on in the working group and if there's anything value, I can add to it. Awesome. I'm good to have you on board. Thank you. Kapil, good. Hey, I am an open source technologist at Amazon and currently hanging out with the CIG because I have a project that I started with my former employer, Capital One, called Clock the Student, that we're trying to get through the assessment process to go for the talk for an incubation type of event. So I've been hanging out on open source for 24 years and always, I'm tired of my data being leaked, so anything that we can do to improve security in the cloud, I'm fully in favor of. Beyond that, more tactically, I've been looking at the assessment issue and it's sort of been, I feel like it's been kicking around for a few months without any real movement and the last two weeks, it's been waiting for someone to sign off on the reviewers. So trying to figure out what we need to do to get that done. Awesome. Well, you're at the right place for that. I will help you push that over the edge. And I know, you know, from TLC meetings that you've been engaged there. So, you know, call us out. You know, worst case escalate to the chairs. I am one of them and we'll, you know, make sure that, you know, we get you through that process. It's for you. By the way, and this is just a point for anybody else who's in a similar situation. Raising things like that in the Slack channel or on the issues related to the project are really good ways to do it. I don't know if that was done here and missed. It could entirely have been, but just let us know that things are laying because without, you know, we get the, we get pinged when things happen like that, but we don't get when things haven't happened and should be. So. Good for them. Good point. Well, you know, last comment from, on that issue was from you, Justin, on Ken, one of the chairs review. So, you know, I thought I'd give it a little bit of time, but I will go ahead and drop the issue number into Slack in case anyone has a chance. I've put it in the minutes as well. It's three or seven, but are you based in Seattle? Cabo? I am in Seattle at the moment, but I'm currently out of DC. Okay, I'll just pass. I'm going to be in Seattle next week. If you were around, I would say hello to that. Because I volunteer to chair this. Sure, it's good to have you. Thanks. Awesome. All right, well, thanks everybody for their check-ins and updates. Now, over to SIGs and working groups. Anyone from, you know, Kubernetes, the policy subgroup, security audit working group, or Mark, anything from the broader community in NIST? So a little off topic. This is from the IEEE DevOps, if I turn my camera on, yeah. From the IEEE DevOps community, they've asked me to try to crosswalk that draft with the IEEE reliability standard. So I'm trying to put that off for the post-public release draft that's going to happen in a month or two so that I don't have to do it now because I don't have the time, but I'd love to get feedback from anybody who has got opinions on connecting up DevOps with resilience issues. Obviously cloud fits into this too, but it's not the primary focus of this, but I'm interested in anybody's opinions on this. I can get you a copy of the standard if you don't have access through your institution. Then from here. In that sort of validation process, how much is the process leaning on automation standards versus operators and subject matter experts? If I understand the question right, it's really about trying to take the existing standards work, explain what DevOps is, how it changes the existing standards. I don't think there's the kind of ops centric focus you would get with SRE. That by the way was the Google SRE approach is somewhat orthogonal to this in many respects because it's not software product release driven. That's important for ops. So I think we're really not tackling that even though I've made several presentations to the group, I didn't really get any traction about that. So I think the draft standard won't say much about that. Is that the gist of your question? It answers my question. Though does it not have a certain focus yet? No. From what I take away is it sort of starts and ends at standards and doesn't quite connect back to how those standards are applied and what's missing that the operators might need to sort of take into account. Yeah, I think you're really touching on a broader problem across all of the SDOs. How do you get tech transfer from the standards and vice versa? Because you get a weird population of people with the time to work in the standards. So in some standards you have very IBM dominated scenario because they pay the people to show up there. I guess that happens with Google to some extent here and there. But also a lot of folks vary in their late career with a lot of, you know, trying to make their mark in a discursive environment. And those folks tend to be a little at some distance from current practice. So that's the sociology of the standards organizations is a little, a bit of an impediment to tech transfer. Yeah, in the DevOps group, I think we've made some traction there. I'm concerned that the document is gonna be really big. For example, it's taken ISO work from the test community and trying to apply that to DevOps automation and also to connect it up with quality and risk management and all of these things are pretty deep disciplines in their own. And to trying to DevOpsize all of these things is really trying to come to terms with a thing that really hasn't evolved in current practice yet. So yeah, this is a large topic. We could talk about this for a whole meeting, right? Yeah. Yeah, it's a big issue. And I think we're potentially undervaluing it. I think those of us who may have a little bit more experience under fire may have more appreciation for it and just sort of a natural expectation that that's the part of the process. But those who haven't sort of had that opportunity don't have the appreciation. And a lot of what we're building is abstracting those things out or automating those things. So, we aren't placing an assumption that we're gonna need subject matter experts for those systems to be successful in the future. Right, that's a good summary. And just to really evangelize this even further for this audience, if you look, if you try to fast forward five or 10 years and where this automation is gonna go, security becomes in part at least AI versus AI. And the extent to which those algorithms require deep subject matter specializations, say to automate the generation of test plans for things like two factor authentication or for testing the resilience of distributed systems that have part IoT, part concentrator, part cloud-based operations, these require both siloed expertise, necessarily siloed, not siloed by fiat or org chart, but just because to become a specialty knows things you have to become steeped in it. So building test cases that work across them is a big challenge. So, yeah, this is a problem we're gonna face. And in an equally siloed way, the adversaries are going to architect their own approaches to this. They're gonna leverage the same open source tools that we're using to implement our own countermeasures. So, at the same time as we're embracing an open community to what secure our systems, we're also providing them the tools to combat us, to offset these safeguards. So these alternative perspectives on security rid lards beyond the issues that you're addressing is something we kind of have to have in the back of our minds at all times. Great. Erica, I saw you switch cameras. Did you have an update? I just linked in the doc that for the Kubernetes working policy working group, we're kind of discussing a policy violation kind of standard across so that different projects can plug in and have the output be readable. So I linked the doc and people, especially from more policy related projects would be interested in chiming in and contributing slash integrating with it. That's all like that. I'm gonna beat this one to death today, sorry. The workflow that you're building for policy violation begin to approach sort of unknowns or how we sort of intercede in an incident or is there an expectation that automated systems are going to take our output and address most of the problems? Yeah, it's a little bit agnostic on purpose so that we're kind of, there's a lot of different kind of plug-ins and projects, the caverno, the OPA with gatekeeper, et cetera that are kind of approaching the policy landscape within Kubernetes in different ways. And we kind of just want to get some parts on the same page so that we can kind of have, especially so that users can switch between certain aspects of them. So we're trying to keep it pretty minimal and not prescribe much at all, except that the output is human readable and understandable at the least. Bonus, right? Code 512 to start working. Nice. I look forward to reviewing that. Okay, so thanks again for the ping on Kappel on cloud custodian, needing sign off, I will circle the co-chairs and make sure we wrap those up this week. Don't see Brandon on today. The KubeCon.edu deep dive. Is there any updates on that? Amy, are you on the phone? I saw you in the dock. I know he had mentioned wanting to do something related to the landscape discussion presentation there. And I know he's been thinking about it, but I haven't talked to him this morning. Okay. I won't come back to that. Okay, so in this second part, I'd like to open this discussion a little bit further around the role of operators in cloud-native systems. We approached this several times. I've been talking to a bunch of folks across the ecosystem and there's this interesting sort of duality of especially around Kubernetes where we're both trying to standardize it and abstract it away at the same time. And both of those things are needed, but one of the drivers that I see of wanting to abstract it away is Kubernetes is hard and I don't know enough about it to effectively manage it. So make it go away and just make it easy for me. And the reality of that is folks are leaping over necessary steps of understanding and integrating new systems with tons of distilled complexity. We've lifted and shifted the entire workflows of data centers and the operators in the data centers that have had physical abstractions that enabled us to keep things secure, keep things maintained and sort of pipe in in crisis and deal with issues. That increasingly is going away in our cloud-native world. And collectively I think we all want to get to the other end of the rainbow, but I've been at this for now 25 years and I'm increasingly of the mind that there is no other end of the rainbow that we're only going to be changing the wheels on the car faster, more often and probably we ought to get better at doing sort of live mechanics rather than expecting that we're going to get to some perfect state. I spent five years commercializing Nodeath bringing what I thought we were eventually bringing things into helping developers. I'm a developer solving developer problems. Ultimately, once we got into quote unquote product market fit, the reality was we were serving operators. Folks didn't know how to run those systems and we were providing the tooling that enabled those operatives, the individuals responsible for running these new novel systems that hadn't existed and hadn't been run at scale before and providing the tools that they needed to successfully operate. And I've come back to that premise as I've spoken to many organizations recently that is, I'm a developer, is developing this solution really going to get us the outcome and that we're looking for. And even with our sort of best approach that we have today around SRE. Yes, we're actively solving things problems with software, helping accelerate our systems. But ultimately, we're putting experienced individuals that understand the subject matter in the line of fire and enabling our system to operate successfully by essentially putting operators in the mix who are better equipped to deal with the dynamic changes that we have in our cloud-native systems. So that's the premise. I'd love to get your feedback on that and see where we can draw some inspiration to move that forward. And also see if that's something that we collectively are interested in spending. Any of our cycles on, a lot of the folks that have raised their hands to participate in the assessments are looking to build their skillset and ramp up their understanding of how they can work more effectively in this cloud-native ecosystem. So in a very tangible, direct way, we're helping support the security operators of this cloud-native ecosystem by the security assessment process that we're putting in place. Silence the crowd, Dan. I guess I'll just add my two cents. And I think the operator framework or the operator model is actually good from the perspective of the laws. If it's done properly, it allows you to bake in a lot of your security posture and security configurations into the configuration. Of course, part of the challenge is is most of it becomes a black box. You don't know if that's being done properly or not. But the idea behind operators is that you can have the people that have the expertise in mycicle or cocker or whatever it might be, build in those best practices to make it much easier to run systems securely. I agree. Though I keep seeing, especially on the business side of things, a desire to make those individuals go away or an expectation that we're gonna AI our way out of it rather than proactively invest. Like, what's the training curriculum that we would expect those individuals to have gone to assert that they are a subject matter expert? That's a simple question that I would ask in helping folks understand that they're all of operators. How do we validate that? I mean, I think things shift so much over time that if you'd asked five years ago what people doing this kind of work would be doing and how would you train somebody to know how to use cloud, it's very different today. So I don't sort of know what that we're going to be able to come up with some meaningful prognostication about this. I think AI and automation has made things that were hard easier, but it's typically done that for mechanical things so that you can have a single person be able to do more or something rather than not need that person anymore. Yeah, I agree with that. I think when people try to say they're going to automate away jobs, it's just besides like doesn't even, I don't even think it makes sense. It's like, I thought you're trying to do more, right? Most companies are trying to grow. So it's more, I think if you frame it as we're building tools to help people do even more with the who are already overworked, it's a better frame than thinking about getting rid of them. And I think that goes for operators as well that we're giving them the tools to do their job more effectively, to run more services with fewer, with fewer of them. What are the tools, just like, what are the tools that developers need? What are the tools that the operators need to be able to do their jobs more effectively in the cloud native environment? How you doing? Pretty good. I'm just trying to sit there this meeting and I'm like, ah. So, I hate to monopolize this too much, but I'm reminded. I'm talking about AI. It's sacred to call this, I'm just going to talk over this person. It's a pity to call this work infrastructure, which means that people are responsible for. Bill, do you want to mute? Somebody mute yourself? It's going to happen to your director, it's going to happen to the car. Yeah, it's going to happen to the car. I can't mute him. So, go ahead, Mark. I'm going to mute him either. I was just going to say it's, the people that we call doing infrastructure now means, for example, the folks trying to implement micro networks, the smaller subnets of authorization and policy connected subnets is what used to be done by network engineers. And that was a clear, that was your Cisco guys, your Palo Alto guys. Well, if that becomes software, there's a fusion that's happening here that is a force multiplier to use the DOD framing for this. And I think that does mean reduced headcount. Because it now becomes a cross-specialization. It's now a Python skill plus networking skill. And also, if it becomes open source, it means you're not hiding behind a paywall to teach people how to do it. So I think there is a sort of democratization of infrastructure that will happen through cloud. But sort of the offsetting thing that's going to happen that I see on two fronts, one is the sustainability metrics, which is kind of related to security, but not directly. But as we become, have corporate responsibility for power footprint for everything that we do, and also for measuring it, that becomes an IT demand to produce real-time metrics for that sort of thing. And to plan for it, that creates new demands on our infrastructure. So there is that pressure on it. And also, I think there's a demand to move toward real-time, which is a slow moving front, taking moving things across sector by sector that's affecting every domain separately. Maybe medicine will be last in some respects and utilities might be first, I don't know. But as we come to encompass the implications of all that for security and manageability and costing, I think then infrastructure takes on a sort of a role closer to management than it used to be. So instead of the Cisco engineer, you now have sustainability engineer, a reliability engineer for top to bottom network resilience. So, yeah, I do think there's a force for headcount like it or not. But I wanna press you a little more on Dan, what you mean by the SMEs? Is it the SMEs for our traditional specialties? Is that what you have in mind? No, I just know the way that we value subject matter expertise and apply it. A lot of the sort of scale ways that we're applying subject matter expertise is through what we keep calling AI which behind the scenes is often mechanical Turk and feeding in training into systems that we don't fully understand to achieve the outcomes that we'd like to have. So real boots on the ground applications things, not the idealized or perfect state. And that workflow, that process, the flywheel fundamentally is abstracting away the subject matter expertise, not distilling in subject matter expertise based on years of experience. You mentioned those trained and certified operators in kind of two generations ago with our network operators. All of those folks to get to be able to participate in the marketplace, had to go through extensive training and certification to do what they're doing. And we kind of just flipped a bit and said, okay, great. Now that's virtualized and that expertise is really not needed. Maybe if you get a little networking, maybe you get a little Python off you go. Rather than saying, okay, wow, that was really hard. And we probably don't understand all of the rough edges where we're gonna burn ourselves. And that just will hide pain that we're gonna get in the future. Okay, that's clear. So a short thought about that is the flywheels are operating autonomously now inside the major vendor toolkits. So like the anti-fishing tools, there's a whole bunch of deep knowledge required to use them. Same thing with the edge connect, the edge tools, the dark web intelligence tools, all of these things have their own sort of deep specialization stuff that is still there. So as you're writing APIs into these tools to do orchestration, you have to come to terms with pretty deep SMEs around that. Some of which stays on the vendor side, some of which gets brought into the institution. But still, I think you've got this, the thing you're tackling here, you've got this sort of decentralization of that expertise into a broader community, whether that's good or bad that is going on, it's true. Right? You've also in a sense got a centralization of a lot of that stuff into cloud providers and other people providing services. Wholesale, who will have whole teams who sit underneath those APIs and work out what the internals of the security model are in a way that's actually very, quite well hidden. If you think about what's underneath, the AWS API in terms of the number of security people working on it, there's a lot of people in those teams. Right, you know, my go-to use case for this is medicine, though, where we all concede that we don't understand what a radiologist does looking at a mammogram. Right. So the way that a security engineer interfaces with a domain-specific ecosystem, I think, is the leading edge challenge of the SME in the technology domains where this community on this phone call operates and the specialization in the healthcare ecosystem interact, and that's a hard problem, which most people, I think, don't even accept as a problem. Yeah, so, Mark, you worked with a framework that actually collides and coincides with our former moniker called Safe. That is kind of a very large structured process for beginning to look at that. That's been in flight now for several years. Would you mind sort of describing Safe and that framework? And if you could touch on some of the challenges that actually implementing that, you know, have you encountered? Wow, I need to do some more homework to put that presentation in a coherent state. There's an appendix in the last release of the report we worked on for that, which summarizes three levels of sort of voluntary compliance to try to address that in security and privacy. That's, you know, we could walk through what it takes to try to do that, you know, but I think this community on this call is more sophisticated than really that standard tried to tackle. You know, for example, the ability to take, you know, an open stack like architecture and say, this is how I'm gonna partition off classes of data and protect it, and how I'm gonna, you know, control the anonymization algorithms that I'm using and how to try to de-feed de-anonymization tooling, you know, if this audience would get that, we don't really try to tackle that in that framework. You know, I could come back and talk about this, you know, at greater length if you like, but you know, the short version of this is that, you know, it's, we just conceived of three voluntary compliance levels that try to look increasingly deep at this intersection between domain specific and cross domain security apparatus to promote privacy and security across a bunch of segments which we're all familiar with, you know, encryption, transparency of algorithms, adversarial testing, automation, reduce cycle time for the promotion of code in order to sort of stabilize the interaction between what we find in adversarial testing and new product releases. You know, there are other facets to that that came up in this four year effort to do this for the big data scenario. You know, it'd be interesting to, you know, get the reaction of this group to it, but, you know, I would frame it differently if I knew this was gonna be my audience as opposed to people in the government looking at, you know, it's at like the GSA level of how do you do this for agencies and how do you do this for a 20,000 employee company where you have to deal with a lot of legacy code, you know, as well as, you know, because I think in cloud native gets to deal with a lot of greenfield and the greenfield luxury is not a common one across our industry, you know, even in telecom there's a lot of, you know, for a lot of reasons, there's a lot of legacy stuff you have to work with and this constrains the way that you architect system. So the framework driven approach with I know not everybody on this call is fond of tends to work better in those places where the legacy stuff is all in the mix. It's, you know, everywhere you turn there's something you don't have full control over. So you're, you know, you're controlling it through controls as opposed to automation which is kind of not where you wanna get if you're developer centered. So I don't know, I'm kind of dodging your request but I'd be happy to come back another time and talk about it. Cool, you know, I'll put out a request feedback. You know, maybe, you know, sometime next month. Sounds like, you know, it will require, you know, a little bit of thought and a little bit of prep. I, you know, we discussed earlier, you know, the, you know, the positive impact of subject matter experts and silos. You know, we, you know, as the security sig inside the same SIF are inherently that, you know, now the, you know, we were sort of the guinea pig for SIGs. Now that that SIG workflow in the CNCF is really beginning to hit its stride and, you know, kind of our next challenge, you know, since we've been able to invest so much in our internal process is now, you know, beginning to take and, you know, take our learnings and collaborate with the other SIGs and get better at that sort of looking outside of our world and mark, you know, that those formal efforts that, you know, really document all of those interaction points and rough edges, I think might help us inform, you know, some of those things where, you know, we might not know what we don't know and, you know, in need to draw on, you know, other insights to do that better. And your comment on Greenfield is, you know, I think one of the main actual reasons why we see so much, you know, acceleration in this field, in this area, because we, you know, have the privilege of going in and working in Greenfield and have gotten that, you know, time under fire and, you know, the ability to just, you know, really map that particular route out well, but, you know, then we got to integrate it with everybody else, build consensus, and figure out how it fits. Is this cloud native or not, you know, there's a lot of fit up work that we all collectively have to do to come out the other end, that, you know, not just our subgroup, but the overall collective, you know, remains coherent, remains valuable and, you know, is truly a benefit to the broader ecosystem. Yeah, I understood. All right, well, I feel like I've probably beaten that one as much as I can for this session. Thanks for the input and, you know, I'd love to hear your thoughts. I'd love to get feedback on, you know, whether, you know, we'd like to drive into the, you know, to safe as, you know, potential process that we can draw inspiration from so we can, you know, begin to inform ourselves on how we can integrate the work that we're doing here in security into the rest of the ecosystem, you know, make it usable, make it approachable, and, you know, make it something that, you know, folks are, you know, one of the main inspirations that JJ Sarah and I, you know, had when we got together to kick off this thing is really making security, you know, a first class citizen end of default. And I still think we have a fair amount of work to do to get to that. And, you know, a lot of that work is going to be fit up and, you know, helping folks manage their expectations. You know, with the other parts of the ecosystem, not just through our individuals, but through our individual and collective matter expertise. All right. So I'll end it with that. Any other closing thoughts or call-outs that folks need? If not, we'll give you all a few more minutes back in your day. Thanks everyone. Have a good one. See you next week. Take care. Ciao.