 Yeah, cool. So, um, do we want to discuss the, the GRPC? Yeah. So I think there are two approaches to solve the problem that is mentioned in the issue. Okay. Can you just fill everyone on the call? Can you provide a recap of the actual problem? Yeah, sure. So, uh, so currently GRPC, uh, has a certain mapping of, uh, the requested, sorry, the response status and the actual status returned from Envoy, which is mentioned in the issue. But there is a particular status, which is during a rate limit and that is not mapped correctly on the Envoy's end. So the issue is asking for a solution, maybe through config that would map a particular status in two different status within Envoy. So my suggestion was to, uh, have a generic map that would like map a whole bunch of statuses into something else, but do we want to go that, that way, or do we, do we want? Flexible. I mean, I don't know if many people are going to want this. Can't we just fix this in the rate limit service? Have that actually apply the fix up? I'm sorry. I didn't catch that. Sorry. Cut the rate limit service. Just apply the fix up itself. If this is an issue with rate interaction of rate limits in GRPC. I think we can do that. But, uh, my question is whether we want a generic solution that would cover all the different possibilities. I guess what, what are the possibilities are that there's like three or four different things that need remapping? Yeah. I agree. Totally. We should have something like that. But if it's really just an issue here with, uh, the specific interaction of GRPC in rate limits. Okay. So maybe then we'll stick to just a single, single status. Yeah. But if someone wants to speak up and suggest otherwise, all he has. Okay. Thanks. Did we get GRPC savvy people weighing in on here? Yeah. Good. Liza's on there. I will take Liza on as a generic GRPC. Is there a longer with, yeah. No, no, no, no. But as someone who cares about GRPC is going to think about like Istio, whether or not he's done there. Cool. Okay. And I think that may be it, unless anyone has other things we're going to talk about. Yep. Going once, going twice. Do you want to talk about the V1 deprecation? I just shared the progress net API deprecation. Well, so I feel like we don't have a totally solid status on that. So we, we killed off the V1 command line and that, that is thoroughly done. Something like eight out of nine of the deprecated V1 proto-fields have also been marked deprecated. And we could arguably remove them, except some of them probably shouldn't have been marked as deprecated because we don't have the, we have deprecated and not ready yet, roughly, for the TCP proxy work. So I do think that, that bi-policy probably shouldn't have allowed that field to be marked deprecated until we had the solution for it. That's probably true. Yeah. So some of the rest are on limitators. I don't know because like you want to discourage the use of it, right, for any further use. So there is that, it hasn't been deprecated in that we're actually ready to retire it, but it's definitely not a ready thing. Yeah, like. People classic. We still didn't want anyone like, you know, having you feel there or doing things or calling it deprecated certainly made sense. That's fair. No, but we explicitly called out in the release notes for the last release that the deprecated V1 fields were officially deprecated. Okay. And so I think either we could have called them out individually and said all of them are except for the TCP proxy one or not. But yeah, I was on the fence on whether or not we should get rid of the deprecated V1 part of fields that we don't believe are problematic. I'd started a PR to remove one of them and I was like, maybe we should move them all together. And I don't know if anyone has opinions on that. No, I think we could note them off one by one. Like, yeah, we wouldn't care about. Okay. I'd started out and I'm like, you know what? I've done so many reversions on deprecated V1 PRs lately. I didn't want to deal with it. I'll pick it back up and start not going on. Let's take us direction where we want to be. And I'll leave the the TCP proxy one specifically until the STF folks are happy with functional compatibility. Yeah, that sounds good. Cool. And then other than that, I think we're that's it for this release for the one turned down stuff. I think next release will remove the old old style recipe. Yes. So for anyone who hasn't got the memory yet, V1 REST APIs and not long to this world, they will be gone. It'll be hard to enough. So given that no one complained about the command line, I wonder if anyone actually cares, but hopefully not because it'd be great if no one's upset. I don't mind leaving the code in the code base for another three months. I just want to not cause people unexpected pain. So yeah, cool. And I should do a deprecation notice for that. Yeah, I'll go do that now. OK, see you guys in two weeks.