 Should we do it? Yeah, let's get started. I think them, we have forums, so we're good anyway. Go for it. All right, welcome everyone. I've got, I guess, who's got the slides? Is somebody, shh, bleh, can't speak. Engaged for mouth, right. Who's got the slides and can share them? Should be Taylor one second. Yeah, it's Taylor here. I thought they were there a moment ago. Yeah, we just had them up. What happened? Is Taylor still on the call? Because I'm also not saying being recorded yet. Yeah, one second. She's restarting. Ah, OK. God, she's hosed one second. Let's give her a minute. I guess it would be good to wait for Taylor, partly for the slides, but also for the record button. Yeah, no, she's got admin access. She should be back any second now. Looks like she's back. So, hey, Taylor. Hey there, I'm going to share one second. No worries. Great. I'm sure the recording is going to, because that's looked like it killed that. Oh, there it is. It's recording now. OK, cool. Share away. Let's get to the agenda and we'll get started. Yeah, all right. So while the slides come up, welcome everyone. We've got a few things to come through. There we go. I think we could move straight on to talking about KubeCon and ClanNativeCon, which, Chris, I imagine you have a couple of things to say about that. I'll just quickly, CFP closes for KubeCon North America on July 2nd. So if you're interested, please get your talks in. We're doing pretty well in sponsorship. So if you're interested in sponsoring, please reach out to us. We've had a huge influx in interest in co-located events. So we're doing our best to kind of accommodate, but please get your request sooner than later. Other than that, yeah, go ahead. July 12, 10 days from now, not the second. Sorry. Yeah, I'm still jet lagged from China. July 12. The link is there for the CFP. Next up is we've been doing these conference transparency reports for all of our events moving forward after the TSE requested them. So if you go to the next slide, Taylor, it's online available. There's a PDF and website that basically kind of breaks down number of tendons, number of companies, attendees, percentage of end users versus vendors, et cetera, et cetera. So it's fairly detailed. So feel free to comb through it. But a lot of data is available for you to kind of poke out there. We'll be getting the one done for China, hopefully by the end of this month also. So if you have any questions on KubeCon or the transparency port, let me know. Just give a couple of seconds in case anyone's got any questions right now. I have a quick question for the call for proposals. Are we only allowed to submit one? Is that right? Or is there a mechanism for submitting more than one? I believe you're capped to two talks per person that you could submit. If I recall, Dan, you may remember the rules offhand. That's correct. You can submit. You can be a speaker or a panelist for up to two talks. It doesn't matter who actually submits it. But you'll only be accepted for one. Right. OK. And you can do this from the same account. Maybe I missed something. But it seemed like you wouldn't let me add another one. But it was perhaps just me. It could be a bug if that's the case. You certainly should be able to submit two from the same account. And you can reach out on Slack or by email if you're having trouble doing that. But just as an FYI, we don't actually care whether you submit it or a co-speaker submits it. We're not tracking by who submitted it. It's who the speakers are. Got it. Yeah. I thought, Dan, that it limited to if the marketing people were submitting, the marketing person could only submit to regardless of whether if it was the same speaker or not. That was my experience last year. That sounds like a bug. So I'll take that up with Nancy, and we'll see if we can adjust the center. OK. I'll try and confirm that and let you know. Thanks. Thank you. Any other questions on this? All right. Six. OK. Let's make on to the six. So we'll be hearing from Six Security in a very short moment. Six Storage. I think the last meeting, or roughly the last meeting, we had a discussion about the co-chair and tech leads for Six Storage. And we're talking about two existing co-chairs. And we're looking for approval for Erin as the third. Is that how that works? That's right. We have two co-chairs right now, and we're looking to have Erin as the third. And we already have a couple of tech leads. Actually, we have three tech leads, and we're looking to add Brad and Louise as tech leads too for the various projects that we're looking to engage on next. OK. Any comments or queries or concerns from TSC folks about those people? I'm going to take that as everybody seemingly happy. Chris, do we need to formally have a vote, or are we just able to say? I mean, if there's no objections here, we have quorum. I'm happy to have it pass. I would also accept if anybody said they wanted to push off the decision. That's also something you can say. Otherwise, I think we should just approve. Just a comment. I think we pushed off the decision about a month ago to give people more time to consider it. So I think we can consider it now, unless there are specific objections. I think that's right, unless anyone has any new concerns to raise today. I think, all right. Well, they have my support. Any objections? Consider it approved. Thank you. Brilliant. Thank you, everyone. Great. SIGAP delivery. I know there's been some activity on drafting the, what do you call it, like the? Charter. Charter. That's the word I'm looking for. Thank you. Alexis, I know you're here. Do you think we are exactly in a good state to be discussed, to be approved? It's been shared with everybody who's on the app delivery SIG mailing list, which was everybody who responded to say they were interested in being in the conversation when we advertised it a few weeks ago. That's about 40 people, I think. So if you're listening to this call, go look at the SIG mailing list, which you should be on. And if you're not on it, email Amy and me. And Michelle, but if you look at it, you'll see references to the draft charter. And we're looking for feedback at the moment so we can start the process of getting potential chairs to nominate themselves. We're essentially trying to bootstrap the charter and the chairs at the same time. So we did an initial cut of the charter to give people a sense of the direction. And now we're sharing it with the community to help finish the charter. While we're doing that, we're asking the most enthusiastic members of the community to self nominate as possible chairs. I hope that makes sense. Any questions about that process? All right, so I think the conclusion there is it's not ready for a vote yet. It's still in progress, but, you know, it sounds like good progress is being made there. There is at least progress being made. I wouldn't quite guess as far as to say good. We have delays mostly due to things like KubeCon. But it is now in the hands of the right people together. And I think it'll be ready for a vote in probably four to six weeks time, I would hope. Great. I know there was also a discussion of a networking related SIG that I believe someone was interested in actually forming. Yeah, yeah. Yeah, hey, this is Lee. Yes, this is the answer. And soon, there's a proposal written that is, I would say, 90% draft complete and should be shared on the networking, working group mailing list shortly. Feedback and insight from Matt and Ken are forthcoming on that as well. So I think it's just still just an in-flight proposal. Okay, great. I think if you start following the model that SIG security, SIG storage and SIG app delivery have started putting in place, that seems to be working. So is there a form in your chart? Or is it just an informal group that's pulling to that stuff together right now? Joe, actually, I think I missed the first part of your question. Oh, is there a mailing list or anything sort of formal that folks can get involved with the SIG networking? Sort of. There is. That's still very informal. There is, we'll drop it into the chat, the mailing. Okay, and do we have any other folks interested in forming any other SIGs right now? Yeah, I volunteered to help set up the applied architecture SIG if there's demand. I just bit backlogged at the moment. I was intending to have started it by now, but I have not yet. I can't do it in the next few weeks if there's demand for that. So what's SIG I missed that one? It's called Core and Applied Architecture. So it's basically Kubernetes and applied architectures of Kubernetes. And I was just to be clear, I was just offering to kind of kickstart the process of drafting the charter and goals, et cetera, and trying to solicit some interesting people to serve on it. Now, that's an interesting name for it, but okay. I'll wait to see Mr. Omen. Yeah, and that's certainly the name is up for debate if you like it. It was kind of debated in the original SIG stuff, but it would be up to this new SIG to clarify the charter and if they decide it's necessary to rename it. Okay, great. It does look like a very large set of technologies there covering orchestration, scheduling, and runtimes, et cetera, so there we go. Okay, I think the one that stands out we don't currently have in flight is probably observability. So if there are folks out there interested or thinking about setting up a SIG for observability, that is open. For those of you who missed the last 18 months of discussion on Twitter, observability is monitoring, logging, tracing, and debugging. Okay, so I think we can probably, unless anyone wants to say anything else about SIGs, let's move on to SIG Security and Justin Kappos, I believe, is going to be telling us about SIG Security Assessment process that they've put in place. Great, well, thanks Liz. Yeah, so what we've done is we've set up a process by which we take a project for the moment. We've really looked at a few security projects and gone and provided a lot of security information and context at a high level. This is not meant to take the place of an audit but is meant to tell you things like what is the system designed to do? Where are the gotchas at? Where are the things that if you can figure it, you should think about it. What sort of protection should you expect to get when this is used? Is the project developed in a way that makes sense or are you likely to find a lot of problems with it? Things like this. So this is meant to be helpful for anyone who might sort of adopt it and also meant to let the TOC and others go and look at this and try to decide is this the kind of project that from a security standpoint, we want to have, you know, be admitted into this ENCF. And we're not trying to go through and actually go through and say, aha, we found a buffer overflow here or we found this issue there. There would be a later assessment by Cure53 trail of bits or whomever else the TOC contracts out to find those types of issues. Next slide, please. And really, as I said before, there's two main audiences here. We're really trying to answer these sorts of questions, from the CNCF end user standpoint to help you figure out what security properties you'll get by using your project and how to set it up correctly. And then the TOC to understand things about where maybe gaps are at in the TOC's landscape, how do we improve existing projects and so on. To this point, we've gone through and done several assessments. There's a very long and painful assessment that the Intodo project that went through as it was the first project to be assessed. So we kind of rewrote the rules, I don't know, three or four times as it went through the process. OPA is mostly through the process, we just need to do a little bit of sync up and declare them final. Key Cloak and Falco have expressed a lot of interest and I know Spiffy, Aspire and others are also, I think, ready for a refresher for this. Our plan is to conduct an initial set of about five assessments and then go through and sort of revise and formalize some of the steps that we're doing in a way so that we can make sure that things are much more uniform. I'd like to thank a lot of the people that have gone and participated in this, Sarah Allen, Justin Cormack, Brandon and Brandon Lomb and a bunch of other people that I'm gonna be embarrassed that I've forgotten that have started with it so far. And if you're interested in participating, please come join us and join our meeting on Wednesday at 11 a.m. Eastern time, whatever that is in your time zone and we'd love to have you participate. So I'm confused, are we just doing CNCF projects or non-CNCF projects? But we're doing projects that effectively from our standpoint, it's what's being recommended to us by the TOC. Okay, so what's the process for recommending that? Cause I don't think we discussed it. Not, I mean, maybe I missed the meeting or the email list, but where did that list come from? Projects. We had some initial conversation and Liz and others who know this should really step in but we had some initial conversation and we were told these seem like good projects. Like I think when the SIG was formed, there's like, these are these five projects that should be part of it. And that was tough, Spiffy Spire, Falco, Opa and something else, Istia or something else. I forget what, but something else that I'm forgetting. And then the Spiffy Spire assessment that I did before any of this was set up was kind of used as the model. So we said, we don't need to do them first. Toph has had a lot of assessment, thank you. And so then we went and said, Opa would be a good thing. And in total, when in total was going to come up for vote in the TOC, there was a discussion about why don't you be the first one for this process. So we would expect there to be a more formal way to do this in the future. And we're also need to have a discussion about should these be things that are refreshed annually? Is every project supposed to go through this so that we would look at Prometheus, which are other projects like that or what the process should be? Yeah, I just wanna make sure that we put effort into the things that are CNCF projects first or are well on their way towards a vote. And so I think definitely there's been discussions about some of the other projects you mentioned, but they're not really on their way to a vote right now. So that's the, and I heard T-Club there specifically. And I know that we've seen presentations from T-Club, but I don't know of any formal submission of T-Club to the CNCF. I know there's been a lot of discussion, but it's been happening one-on-one. And I wanna kind of bring that stuff into the public. Yeah, so this is exactly the conversation we wanna have. The process is that I just put a link to our new issues. We have an issue template. So any project or the TOC can initiate that and anybody can put out a request. And then the prioritization is something that we want, like the TOC influences, yet we weren't going to wait for the TOC to pick a project if we have bandwidth. So the idea is we queue these things up. The TOC influences the order, but then we have a team ready to be doing a security assessment at any one time. And so yeah, so we wanna refine that project. At the beginning we had these two queued up in total on request of the TOC and then OPA because it was the one in this list that hadn't had an audit or some kind of prior review. And they were involved in the group. And so basically we're a little ad-hoc'ing it right now so that we have some in the queue and completely welcome whatever process is appropriate for that prioritization. I mean, one of the things that I think we've been talking about across the TOC is getting a more sort of structured sort of flow chart in terms of how projects come in different stages. And I think it'd be interesting to look at this through that lens. And so again, so that we move from this sort of ad-hoc lot of one-on-one conversations and then something comes up to a vote. There's a bunch of stuff that gets started beforehand to more like, okay, this is in a sort of this stage. And so let's activate some of the gears to make sure we get a closer look across the various groups there. So yeah, definitely something we should take into consideration as we do that. So, all right, thank you. Yeah, and also the other thing I wanted to mention is that we thought we would start with the security-focused projects because one, they need an assessment. And the other thing is the people from the project really know their stuff. And then we wanted in this first five to have one project that is not security-focused but then of course has some security. So we're looking for kind of guidance on what that project should be, either by a project raising their hand and saying we really want to participate or the TOC identifying one that the TOC is particularly. Things would be a good candidate for like, this is a template for a project that has security but isn't for security. Okay. Yeah, I think it's worth having the conversation in terms of what that sort of non-security-focused but security-impacting project might be. I have some ideas but I don't wanna start that discussion now. Super, yeah, so just for people to start thinking about because it'll be probably after we get through the next couple. I think one thing that's quite interesting in the discussion of the flow chart here, the flow for projects in general is that security makes sense to review security-related projects and also makes sense to review non-security-related projects that may need to be operated in a secure way where I think other seeks, there's a more kind of clear, you know, if we had an observability seek and we were asking for the observability seeks opinion on an observability project, we might also want to get seek security's opinion of the security implications of that observability project. And I'd also argue that really for any project, you at least want to know that you shouldn't operate it in context X or context Y. And so I think there's at least some argument to be made that pretty much every project should go through this if for no other reason to say, like this is wildly insecure if you use it in situations A, B and C, so don't do that. Yeah, a lot of what we're finding is that the assessment process is a matter of saying, oh, maybe you want to put this high up in your documentation that things that the project maintainers might think are clear and obvious to everyone are actually a well-kept secret from a user's perspective because projects aren't aware of how users perceive them versus how they think of themselves. I think it might be useful to just circulate an example assessment so that people on the TOC can see the kind of recommendations that you're making. Well, coming up is the Intodo presentation which includes its security assessment. So this was very much like right before you're about to hear a sample assessment. So that's the first one we anticipate that it is like we've been through and like four to six iterations on it so and it is not perfect by any means. So that is the first of five that you will hear and then we welcome feedback on the format, the content, all the things. Justin, do you want to take this question about overlap with the independent security audits? Yeah, I was, yeah. So I think that the way to look at it is when you get an actual security audit and you read it, it's typically a very dense document where they've gone and they've pinpointed particular things that they say are vulnerabilities in a project. A lot of times the assessment is more meant to provide high level guidance about how to use something and the way to do it in the way the system is intended to be done. So an assessment will do things like help to guide the auditors about what to look at and talk about scoping and resources, whereas the audits that you go through typically try to pinpoint vulnerabilities. And so there's a few examples of that. You can see this if you look at, for instance, a lot of the audits that Tough Project has had by different groups or audits that other CNCF projects have had, there's a focus on, there is vulnerability X with severity Y and then that's probably been fixed three weeks later, but that doesn't tell you, when you deploy it, you should think about doing it way X, way Y, this is the secure way to do it, which is more of the assessment process. So I just wanna call it in the chat, somebody's saying overlap between, okay, so that's what you just answered, but then Quinten also had his hand up, I wanna make sure that. Yeah, I just had a quick question about, so there was originally a request from the TOC to produce like a white paper, and I think there was some debate about whether that was a good idea or not, but either way, it seems useful before going and doing a bunch of assessments to at least agree on some basic ground rules, terminology, these are the general approaches to the following categories of cloud native security. There's key rotation, this is what it means, it's typically done in the following ways, et cetera, those kinds of things. Do we have such a general framework before we go diving into specific assessments of specific projects? So just as a, before we, the SIG ever got in place, audits were happening, so a lot of this is, there's activities that are happening and that are needed for projects, you know, kind of for the projects to meet needs of the projects. And so the process that we're following is to do the activities that the experts within the group know how to do and have that informed the vocabulary. So one of the reasons that this INTODO project took so long was getting to alignment on what this assessment is, how is it different from the audit? How are these volunteers from various companies, what's an appropriate role for them to take given that this isn't their full-time job and how is that different? And with the knowledge sharing and education aspect of the SIG, how does that color this process? And so it might be appropriate. Do we have something that the TOC and end users can consume that says this is the scope of cloud-native security and these are the terminologies that we use and everything else should be read in that context. Do we have such a consumable piece of information yet? So as I was about to say, the scope of SIG security, which was just formed two months ago is specified in the charter and we're working on a roadmap, which we anticipate will include the white paper that was much discussed many moons ago. And this security assessment was just prioritized ahead of the completion of that white paper. And so it might be appropriate for us to schedule a presentation of the roadmap as that gets put together so that the TOC can give feedback on that. But yes, we do want to do that and we're taking a bottoms up approach. And so you can see the security assessments. There's a lot of vocabulary that is being used there but security also includes policy and compliance and a number of aspects that need more discussion in order to get to alignment about what the group is comfortable putting forth. Yeah, and I would also like to jump in and say that in these first five assessments, we are trying to be quite clear about defining things that we think are unexpected for readers. There's a stupid question phase that the person leading the security audit does where they expressly try to make sure that there's meaningful definitions for any terms that they think a reader might not understand. So, but we haven't formalized this process. This would I think make sense for us to talk about once we've been through the five assessments and we have a better idea of the right scope and fits into something like what Sarah was saying throughout the map. It is in the charter that one of the things that security will do is educational resources which include things like common vocabulary to talk about and understand cloud native security. So I think it's documented as part of the charter but I don't think it has to be done in, you know, the precise order that is laid out in the charter. And I think the fact that there are people volunteering to do security assessments is really, really valuable. There's a follow-up question about security and audits. So I think that that's still in process. Like we, so Justin Cormack reviewed all of the audits and we're trying to figure out what is our role with that and, you know, but I think that I think it would fall under sick security to coordinate with the auditors, but that isn't a separate CNCF process. So we'd love to see feedback about, you know, how to engage. I assumed it that it was a matter of logistics and that it would fall under our, you know, sort of broad. Because the auditing process started before sick security existed and has kind of got its own process going. Like many of the audits have happened already. We haven't been as directly involved, but some questions have come out of it which we're following up on. Okay. Any other questions? Oh, no. Any other questions or comments about the security assessments? I would definitely say it'll be really useful to see the example as we go through in Toto and we can see the kind of value out that comes through that. Okay. And a comment there from Sarah about some common vocabulary for use cases and personas. Quintin, did that cover your question? I don't expect that the use cases and personas covers the questions. It's just I'm trying to illustrate the bottoms up approach. So I'll drop in a few links. We've developed some resources and then, you know, and I'll point to some, and then we'll come back with a timeline on the white paper and the other things mentioned in the charter. Quintin, does that address your concern? It does answer the question which it sounds like the answer is there is not a complete body of information that I was requesting and I just wanted to point out this has been requested over and over from that group which previously was called a working group and is now called a SIG for over a year now. Actually, I'd like to correct you. We were not, we proposed to be a working group and the request was not clearly presented to the whole group and the priorities were not clear. So I think there was some miscommunication between JJ who was one of my co-chairs and myself. I don't know if he's on the call. And so there were things were prioritized differently because we got many different requests from the TOC and we weren't formally involved with the CNCF until a couple of months ago. So we've been doing work that the community that we felt was the community valued in, you know, I think a white paper is a grand idea and it's just not done yet. So to answer your question, this is JJ Quinton. I think in terms of the first problem that we had with security was the scope was too large to just to make sure that what's in scope and what's out of scope took a lot of iterations and that's specified in charter. And then the second stage of like what are the categories and then all the projects that are associated with the categories that needed some form of definition which I think we took care of. White paper is an in progress thing. There's a lot of different ways in which we can actually slice security. If you wanna layer security in terms of functionally, it's gonna look a lot different. If you're gonna layer it structurally, it's gonna look a lot different. If you wanna layer it based off of associated project, it's gonna look a lot different. But to even basically to address what makes sense and how we can actually make sense of this to the end users, a lot of use cases needed to be understood. And I think we spent a lot of time collecting and gathering use cases. This coming up with a white paper that's like functionally narrow will be easier. But for something like security, it's gonna take some time. And once you have something, then I'd want it to be a little bit more meaningful in terms of like how we can trade on it. So that's a long-winded answer, short-winded answer. Short answer is like we are working in steps to gather enough information so that the white paper is meaningful. Would it make sense to think about carving up rather than doing a single white paper, doing smaller, more focused white papers? I'd be open for, yeah. In fact, the policy working group, subgroup is working on a much more implementation focused policy white paper, whereas the white paper that JJ is referring to and Quinton's referring to is more the security landscape and the terms and all the different parts of security. So it'll be more of an overview, like one of the things that we struggled with is who's the audience for the white paper? And that we didn't get a lot of input from the TOC on that. And so we talked amongst the different members and people in the community and found that, and I had an interview with Quinton and it was really felt that it's the deciders who need this white paper of like, how do I reason about security in the cloud? And how do I know what, how to make these choices and what things should I be worried about one of the categories? And so that's where I think we could still use some participation of the TOC in validating our assumptions about who is that audience. And one thing we've talked about is could we get a few people who are from the end user community who are representative of the audience to validate the white paper so that they, you know, we could have reviewers who are outside of our group who could say, yes, this is useful content because we want to produce something that is valuable to the audience. Okay, so Joe and I are the kind of liaisons to sick security. So I think I would make a request to the other members of the TOC that if you have particular concerns about what sick security is focusing on, you know, let's discuss that and try and come up with a coherent message to the team there. Or show up to the meetings. That also. All right, any other questions on sick security? Or shall we move on? Thank you very much, Justin and Sarah. Thank you. All right, moving on to the question of archiving rocket. We brought this up a month or two ago already so I don't think it's a surprise to anybody but Chris has now created the formal request to do the archiving process. Do you want us to say something about that, Chris? Yeah, sure. I mean, we discussed this last time, I think about a month ago and, you know, I think we kind of decided to not, you know, necessarily rush this and kind of, you know, given that it's our first archival project, let's take it a little bit slow. So, you know, I've had some private conversations with the rocket team. I filed a public issue kind of notifying them publicly that we intend to do this, you know, per our process, they're supposed to have essentially two weeks, you know, to discuss or come up with anything before we formally do the vote. So that's kind of where we are right now. I just kind of wanted to kind of bring this up to see if there's any other further thoughts or discussions. I think we're just kind of being slow and careful here, notifying all the respective parties and community that this is gonna potentially happen. So from a process perspective, we'll formally call a vote in about two weeks if there are no strong objections from anyone. Okay, and then we're gonna help the team move documentation and project, you know, website or the rest of it. I'll figure that out. There's some other complicated things where I think they're also participating in summary code, but they're happy to do that. You know, still they're an open source project. We'll figure it out and kind of document everything. Okay. Just giving a moment for any other comments on that. Hey, this is Jay Pipes. Just a quick question on this. Is there a plan to have like official messaging from CNCF with regards to this archiving? We like CNCF blog or something, like explain the ramifications of it and that kind of thing. We haven't decided yet. I think I'll kind of lean on the TOC, but if they wanted to put forth a statement or something, we're happy to syndicate it on the blog. I personally, I think overcommunication is not a bad thing in this case, but I'll think, you know, I don't know what the TOC thinks about this. It's our first archiving. So we need to explain what it means to archive a project. Yeah. That's an area where I think the executive staff, Chris could help actually because it's not just about the TOC. I mean, this is a long-term decision. Correct. Like that is no problem, but I think from like a TOC perspective, like we archived it because this project is maybe inactive or doesn't reflect the value, blah, blah, blah. There's that that I'd rather see come from the TOC than necessarily staff, if that makes sense. So the technical commentary, what format would you like that in? Statement and paragraph? Yeah. Statement, blog, like Google Doc. Okay. Why don't we suggest, I'm gonna float an idea that maybe staff could like come up with a blog post with a space for us to comment. Like. Cool. Consider that done, not a problem. I might have missed it. Is there, is part of our communication sort of like talking about how projects can get unarchived or adopted elsewhere or what have you? Because I think that that'll help it feel sort of less final in case somebody makes the wrong call. And I know like in the past, we've said, oh, well, the TOC or, you know, the LF can decide to do this stuff, but maybe having something that's clear there will help soften this a little bit for folks. Going into the LF is not the end of the road for the project. It just means that it's no longer part of the cloud native tent for the time being. And I think what we talked about before was the idea that a project could be revived. I mean, there are many people who use Rocket who may not have noticed this and might come in. There's also people who've spoken on Twitter. I see Chris here from Kinvoke talking about it on the slide, for example. Right. I think, you know, I know that's what we've talked about. I'm just wondering if that's part of the communication plan. Do we have that written down anywhere or has that just been informal conversations? We have the reactivation archival process. OK. So that is part of the, you know, I'm just, yeah, just soften the blow a bit, you know. Yeah, we're sure. Au revoir, not. Go ahead, Alexis. I said au revoir, not idea. All right, so we'll share a post with the TOC and then we'll do our best to kind of fill it in. Great. Any other comments about Rocket or archiving in general? OK. Right. Ten minutes for Backlog. OK, so, Chris, I think this is to try and keep us honest and make sure we're working through the Backlog, right? Yeah, so, I mean, basically outside of the schedule for the community presentations, I think the important question to ask is, I think it's hard to say no always, right, and trying to find projects that you may want to say no to here and do it at some time in the coming weeks would be good. You know, we seem to have an uptick of interest now of projects wanting to come in. I don't know whether it's a seasonal thing, but, you know, we have quite a lot of projects in the Backlog right now, so I don't know if there's any thoughts of, you know, how you want to go about this, but I just wanted to kind of raise awareness and make sure everyone's kind of on the same page of what's on the Backlog right now. My understanding is that Longhorn is actually ready to present next week, is that not the case? We shuffled them around. They're presenting to the storage SIG first, and then in August they will present to the TOC and wider community. There's other ones floating around for a while, like CNI, Genie, I believe, and others that I think just basically need a kind of an answer of what we want to do with them. And I think also just referring to Joe's comment earlier, this is one of the reasons why we need a clearer sort of flow chart on what the process is. This is something that as the TOC we've discussed privately, and we have some volunteers. I can't remember who those volunteers are. I think it was Brendan and Matt to draw up a flow chart, because we need to get on top of this process and make it very clear not only what order things happen in, but also the etiquette of approaching C members, just so that everyone knows we are all now communicating with each other if we are approached about a sandbox project, because I think there were concerns that a bit like if you're a kid and you don't get the answer you want from dad, you go to mum, right? So, while it's totally fine to talk to TOC members we are now trying to over communicate with each other about conversations we're having around a project, particularly sandbox. Okay, so I don't know if anyone has any particular strong feelings about any of those backlog. I mean, I think Longhorn is going to be presented. Do we know about dates or prospective dates for any of the other proposals in that list? Some of the shift to August, I'm still trying to track down folks availability and so on. Chris, this is Erin and I joined late, so maybe I missed it, but do we have clarification of what we want for sandbox projects? Are we going to require a formal proposal and a presentation when the charter doesn't necessarily reflect that? Generally, I think the legwork of doing a formal proposal to PR and starting from there and kind of deferring to the TOC whether, you know, hey, maybe there's two immediate sponsors or they want to see a presentation and so on is, I think is a better path than just asking for a presentation to put us a little bit more legwork on the project. So we should probably update that in as part of the sandbox requirements so it's more succinct and then I'd be happy to put together an example. PR, what we expect is part of that, if that would be helpful. I just, I seem to kind of get a lot of these questions and it's not necessarily intuitive if you're a brand new project to come to want to present. I think that would be very helpful, Erin, thank you. And I think actually as part of that, that can help us as the TOC figure out, you know, whether there are other questions that we should be asking before we accept a project in at Sandbox or any other level, having a template for all those questions. Right, because we did that. Sorry, I didn't mean to cut you off, I have a lag in my network. It's, and I think we did a really good job at that with the due diligence and we couldn't put that together but I don't think we ever stepped back and did the same thing for Sandbox. Yeah, I think I completely agree. Great. Yeah, that due diligence is a bit vague with respect to the different categories. So it gives general guidelines about how to look at a project and how to evaluate it but it doesn't, it's not very good at distinguishing between these things have to be there for a graduated project, these things for a Sandbox, these things for a incubation, et cetera. Perhaps it's worth refreshing that document in that context. Well, and I think it changed Quentin, if you remember right, because we did used to do due diligence even on Sandbox and then we had so many projects it just wasn't scalable. So then we said, well, we're not gonna do due diligence, we're just gonna do presentations. So yeah, I think if we split it out into the categories and kind of loose requirements at least for each, it would give a better set of guidelines for the TOC that's consistent for every project coming in. Yeah, that makes sense. Right, that's all I had, thanks. All right, I think we can all take this as a bit of a kick to take a look at the backlog issues, see whether there are, and I think TSC members, let's all try to over communicate with each other whether there are some projects here that we do or don't, you know, if we have objections to a particular or concerns about any of these backlog projects, let's share those concerns so that we can start saying no, because I think this is one of the problems here we need to say no to some projects. Liz, as part of saying no to some, does there need to be a reevaluation then after we're finally done with the backlog to go back and based on some new set of standards, say no or say you have to come up to this next level? I just, I fear there's an inconsistency just based on the number of projects coming in, the changing of the TOC, the changing of the policies, that someone who did it a year ago compared to now isn't judged by the same, you know, set of rules. Yeah, I think that's completely fair, completely fair criticism. I think maybe having that kind of set of questions and the documented flow of how the project should work and perhaps if we are clear, something we talked about was the idea that when we say no to a project, in the hypothetical situation where we say no to a project, we should be trying to document why we've said no, but with a certain level of discretion that, you know, if we, you know, if somebody submits a project and it's just in terrible, terrible shape, and really what we're saying is this project is in terrible, terrible shape, we may not wanna say that publicly, we might wanna communicate that privately, but I think if we're having more general guidelines on, for example, this project, well, you know, we're saying no to it because you're not prepared to move it to a license that the CNC would, you know, that would be a very clear reason why we'd say no, and we should probably come up with a few more of those reasons why we would say no and why we do say no when we do, yeah. Also, I'm seeing, yeah, okay, so a couple of comments coming up here. So Lee was pointing out that the requirement to present is listed in the Sandbox process. And to my mind, we should have that presentation before TIC sponsors actually commit to sponsorship because otherwise, how do we hear about objections? Yeah, I think that's all right. Yeah, in my mind, the redirection of Longhorn to the storage, SIG is in part where I think those working groups in those SIGs are four. And so, yeah, that as a general, I don't know that we necessarily state that in there, that can be a way of ensuring some diligence, offloading the TOC sum, allowing the TOC contributors to enter in and assist. So I don't know if there are two places where that requirement, that presentation requirement is called out. And yeah, I don't know if refinement there is necessary or not in terms of funneling through a SIG first. One thing that I think is worth of taking. Sorry, go ahead. So one thing that I think it's worth updating the larger community on is the TOC got together and one of the things we talked about is just creating more communication about as projects start engaging with the TOC across different TOC members. So one of the things that we're doing is that if you talk to any of us about a project becoming a sandbox or incubating project, we just want, we're gonna share that information across the TOC as soon as possible, just to make sure everybody's on the same page. Because I think that, you know, things can get pretty confusing when there's a lot of one-on-one conversations. And we don't want somebody in the TOC having a concern and then somebody else committing to a sandbox project without having a chance to really have these things talked through. Thanks, John. Sarah, also your comments about having a clearer communication to the SIGs about how to prioritize requests and roadmaps. I think that does also make sense. Yeah, and we're kind of making up the SIG processes as we go along, but we'd actually anticipated that we would present our roadmap before presenting the security assessments and things because Intodo's been waiting for like six months to actually do their presentation and proposal to this TOC. We kind of did things out of order and probably should have acknowledged that. I really like the idea you just posted there about labeling in the backlog when a project proposal is related to a SIG. I think that could be a useful part of the process. Well, cool, yeah. I'm happy to do it. We're running up on time, so... Yeah, we are. Was that the end? Have we got anything else? Nope. Cool, see you everyone next week. Awesome, great. See you all next week.