 Hello. Hello. Good morning. Afternoon or evening, we'll get started about five past. All right. Thanks. Morning morning. They can. So far I see you. Camille and Sam right now we're waiting for Alexis. Oh, Jonathan bulls here too. Is a Brian control. Yep, I'm here. Morning. Hey, Chris. All right, we'll get started in a couple more minutes. Chris, if you put the link in the slack. Yes. Oh, thanks. Is Ben Brian. Grant or solemn in here. Let's see them right now. Given another minute, I know Brian Grant sometimes late. Chris songs not on the to see anymore. That's true, but it's his last quote unquote last he said he was going to show up. All right, it's about five past. I think we've waited long enough. Lexus, you want to get started with that six members of the to see on. Hey, thanks very much Chris. Good morning or good afternoon everybody. Welcome back to the meeting. I'm sorry I've been away for such a long time. Let's just jump straight into the agenda. And we're going to go through presentations today and we're going to discuss the Prometheus graduation. A bit of working group stuff and of course the announcements of the to see the results. Let's let's do that first Chris. Actually, you've got the keep announcement first. What is this slide six. Yeah, this is basically I'm just letting people know we're canceling our meeting on May 1st. It's just a lot of sort of the conference and instead we're going to do kind of boot hours. So folks like Alexis and I will have office hours at the CNCF booth for people that want to talk to to see members. I don't know who else on the to see is going at cube con, but it would be nice to know so I could add you to the office hours list. I'll be there Chris. Yeah, okay. Feel free to reach out to me over email for those that are on the to see that want to be on the on the office hours. I mean, it would be good for anyone who's a to see contributor to meet other members of the to see. So I think, you know, we should continue to strive to bring people together. I don't know what you and Dan feel about doing something, maybe attaching something to the GB get together. Perhaps you could buy everybody a glass of something fizzy. Okay. Yeah. Sounds like sounds like an idea. Cool. Okay, so let's go on to the election results. Now Chris correct me if I'm wrong, but this is these results are voted on by the other members of the to see. Yep. Vetted candidates who step forward and are the two seats that are elected by the to see from those vetted candidates. Correct. And they stand for one year. They run for one year and two years. Correct. Yep. Okay. Well, first we can make the announcement that Brian Grant was reelected in Quinton who was elected as for the second seats. So Solomon is no longer a to see member and we want to wish him the best and thank him for a service since this whole thing was getting started. So there's 10 total candidates that are in. So thank you to everyone there. I'm sure that's the time to decide who gets the two year term versus one year term seat. So I'm just going to go share my screen really quick. See if everyone sees this. Are we confident there's no CGI at work here. Yeah, I hope so. Everyone see my screen. I'll take that as a yes. All right. I'm going to go flip. All right. I'm going to go back to the slide. You know, how many, how many folks we have to do before we just head's it's done. So going back to the slides. So Brian gets the two year term and Quinton gets the one year term. So I will stop sharing my screen and we'll go back to Alexis. So thanks for participating. Everyone. Thank you. I really, really want to thank Solomon who I know he hasn't done to make every single meeting or even, you know, it's kind of similar meetings, but I do believe that Docker lending then support wholeheartedly to this process at a crucial stage and very important for the evolution of the CNCS. And please note that most of that originated from Solomon. He was the person who bought into the vision of having this community and Docker being part of it. And I think it's very important to recognize. Thank you very much, Solomon. Also, congratulations to all the candidates. We had a really strong field with some very close voting. Please, please do not be disheartened. If you didn't get, you know, what you wanted. Stand again, please keep helping. We really need your help to make this a success, whether you have a vote or not. So I'm going to move on to the next slide now. We're going to talk about primitives for graduation review. In my opinion, having originally sponsored the project, it has done more than enough to graduate. The number of maintainers has grown. One of the girls that Chris and Diane and I and the maintainers had a year ago when we convened at KimCon in Berlin. But one thing I will say is that Prometheus is still in need of a lot of help. This is a project which doesn't get all the limelight like Kubernetes does. If you know people who say, how can I contribute to CNCF if I'm a developer, there's plenty of work to do on Prometheus. You don't have to send everybody to Kubernetes. There are other projects as well. So I voted plus one for this. Anything else we need to say at this point, Chris, on this particular topic? Vote is live. Feel free to make any comments on the mailing list or GitHub issues if you have concerns. Please vote. Thank you. Okay. Thanks. Right. Next topic. The working group process. Yeah. So I could speak quickly on this one, Alexis. So we've been approached by a couple of folks that want to propose new working groups and we don't really have a formalized process where someone could just issue a PR like they do with project proposals. So this is just basically solidifying kind of what we expect folks to do. So I took our existing working groups and basically sketched out what their proposals looked like when they first came forward and outlined them. And now moving forward, we'll have a simple process where folks could actually submit a PR and present and, you know, comment and vote on like we typically do with projects. Any comments, anyone? So my big concern with the working group process is that while well meant, we haven't, you know, we don't have a system for working groups and, you know, we've reached the point now where we've explored the space a bit. We've kicked the tires. We've experimented. We've seen a few successes, a few non-successes. And now we need to get serious about it. So if anyone would like to help me and Chris to figure that out with a written document, I would really appreciate it. So please send Chris an email volunteering to help. This is a TOC contributor opportunity. Or if you have a vote or if you've recently been elected or re-elected, this could be a great chance to prove that everyone made the right decision. But please do help. This is an important area. Without some clarity, working groups will stutter. They can't continue forever based on energy alone. So what exactly are you asking for? People to volunteer to help me and Chris write down a document with a bit more structure around what is a working group, how it's supposed to run, what its objective should be, how to propose it and things like that. Are, is explosion of working groups a concern? Or do you think that's a good, a fine and good thing? I think a greater concern for me is that some of the working groups have, are not quite sure what to do next. And what their, you know, what the exit and success criteria are rather than an explosion. So this is Dan Shell, we're presenting, you know, safe working group proposal later in this meeting. I don't think that, you know, I'm necessarily in a position to help in this definition, but I want to sort of raise our hand as we're going through the process to be a guinea pig and fodder for, you know, testing this process and working through that. So, you know, please feel free to lean on us, you know, in that process. And, you know, we'll help document along the way. If we have a partner in the TFC. Thank you. Yeah, Alex, you can count on me to help you guys out. I mean, that's my ideas based on the workgroup effort so far. Appreciate that. Thanks. Okay. Great. Okay, the next slide is project proposals. So we have tally presence and open messaging coming up with the Sandbox. I should just say a word about, I know we had this show of hands vote on Sandbox versus some other names. There was an even split between Sandbox and workshop, and people seem to be settling down around Sandbox. So I think that kind of concludes that discussion. There wasn't a clear, clear vote for an alternative I'm afraid. So, unless anybody wants to throw themselves in front of the truck right now, Sandbox, it's going to be. So we have the two proposals for the newly named junior tier coming in. I'm the sponsor of tally presence. I have interviewed several customers of the project and users, and I'm quite impressed. It does fit Sandbox well in the sense that it's not completely obvious that it shouldn't be part of a larger project or go in really what direction to go into. But I feel that it shows the right kind of green shoots of a young project to deserve backing at Sandbox level. So I'm just going to go ahead and give you a little bit of a quick overview of who is going to stick up their hand for open messaging, Chris. No one yet. Okay. So that one's looking for a sponsor. Should we go straight into Richard's presentation? Sure. Can everyone hear me? I can hear you, Richard. Yeah. I've been clear. All right. So, so I'll start in slide 12. So the problem that we're trying to solve with telepresence is just improving the experience of the app dev on Kubernetes. So I'm going to talk a little bit about the development environment for Kubernetes. You essentially have two major choices. One is local development using something like mini cube or Docker compose or now Docker for Mac. The pros are you don't need a network. You're isolated from other developers. So any changes you make, you have your own little Sandbox, not to overload the term. You can use all your local tools like your IDE or auto reload with some configuration. You can't run resource hungry services, right? So as soon as your application goes beyond a few services or maybe one service, if you're using Java, your laptop starts to get really hot and it starts to melt down. And so the alternative then is cloud development where you run Kubernetes in cloud and then you have some sort of deployment system like scaffold or draft or CI or something. Any of these things. The pro is that you can guarantee that your production environment and your development environment are exactly the same. You can run the exact same version of Kubernetes in the exact same place. The challenge is that it requires a network. You can't use your local development tools. There's a higher latency. So you have to push to registry and do all these things and developers sort of an inpatient bunch. And so on slide 13, so this is why we created telepresence. So telepresence is a hybrid model. You essentially run all your dependencies, your services, your databases and applications in Kubernetes in the cloud or locally, depending on your configuration, but typically it's in the cloud. And then the service that you're actually coding on or set of services, you were actually run locally in a container or directly on your laptop. And the benefit is you're able to use your development tools like your IDE, your debugger, auto reload, curl, et cetera. And by running the rest of your application in the cloud, you can actually use cloud databases and you have access to unlimited compute and memory. So on slide 14, the way this works is we deploy a two-way proxy on the Kubernetes cluster. And we also run a client locally on your laptop to connect to the proxy and we expose things like config maps, secrets, access to other services. We also let you proxy to other cloud resources like, for example, Amazon RDS or any other sort of cloud database. We actually, telepresence has really grown organically. So we actually have currently three different methods of proxying, which we are trying to figure out when we recommend one versus the other. We have a VPN type approach, which uses S Shuttle, which is a VPN of RSSH. We started with this method called Inject TCP, which injects a shared library by hacking LD preload on Linux or dinlib on Mac into sub-process. The benefit of Inject TCP is it works with your existing VPN. And then we also use, we also support using Docker run directly, which lets us hijack and take advantage of Docker's networking capabilities instead of maintaining a VPN of our own. So that's generally how it works on slide 15. So we have about 700 stars and growing pretty steadily on GitHub. We have a bunch of users. Bitnami is actually, and I see ours on the call, she's giving a talk at KubeCon about how they use telepresence with KubeApps, namely, company at New York City has actually integrated telepresence with Istio. We've got a couple case studies from some other companies that use site machine users telepresence because they run a lot of ML. And the ML programs don't work well running locally in your laptop, but they also want to use PyCharm, the IDE. And then we also have a variety of non-public enterprise users who I'm happy to talk about off-list. And like I said, the common use cases that we see are people are, they want to use IDEs or their laptop isn't powerful enough to run everything in Minicube. So a lot of people start with Minicube and then they run out of memory and they start looking for something else. So last slide on telepresence. So our interest in CNCF is we're really focused on the app developer trying to reduce that friction and building multi-service applications on Kubernetes and sort of, there's been a bunch of threads. We've been talking a lot with the scaffold team, but we really would like to try to grow the Kubernetes app dev community in general. We think that's sort of one of the big next frontiers in conversation around how do we improve. And there's lots of stuff going on with the application CRD and the app dev working group and developer tools and workflow. I just think from our own experience that the maturity of the developer experience on Kubernetes is definitely a work in progress. We also would like to expand the telepresence community. So the core maintainers all work at DataWire today. We'd like to expand to other maintainers. We have some maintainers who work on very relatively small parts of the system. Like we have someone who helps with open shift support and we have someone who packages telepresence for specific Linux distributions, but we'd love to get some more core maintainers and also more users who can help each other because there is a lot of sort of best practices and configuration and we don't use every single IDE under the sun. So yeah, so that's the basics. I'm happy to take any questions. Yeah, I had a quick question. It seems that, so you do need a network connection from your laptop to the cloud in order to use this. And given that, I guess one alternative approach would be to run the IDEs on the cloud and use like a virtual desktop, remote desktop kind of tool to get to the IDE. Did you consider that approach as an alternative? It seems a lot simpler, but I can see some downsides. Did you think about that at all or weigh it up? We honestly, we started telepresence as just a prototype and we didn't spend a whole bunch of time thinking about it. So the honest answer is we didn't really consider running your IDE in the cloud. Since then we sort of thought about it and it seems to be a little complicated. And also with some of the things, I should have actually talked a little bit about some of the things that we are actually working on because probably the biggest piece of feedback people want is faster startup and better reliability over poor network connections. So we're actually working on things like auto reconnect and speeding up the startup process because right now starting up a telepresence process takes 20 to 30 seconds and it really doesn't need to. So we're trying to get it down to two or three seconds. And I think that deploying your IDE remotely would probably be harder to do with that setup. So if you don't mind quitting, I can probably add on to that. For those of you who don't know me, Matt Farina, I do SIG apps over in Kubernetes. I work on a lot of the app tooling. So when it comes to IDEs though, Visual Studio Code is the most popular from the latest surveys. There's Vim versus Emacs debates. This for developers is a really personal thing. And I think the popular dev tools like this are all still desktop based. The cloud based ones haven't taken off as much as the traditional desktop ones that we have all used. And so I like that telepresence hooks up this way because it's not forcing you to use a different IDE. It kind of meets you where you're already at. Just to be clear, I wasn't suggesting using a cloud based IDE. I was suggesting just running an IDE on essentially a desktop in the cloud and then using a remote desktop technology to get to it. Not running a cloud IDE. So running exactly the IDE that you normally run, but just don't run it on your laptop, run it on a cloud server. Yeah, and I think that's an interesting proposal. And I have to say we just haven't thought too much about it. But yeah, so I don't have a great answer for you. So other than we have a thing that works now. Thanks. Richard, maybe one other point of clarification. The debugging that this facilitates using your local development environment and your local tools. This doesn't extend to distributed debugging scenario where you were able to debug services that are running on the remote cluster. No, we're, I was just referring to, you know, especially like Java developers like to set breakpoints. Right. And in their IDE and things like that. So it's really debugging scope to your single service. But we, we don't really touch anything around, say distributed tracing, for example. Yeah. Anyone? There's a question about volume out since the container is running locally. So, so one of the things we actually support is if you're using the container method, if we actually let you, I mean, we just pass through incantations Docker run. And so if you want to do a local volume out into your container, that's one way you can actually support hot reload with your IDE. So you can save to your local file system. That volume is mounted into the container. And that actually gets proxied to proxied into your Kubernetes cluster. So, so that's a technique we use for auto reload. It's a little trickier if you want to use a debugger. So just elaborate on that though. Are you saying that you can or you cannot share a volume between your local development and the thing running in the cloud? You can. Okay. Thank you. Yep. All right. Well, thanks everyone. What, what, what do you kind of expect the project to end up looking like, you know, down the road when it's been in the sandbox for a while, coming out of the sandbox, you expect it to end up being a standalone tool or some sort of library that gets integrated into ideas or, or what kind of thing would you expect going forward? I think this to me, this is a grand experiment, right? And this is one reason why I like the sandbox concept because we're not sure if it may, it will ultimately live as a standalone. We think it's useful functionality. That's important that people will use, but we can see it being integrated into a larger projects or it could be maintained as a standalone thing and more functionality will be added over time. And that's one reason why we would be very happy to just get more users to see sort of what the trends are. Because right now I can tell you the trends are IDEs and mini cube and I can't put enough RAM into my laptop, but that may not be true as we grow. And so, so I certainly don't think we're ready for whatever the incubation, I think. Yeah, so, so, so the short answer is we don't know and we're very curious to find out. Richard, last question from me and that's maybe this is obvious in the documentation, but I'm only seeing references to mini cube as the where you would run your local services. Is, is that correct? There's a dependency there and that's kind of the only supported local cluster. That's the only supported local cluster, but that would be and there's some people who use that configuration, but that's more of an anomaly. Usually your Kubernetes cluster would be running in the cloud and then you would run the service that you're coding as a local process on your laptop, not if that, if that makes sense. Right, so you can run it locally on your laptop or run it locally on your laptop inside a container. So those are the two most common methods and then everything else runs in a Kubernetes cluster, not on your laptop. I like this idea and I'm willing to be the other TOC sponsor. Super, thank you. Hey, Richard. I know Camille's not requesting this, but I think it would make sense for her to be put in touch with the same people that I spoke to as your end users. Sure, yeah, that's happy. I'm happy to do that. Anyone else? Okay. I think we are moving on to the safe working group proposal. Thank you very much, Richard. All right. So we're going to start on slide 17 and bop into 18 pretty much right away. Hi, everyone. I'm Dan Shaw. I'm joined today by JJ and Sarah Allen. We are the co-conspirators that have been pulling together this working group proposal that centers around secure access to build, you know, now that we have our infrastructure sort of elevated into the cloud, we all have shared visibility from operators to administrators to developers to DevOps to that cloud infrastructure. And our group has identified that, you know, it's there. We have access to it. But what's lacking is a shared vocabulary and shared mechanisms to convey that system integrity to understand that we do indeed have secure for all of those parties, the access and a safe system that we're working with. So JJ, we'll take over for slide 19. Thanks, Chris and Alex for having us over here. So like what Dan mentioned, I'll go over a little bit of what safe is about little history and why is part of it. We believe secure access is an end to end concern in a heterogeneous system. So security solved within a system doesn't actually lend itself to providing a full-on end to insecurity. We've seen this several times in several systems and we all believe that this needs to be addressed as a common concern. So the idea is to understand the common problems around security with all these infrastructures and then centralize infrastructure, which to some extent is already happening with Spiffy and Opa and a few other projects, but then that needs to get centralized. And that's the vision and the idea with which we're driving this effort towards. A little bit of history is this appeared as a common problem way back when I was brainstorming with Chris last summer. So obviously we weren't ready for it at that time and many of us organically came together over time to address this as a problem. And a quick note on why us. I'll be happy to address any of the pointed questions after that, but I just wanted to give you a brief overview of what we're trying to accomplish here. Why us? Many of us who have come here has previously built security infrastructure at scale in some of these companies like people from Netflix, CloudFoundry, Google, and I think Torrance here as well Opa. So a lot of people have faced customers, faced real problems and a lot of us understand that this is a common cross cutting concern across heterogeneous infrastructure. So and with this collective knowledge, we hope you'll be able to address many of the system architecture that's required for an end to end secure access. Come up with common vocabulary to help define us into insecurity. And we also believe like there are lots of gaps and libraries and protocols that needs to be introduced or built to enable a full on end to end secure infrastructure. And the idea is like this empathizes more with the operators and developers as the workflow happens. So security becomes built in process along the way. I'll touch briefly upon how we plan on go about doing it and we'd be happy to take any comments on this and suggestions to improve this process. We had a draft charter which we have it done and then the vision statements all there. We went through discovery where a lot of people including people from NASD presented their use cases and their understanding of what secure access means. And you've gathered a lot of it in the document. It's still an ongoing process. And with that I'll hand it over to Sarah who will carry us through the details of how we are planning about doing it. For those that are playing along at home we're on slide 20. Sorry I was on mute. Thanks JJ and Dan. So I'm going to talk about primarily this sort of steps two, three and four and how we get to having some clear recommendations in this space which is actually pretty fractured right now. And I think there's a lot of projects in the CNCF which are doing good work in this area. But like JJ says that we are going to slide 21, like how do we pull together a secure system? How do we even describe it when, you know, if we have Spiffy and we have Opa, those aren't themselves enough. Like they have to probably be combined with other things and there's a lot of people who have strong opinions in this area. So we've come up with this process that seems to be working really well that we've been doing like Dan said since January where almost every week we have a presentation from one of the members or our guests where people will share the problems that they're experiencing, the solutions that they have, where they see what's leading them to want to collaborate or what's working for them. And often we'll have like a half an hour presentation and a half hour discussion which means that we're pulling these use cases out of data that's more than coming from our experience and more than what's in our head, which means that we are all discovering together, which is just turned into like a really nice community exercise where we're all having deeper learning in the space that is beyond our own experience and we're all curious about these systems that we each, our developing software that needs to interoperate or in some cases are deploying them into these systems together. So that's really the discover phase that we're in when we finish up these use cases, then we'll attempt to draw some kind of diagram. Some people in the working group thinks we can't have one, maybe there are three. We don't know exactly what it is, but after we have these use cases, we will at least attempt to make a draft of that. And we think that by breaking up into these three phases that'll kind of help keep us focused and help feel like there's momentum because we expect this to be a little bit of a process, a time consuming process, but with artifacts emerging from the process, every couple of months, we think that even though it takes a long time, that it can be very fruitful in the interim. So the second phase is really looking at standards because there are a lot of standards in this space. We'll look at the CNCF project, see which standards are widely adopted, whether there are clear winners that are working for the community and we can just highlight those in a clear way, whether it's fractured, whether people are adopting different standards and thereby not interoperable. And out of that process, really we find the common definitions and come up with a vocabulary or glossary in this space because like in many of these cloud native technologies, people are using different words to mean the same thing or overlapping definitions and terminology. And then we can call back to the use cases and see where they're used potentially. And so after that kind of cataloging of the standards and protocols and definitions, the next step is to really catalog the projects. What are people using in terms of software solution, which CNCF projects are related, and fill in the boxes so that we end up with really sketching out what this ecosystem is and what we want it to be. And we anticipate that there are some gaps. There are some that each of us is motivated to come to this working group because we see gaps. We don't necessarily agree on what those are right now, but by the time we get to phase four, we think having that shared vocabulary and having a deeper understanding of the space that's written down, we think that we can clarify what those gaps are and they may be improvements that we might say that this project, we recommend adopt this protocol that four other projects use, or it might be that there's a project missing or a library missing or we're open to what those gaps are. And what we want to do is by pulling together as a community that we can focus on making some recommendations about filling those gaps in a way that's going to be efficient to getting us to this end-to-end security that crosses clouds and crosses on-prem and the cloud providers, which we all see as a critical concern for anybody who's doing substantial cloud-native apps. So this all culminates in a recommendation. And I'm going to hand this off to Dan, who's going to review our proposal. Great. So that'll land us on slide 22. So with that, with the context that this group that's been gathering since, basically Kuba Khan in Austin last year and meeting regularly this past quarter, I thought that that interest in this cross-cutting concern of safety is a great fit for the CNCM a couple of non-goals. We're not here to choose a single provider or single security technology. And obviously we aren't a standard body for creating standards. But we are a broad group of concerns across the cloud ecosystem. And we'd love to bring this to the CNCM and our asks are specifically, we'd like to get as many use cases in. We've already gone through a few, had some great presentations from the folks at NIST, Cloud Foundry and Google. And we'd love the opportunity in this discovery phase to work with members and projects and integrate that into this broader safety story. And we're looking for a TLC sponsor that is going to join us for a fairly long journey. So I want to make sure that you're aware upfront that we expect this to be a bit of a process, not an infinite process, but a better part of the year. Thank you very much. Now we'll open the boxes. I have a question. If there was a security project that was in the sandbox or incubation, just doing open source code, what would you like your relationship to be? So at present, I believe what we can offer to that group is to listen and provide feedback in terms of the data that we've collected so far. But at present, we are not in a position to direct or add towards the solution. So we can partner, we can help them gain perspective on some of the other concerns, other peers that they may have in the cloud-native ecosystem, but we would not be mature enough as a working group to provide any explicit feedback or any explicit direction. So I thought about this a little bit. I think everything Dan says is right. We want to set expectations that we are nascent. We've got a group of people that are coming together for a purpose and have, for many of us, an hour or a week plus the async activities is a significant time commitment. However, we think that by being a CNCF working group, we could potentially provide a structure where we say that anybody who, any new project that seems related, we would invite them to just sign up for a presentation. So then instead of us going and finding everyone, we would just have this steady stream. And so we would offer the TOC that after that presentation, we'd record it, we would write our summary, and in the discovery phase, that's pretty much all we would do. We would, the observations of the people of the working group. Later, we would be able to place this project in our diagram, in the landscape, and we would ask them to validate, is this feel like where you belong, right? And so we would, it's not like new projects are adopted every week or something. So there's a pace that I think would be reasonable. And then so the new projects are fitting themselves into the landscape, and then we're echoing that back to the TOC. We wouldn't have to present in a meeting or anything, but anyone could check in on that progress. And it might contribute to, it certainly would have helped me when Spiffy was being proposed, I tried to review it, and it took me a long time to see where it lived in the identity landscape. So that's an idea. So specifically, specifically to address the two projects that Alex has asked about in CNCF, I am part of Spiffy Six-Spec. So I'm working on it, and I bring in the perspective from there. I've been fairly involved in giving comments and feedback to OPA from way early on, and Torin is part of this working group already. So as far as those two projects are concerned, we're good to go. And for the new ones, we would like to have a similar or deeper integration with the newer projects. So we can actually flow back and forth the information. If not, we'd have to identify and understand like what Sarah and Dan were saying to make them present and us getting involved in that project. I had a question and or comment depending on which way you look at it. So a lot of this work has de facto happened in the SIG-Auth special interest group inside Kubernetes. It's not, you know, its mandate is not the same as this working group, but de facto for lack of a better place. These are where most of these discussions have been happening. So question, what is the relationship between this working group and SIG-Auth in Kubernetes? Or stated another way, I think that it would be very beneficial to have a very close working relationship between those two groups. Otherwise, we're going to end up with, you know, two bodies doing very significantly overlapping work, potentially diverging. So I'll let Sarah or JJ speak to SIG-Auth, you know, specifically. But another Kubernetes group, SIG Policy, we've already begun sort of cross-pollinating with that group. So yes, all the work that's happening in Kubernetes is kind of leading a lot of the direction that's happening. But, you know, there are all the other, you know, infrastructure components in the cloud-native ecosystem that, you know, aren't Kubernetes. And, you know, while some of this, including myself, may believe that the Kubernetes is the eventual future, you know, it is, you know, an implementation. So, you know, with this working group, we really want to be the clearinghouse for those cross-cutting safety concerns and bring those together, bring the interests of SIG-Auth, bring the interests of SIG Policy into this overarching safety concern and, you know, collaborate with those groups. JJ or Sarah, do you have anything to add? Well, I think that, like, in some ways, I haven't been involved in those working groups, but, like, we will do both less and more, right? Because it certainly initially, we're not going to get into the details of specific implementations and how that ties into, you know, the different, you know, like how we'll have representatives from Google. We won't dive into how it works inside of Google. We'll have representatives of Kubernetes and vice versa. And so we're already excited to have people involved in both groups on the policy side. And I don't know, JJ, is there anybody involved in the offside or do we need to reach out there? No, I think I've been in touch with Jordan Leggett and Jordan Leggett is aware of this. And I don't know if anybody else in SIG-Auth, of course, Joe Beda is aware of this, but I don't know if anybody else that I know of that is aware of this effort. But certainly, the idea is to, like, reach out to them and then get this cross-pollinated, like what Dan and Sarah are saying. And also, there is, we've also noticed, like, a bunch of the discussions around A-back versus R-back versus, like, other things happening in quite a number of places, whether it's in SIG-Auth, SIG-Policy, Spiffy, Opa, which are all the same discussion happening in multiple different places. But then it's something that we can actually, we feel like we can solidify a structured conversation and a structured understanding of what this means within this group. And those are the kind of problems I think initially we'll end up solving to give the structure and give a block architecture for what the security concerns are. They'll fit in well with the rest of the folks. I don't quite understand the overall scope. It's access control, but safety is a very vague term. And so I'm not sure what it covers and what it doesn't cover. Also, obviously, we've got nature in tough NCNCF, which are obviously concerned to some extent with access control, but in a slightly different way. I'm not sure if those would be considered relevant or not because I don't understand the overall scope. So I didn't hear nature, what the projects you referred to were. The update framework and notary. Notary. So in terms of the scope, we've spent a lot of time wordsmithing this and it's not quite perfect. But what we found is that there's a big, it's hard to put bounds around this and this is why we need this vocabulary. For a while we were talking about policy, but policy is very expansive space. We focused on access control, but that's sort of a way of not talking about policy, which is an implementation. But it's more than access because you, there's certain configuration management, which could be a vulnerability. Like if I don't, you know, if I have, you know, quotas or so forth, and the truth is we don't know exactly what the bounds are, but we know that from the discovery we've done so far that there isn't alignment on what it means to have a secure architecture or a secure, like what it means to make sure that your system is protected in a consistent way when you have multiple pieces of software in different clouds or on-prem and cloud that have different definitions of how they secure their system. And so we want to dig in so that this is clearly defined where we're not saying, you know, we've said, okay, well, like if I deploy a piece of software and it has a vulnerability, that's out of scope, right? But that I was allowed to deploy that software and that it was configured in this way, that's in scope, right? I think, but it's generally this, like what is the secure architecture and how do we know that, how we intend to deploy it? Our intention matches the reality when I have 10,000 VMs across multiple clouds. So in short, imagine, imagine, we are imagining how it would look like if we were to implement AAA authentication authorization and auditing across heterogeneous systems with episodic access and things that needs to get addressed part of that, right? And it's a well-defined protocol, but given the complexity of the heterogeneous system, it's not a well-understood and well-structured end-to-end architecture. And that's essentially what we are after. It sounds like the Update Framework of Nature would definitely be in scope because that's controlling how you deploy software, for example. But you're saying things like intrusion detection are definitely not in scope because that's nothing to do with intended deployment, although it's tooling related to whether things behave as intended. It does feel like the concept of end-to-end is important here because it's likely to involve multiple different projects and that will kind of be addressed by a single project. Right. And I think there are a couple of things that we are not that help clarify. And I tried to get us to distill down to a single word and we went through security, right? The security working group, my goodness, that's a lot of land grab. And same thing with policy. We looked at that as like, wow, there's so many permutations out of that. So safety and the secure access gives our group focus and we have spent a lot of time in trying to get that clear. And, you know, we know that it is, you know, we would love, you know, the turn of phrase that would get everybody aligned and understand immediately what we're talking about. So we understand that as a bit of a gap. But this is the space that seems focused enough that allows us to really add a lot of value while still making progress. Okay. Well, we're low on time. I think the key next step here is for people to, well, first of all, thank you to the presenters. I think this is a difficult area. We've got a lot of different concerns from top down and bottom up. I don't want CNCF to become an organization where working groups instruct individual projects kind of what to do, because they will typically be exploring things very close to what users want. If something like this became drifted away from, for example, what's happening in, and the parts of Kubernetes that are concerned with security, that would probably be a concern because it would be unlikely that people would pay attention to the group if it was differing from what was happening in practice. So I think you'll need to figure out how to do that. And the second area is, as Justin brought up, scope. So I would strongly recommend that everybody use the GitHub issue to help the team around this proposal to clarify those two areas, please. We did see this previously with this storage group where there were, at least at the beginning, there was sort of parallel efforts around what's happening in Kubernetes APIs and what's happening in the working group. So the sooner those two things are brought together, the better for everybody. So let's take this offline and take it to GitHub and then come back in an update. Does that sound good? Great. Thank you. Anyone else want to say anything else about that? I think we've got a couple of minutes left to have an update from Ken on the reference architecture if you want to, Ken. Yeah, sure. Just for everyone on the call here, since out a couple of dates on a issues list on the CNCF GitHub. So if you would like to join, kick off me, we're going to have a meeting, I think, on Monday afternoon at two o'clock Pacific time. Set up a meeting invite on the CNCF calendar for that timeframe. And if you're able to join us, please do. And we are going to be looking at the existing reference architecture landscape work and propose next level down in detail for more of a technical reference architecture in that meeting. And all feedback and comments are welcome. So please join us if you can. And I'll just remind folks that we have a lot of users now at landscape.cncf.io or just l.cncf.io. And that is based on off of this reference architecture. So if you're able to join us, please join us. And I'll just remind folks who are not happy with the categories that we have now or think they should be combined or split up or such. It's Ken's work here that will lead to the next generation of the landscape. Okay. I think either I'm getting cut off or Dan is, but I think we reached the end of the meeting. There is no TOC on May the 1st. Repeat. No TOC on May the 1st. Can you just repeat that, Chris? Yeah, cancellation went out. Great. Thanks. Okay. Thanks everyone. Thanks everybody. Take care.