 Okay, well, I'll just get started with the V3 stuff. So there's a few things going on there. First of all, the regular UDPA stuff continues in the background and we're working with the working group there to try and hash out different aspects. Previously it was the transport protocol. Right now we're looking at things like the data model and how L7 routing can be handled in this context. The goal here is actually to do two things, to universalize or generalize Envoy's routing APIs that other proxies might implement them and to have this sort of lingua franca for L7 routing. And in addition, solve some of the scaling problems that exist very concretely in Envoy's API today where everything's essentially a linear match and we're unable to effectively make use of things like tri-structures or hashing deterministically. It's always possible to have an optimizer against what we have today in Envoy, but that's not the direction we wanna go. We wanna actually structurally improve things in the next generation routing API. And so that's currently what we're hashing out there in the guise of the VDPA efforts. Other stuff happening there is we've actually split out the VDPA protocols, including Orca, into a separate repository, which now lives under CNCF slash UDPA and Envoy brings that into its build as an external dependency. And that's then sets the direction for where we wanna go with the V3 XDS API. So moving away from this long-term guide of the effort, we wanna at the end of this quarter cut the V3 major version of the XDS APIs. And given we don't even have V3 offers today, there's not gonna be a lot. That's very revolutionary here. They'll be very evolutionary. We'll be essentially taking the V3, the V2 XDS APIs and removing anything that's marked deprecated will be, there's a few comments around next API major version about doing things. For example, throw away the odd reg X's and just have safe reg X and this kind of thing. And get a better alignment around things like header and path matching and string matching and all this kind of stuff, which was a better ad hoc. And the other thing that we'll probably do is move some of the base types in XDS across the UDPA repository as a sort of a step towards that. So that's essentially what you should expect out of the V3 APIs. But even though this would be a relatively small, it's a magic different from the V2 APIs, we're still following the full API version story. So what it means is from when these are cut, you'll have about a year to start turning down your use of V2 and moving over all your service to V3 and switching over to basically, yeah, to new endpoints, new code path, new generated code, all this kind of stuff. And I think the way to see this really is a canary of the Envoy's API version policy as well as a way for us to actually safely turn down some of the technical debt that we built up. The V4 APIs will probably be much closer towards where we're heading with UDPA and lots of things will be moved into the sort of common UDPA tree there and there will be much more probably revolutionary than evolutionary. I was gonna say, and I think the goal though, I just wanna make sure that from our side, we're on the same page is that, I mean, we're still focusing on making sure that the developer experience is decent, right? So, you know, I mean, that includes like not sacrificing documentation, making sure that we have those. I think I don't wanna speak for Harvey explicitly, but I think our plan there is to have translation tools since we have to do it internally to Envoy anyway. So it's like we're gonna convert probably the old V2 APIs to the new V3 APIs. So we can very likely have a config dump tool that will spit out what the new config would actually look like to help developers transition. But I think just as we go through this process for those that are a little more bleeding edge out there, feedback on the developer experience is useful because we wanna make sure that we're not making things worse. Yeah, I mean, the idea really is by shooting for very low bar for the API changes for V3 or allow us to focus on tooling and infrastructure and process and all this other goodness. And in particular, given that there's very little change between the two APIs really, it will allow us to make sense to not have to, for example, be implemented twice everything that's in V2 for V3. And we'll be thinking very carefully about how we do this translation and automate as much as possible because there'll be a huge payoff from that. Yeah, and then there are a few other things that I would like to fix in this minor rev, which I think I've mentioned to a couple of people. So on the listener and the cluster side, right now we have a bunch of embedded fields that are protocol specific that really either should be opaque extensions or one of, so things like, is it a UDP listener or a TCP listener? Or for some of the upstream cluster stuff, should they be opaque protocol extensions? And right now there are just embedded fields that are null or not. I think there's some low hanging fruit there to actually fix that. Yeah, I think we will optimistically get through some of those. Yeah, cool. Yeah, but that's all on the V3 front. Does anyone have any questions about that? Well, what is the project timeline for V3 right now? It's literally end of September is the plan. And basically whatever we have at the end of September ships as V3. I mean, just from my understanding, does it have to be that rigid? I mean, if it's an alpha, like why can't we continue to... It was the application clock essentially, it's pushing back even further. Basically, we're at this point where we can no longer deprecate anything and remove it from the API. And this is, it's moving things. We wanted this essentially the clock to correspond with envoy releases, which are end of quarter, right? And if we make it slip towards the end of the year, that's an additional quarter on anything which has been marked deprecated. So anything that's been marked deprecated is going to leave at least from this point onwards for at least a year plus, two months or something like that right now or one month. Sorry, that's not what I meant. I think that's fine. But if we basically snap, or you're saying that at the end of September, if you don't want it to be V3 alpha, you want to actually to be V3. That's right. Okay. So there'll be a very short V3 alpha where we just shuffling a few things around and marking these deprecated. I'm pretty sure it's V3 alpha next week. Okay, I mean, that feels extremely aggressive to me. It is aggressive, but that's why I'm not shooting for a high bar for the actual API changes. I guess my question though is, I mean, we have to live with this for quite some time. Like if it takes us one week extra, to fix a couple other things that feels like a useful compromise. I don't know if that's the case or not. I'm just... The question is, if it's coming down to like a week or two, would we be willing to just then push the Envoy release back a little bit for this quarter? I'm just brainstorming right now. It feels like a useful compromise. I guess all I'm saying is if we... Let's see where we get, you know, by the second or third week of September and it feels like we're done with the low hanging fruit and we feel good about how things are, then that's fine. But if we get there and, you know, we're thinking, ah, I wish we had one more week. Like we could do a bunch more stuff here that feels like a good use of time to me. Yeah. I mean, the way I think of this is we were basically learning what kind of automation would be useful. So I'm going to buy hands basically do v3 and then we can go back and even push into Q4 some of the automation parts of this work. And so I feel it's important to do is get the right API cut and then the actual tooling and automation beds, some of these things can, you know, for example, you know, the stuff like to keep the two APIs in sync or to make sure we're not violating any constraints on single definite ODR and this kind of stuff. This kind of stuff can be pushed back and we can do it right by hands up the first time around. Sure. I just, I still feel like I'm just thinking through some of the issues just around, you know, even some of the small things that we wanted to do, some of the federation concepts, like making sure that we have named filters, extensions and named host weights and a couple of things. You know, it's like there's some work to do here and I just, I don't think it's in our interest to rush it by a particular date. I'm not saying to let it slip three months, but if we need an extra time, that feels okay. I mean, to the extent that some of these things are incremental, that for example, let's say you could always add a name field to something later on, I feel we could push them back into, we could add them to V3 after it's been cut, right? It's not like V3 is completely frozen. What we're doing is we're banning backwardly to be backwardly in the pattern of change. Here's one thing that I would maybe suggest because I'm gonna be honest, like the existing UDPA docs are like 30 pages and very hard. That's what was two pages, come on. Yeah, it's lots of words. I'm just, I'm just, You're trying to use the diagram. I'm just thinking like tactically, whether it's GitHub issues in the UDPA repo or whatever. And I can help with this. Can we just open issues on like the things that we want to actually fix? Right, like we're gonna pick a small number of things that we think that we wanna fix before we cut V3, whether that's the scalable routing or the listener polymorphism or the cluster extensions, the name filters. I'm just thinking we could open a couple of issues and then we'll have a better idea of what we're. I mean, well, we already have the V3 API label and we have a bunch of these under that. We may even need, we may need to more aggressively triage that label. I'm planning on also doing a sweep of all the various V2 API things and not moving them across as needed and some even though it would be for API. That's fine. I mean, however you wanna track is fine, like whether it's a spreadsheet or issues or it doesn't really matter. But I just think that will give us a better way of collaborating on like, these are the things that we want to, these are the small fixes or small additions that we would like to often be land in V3. And to your point, we can look at one of those things and say, oh, it's incremental. We can add a later. That's fine. But some of the things that I'm thinking of are not gonna be incremental, right? So for example, like name filter configs is not incremental over the current situation. We actually have to fix that proactively. So like let's just make sure that we're getting on top of those things. That's correct. Okay, so let's try. So if at your end, you can make sure everything's filed and labeled correctly. We played it this week and make sure everything in my end's in and other folks in the community can hopefully look at that label and either look at the issues there or at any of their own. Yeah, that sounds good. But my general comment though is that to people who are either on the call now or we're gonna listen to this later is we have four to six weeks basically to make some incremental not revolutionary changes to the API. So if there's things that you want to see now's the time to speak up. So just keep that in mind. And again, I'm just being realistic because it's one thing for us to do this with an envoy, but then trying to reconcile this with theoretically making the other data plans happy. I'm less convinced that the timeline is going to work unless we take a harder line on just this is what we're doing. When we got the data plans happy. Well, I'm just saying is that even looking at your existing routing PR, the first sketch of it. Yeah, that's not gonna go into V3. That will go into V4. While we're going to V3, we're gonna move some base types across as a sort of just testing. Oh, okay, sorry. Then maybe I'm a little confused then. So what is that PR then? Like what are we? That PR is gonna probably be... So I think all the UDPA data model and transport protocol stuff, like the meat of all this stuff is essentially gonna probably land over the coming year in alpha states in V4. It's a really thing that using envoy's clock, it'll be V4 alpha, right? I see what you're saying. Oh, okay, okay, okay. So basically we'll snap V3 with very minor changes, move a couple of things into UDPA repo and then we'll start work on V4 alpha. Yes. I guess then I'm gonna ask a stupid question. What is the point of V3 then? Why don't we just start with V3 alpha being UDPA? It's a deprecation sweep. It allows us to basically clean up anything we've not deprecated, which we're not going to remove from the API at this point. And obviously, and then other random stuff, which is just kind of a bit ugly and we would like to... Got it, okay, all right. Okay, I mean, I guess it seems fine. I just, I'm not sure that it actually really matters that much. Like I feel like we could just go straight. We could make V4 alpha, V3 alpha. I mean, if we're willing to live with all the deprecations and sort of... Yeah, I'll speak up here. I'd rather not have three years worth of deprecated features. Like, okay. And plus I think it's worthwhile getting a feel for the tooling of having two versions in progress, like sooner rather than later. Just like feature flags or whatever else. Like there was a bunch of work that we didn't anticipate that just got piled on. So having like a minimal change that's not going to be super painful, learning how to support to in parallel and then doing like the big one makes a lot of sense to me. Okay. Launch it early. Sounds good. That's all from me. There's Jot Cookie Support. So hi, my name is Jeremy. I'm from Duo Security and new to the Envoy Group week. I guess I'm not actually technically in the Envoy Group but joined to say hi. There's a group of researchers at Duo who are looking into Istio a lot, which uses Envoy. Everywhere is the communications backbone. And we've been investigating... So Istio currently for Auth currently uses Jots as a HTTP authorization header to authenticate users as they make connections into their applications within Istio. And the Envoy proxy supports pulling Jots out of an HTTP authorization header but doesn't currently support pulling it out of a cookie. And there's a number of GitHub issues on like the Istio issue page that people are asking for this feature. We were looking into this feature. Just last week, we discovered that the Istio group is working on an OIDC auth proposal that might sort of supplant the idea of using Jots in cookies directly. But it's something that we were looking into. And so I was hoping to sort of just say hi and pull the room and see if anybody had thoughts on that if we were going to look into that and maybe submit like a pull request sometime in the future. Yeah, the story of the Jot authentication in Istio is a little bit complicated and the Jot authentication filter is diverged from what we have in Envoy upstream right now. So I think the feature of like extracting Jots from headers a little bit improved in the upstream Envoy, I didn't follow what have done in Istio proxy right now. So it might be already usable with the upstream Jots filter in Envoy but not supported in Istio proxy yet. So that's one thing the tech that we have in Istio site. And also the OIDC group is like is trying to do more comprehensive story of supporting OIDC with the Jot authentication. So that's the current status. Yeah, I've been looking into the OIDC proposal and that's looking really good. We're gonna join the meetup on that proposal tomorrow. If I know more about that. But I guess, so just to clarify you mentioned that upstream Envoy has Jot support in the authorization header. Were you saying that it also already has support in where it can pull Jots out of cookies? Yes, I think so. We recently added up, there's recently a PR is for supporting extracting Jots from other header and matching from part of the like header like semicolon equal based like the which field to extract. I think you might be able to make use of that but I'm not super confident that it's usable to extract from cookie. Right, so yeah, I know that you can specify an alternate header to- Not only alternate header in upstream we recently added that to how to extract from part of the header, so. Oh, so potentially including the cookies. Yeah. Okay. You said there was a PR submitted. Is that on the GitHub? Yeah, you can go find that. Okay. I'll go look into that. Okay. Thanks very much. Any other topics? There was a comment on here about windows. Hello, Bill Rowe here. So yeah, Cole and I are here just to kind of check in that I'm appreciating all of your help over on Envoy Dev, of course, trying to get the Windows port to build. I'm largely interested in your awareness of any other groups working toward or interested in consuming Envoy on Windows first off. And just to kind of give a little bit of an update we basically have all the sources building. There's a whole bunch of work around IO handle and the IO socket handle info that we have to finish cleaning up. Of course, we did a bunch of work. Stephen did a bunch of work way back in the last year. And so now we're finally getting caught up to current Origin Master trying to get back in sync so you guys can accept some patches. But biggest problems we're having are around the extensions API. So, and I don't know how to, I don't know the level of detail we want in terms of the PR on that, but basically we're finding that a lot of the extensions weren't actually built with the Envoy extensions, CC, library and other stubs that were made to tune whether or not those extensions are in fact in the list. I've seen some interesting proposals on Dev to kind of move that over to assemble our list of enabled extensions right off the bat, even as the build system, even as Bazel kicks in. So we would actually know from end to end which pieces of the, in the extensions tree are useful and which pieces are not. Sorry, I'm not, so we... Hey, sorry, I'm not following. What's the problem? Okay. Well, what I've found is that a number of the extensions are just using the normal Envoy Bazel declarations and not using the flavor that was built for selecting extensions. I don't think that's true. I mean, I'm positive that's not true. So if there's an example of that, I would like to know. Sure, sure, sure. I think, yeah, I think you're misunderstanding how we are actually building because the Bazel is smart enough to detect what the rule is not required by a specific target. So if you do like slash source slash dot, dot, dot, you will be basically including everything. But if you do like slash source slash access slash Envoy static, then those not enabled extensions are not being compiled anyway. Okay, that I understand, which is excellent. I guess my question kind of comes down to when we try to invoke the tests, that's where it gets extremely confused. If the test is not using Envoy extension, CC test, that will be accidentally included in the test suite, that's true. And speaking up for the Windows interest, we do have a custom ask for Windows support. So I'm happy to take a look on your Windows port and do some test based on that. I was gonna say, and on that topic, and just just in the interest of time, since we're almost out of time, I really would like Microsoft to do some work here. So let's take it offline. I'm gonna follow up with Microsoft again, and maybe if they can kick in some part time help here. So maybe if you think that you can help, Lee's in, maybe we could start a thread just between us and just talk about some strategy. Okay. All right, well thank you guys. Yeah, I appreciate it. So where is your like Windows port right now? Is that open somewhere on GitHub so I can take a rough look or not yet? Yes, but it's not merged to master quite yet. Yakkel, do you wanna address that? Yeah, okay, I can follow up with you offline on Slack. I'm gonna make a note to talk to Microsoft also. And then could we start a offline mail thread? Yeah, please go ahead. And I also have a few contacts through the Apache ESF that I can poke the bear and see if we can find some resource. So let me know where you're going with that. Yeah, I'm gonna go directly to the higher ups there. And let me just see what I can figure out. Okay, sounds good. Cool. Did anyone else have any quick, I think we're out of time, any real quick things? All right. Yeah, see you folks next time. Bye. Bye. Thanks.