 It's so disorienting it being one o'clock. All right, so let's, we have Michael Ducey and somebody else said that they could scribe, scribe. I heard two voices. This is electric, yeah. Super, thank you. Justin Cormack, do you want to check in first? I don't have a lot of reports this week. I missed last week's meeting, so yeah, nothing missing. All right. Brandon Lum. Hey, so I looked at Aaron's PR again for the clarification identity stuff. I think it was good, just like one or two clarifications needed. If anyone wants to take a look and comment a little bit more, I think, besides minor changes, I think it should be good to merge. Super, you want to include the PR in the notes? Yeah, I'll do that as well. Great. I'm next. I don't really have much to report either, other than I, we have all the transcripts and Michael, other Michael, last name I'm spacing on, who's leading the microsite group is we were going to mock up some content and we have a logo. So that went out on Slack. And so I've requested that Amy, that we get the designer to put together like a whole web palette based on the logo, which I think will help with the microsite and lots of whatever we have to do, we can now have a set of colors and a logo and that's new to you. So yeah, nothing much in security land for me, other than, oh well, something that was pretty interesting is I went to D web camp and learned about a bunch of peer-to-peer protocols and databases like Scuttlebutt and the interplanetary file system. And they're all and self sovereign identity in different ways that they're using the blockchain to not have to have a single identity service. So that was pretty interesting. That's my check-in. Michael Ducey. I have been absent and I apologize for that. I got caught on a trip and then vacation and vacation overlapped Wednesdays, two weeks in a row. But I'm back and I will be back from here on out. Not too much to report. I saw the email threads around the security days. So I'll wait until we get to that, to talk about that. But work rise was at all of the column last week. We have some interesting things that we're thinking of with IBM and some work we're doing with them on the open source side. So that's pretty much it for me. Okay. Emily, you're next. Emily Fox. So I like Michael was out at Audicom last week and I emailed Emily Ruffback concerning logistics and some other events, specific information for security day. We'll talk more on the agenda later about some of the decisions that we need to make today. That way we can continue to move forward with the events. Great. Thanks, Emily. Gareth. After being new member last time, I took a look at the new member issue and this other proposal around that. Left some comments. I think ultimately the idea of having something that is for new members would be really useful. I think I made two main points. I think it's worth having something that is targeting people who are like SIG familiar, who've been along to strange things like this before. I think it's probably worth having something for people who are like, what even is this? Like this is weird. I also think it's worth having examples in there. Basically like stories of like previous issues that have moved through the process, like how they got picked up, like what the success was, I think that will make it easier to go like, oh yeah, I understand how this works. But yeah, I left some comments. I'm happy to pull some things together if people have specific stories. I'm happy to like write something up, but I don't have the individual bits that people have done. Yeah, that's, I'm gonna put, if we have time before JJ arrives, if we need to brainstorm that a little bit or maybe talk about it next week. Cause I think it would be neat to have like a little sharing from people who've been around for a little while about like, what did you do when you were new? That was helpful, both to the group and like helped you on board. I think that's a really neat idea. All right, if people want to include that on the issue, it's like on GitHub, I'm happy to then collect all of those together and make that into a thing. Great. Sounds like that would go well on a page on the microsites. I'm happy to chat to Michael. Well, the first iteration of the microsite is focused not on the SIG. Not on the outputs of the SIG that would let people know more about cloud native security. Thanks. So maybe just a page in the GitHub repo to start with. Yeah. Actually, can you link that issue into the, I stuck it on the agenda, but maybe. I will. Yeah. In the chat, I'll put it in the notes as well. Okay, super. Aaron, carefully. Yes, as someone who is not a SIG, excuse me, who is not a SIG expert, I would certainly use some of that guy's comments on the issues. Looks like Brandon and all respond to your thing and then hopefully pick something else up, but other than that, I've not picked up anything this week. Thanks, Aaron. Carlos. Oh wait, no, I miss skipped. Lakshmi is next. Sorry. Yeah, I'm sorry. I missed last week, nothing from my side. I just saw that Garrett made some comments on the issue. I'll try to take a look as well. Okay. Yeah, some of his comments make sense, yes. Carlos. True. Good morning. Jonathan Mediums shared with me some ideas about threat modeling. He developed a good threat model for the Kubernetes and I'm reviewing and adding some notes on that particular work that Jonathan is developing right now. I will also finish a couple of tests with some security companies related to the Kubernetes project that we are managing internally. Well, that's pretty much it. Okay, thanks, and let's just let's hear your muted. Let's give you a second to get off mute. Maybe we lost you. And then I think I see a couple of people who aren't on the attendee, Ray. Hello, my name is Ray Lajano. I'm actually new to the cloud native and security space, just seeing what the call is about so I'll be over at Kupon in November. And yeah, just saying hi. Great, welcome, TK. Do I see you there? Do you have an audio check-in? Sorry, I wasn't muted, just a little bit late. Don't have a lot actually just on the IEEE 5G roadmap. I dug a little bit deeper on that and seems like there are some interesting architectural proposal which obviously identifies security as a very critical component for the 5G infrastructure which is obviously an integrated system of many, many different architectures. And one of the key points in that architecture that would be interesting to us is the virtualization. So SDN, NFB, inspired virtualization as well as compute virtualization and as well as the storage virtualization, they are all playing a very key role and they are obviously focusing on the security that will play a pivotal part on the part of how security is gonna be handled in the virtualized world. So that's what seems like on the roadmap, a long roadmap for 10 years. So there's a lot of people getting involved, many carriers are there, many vendors are in there. So it's a mixture of everybody, even the end users. So it might be worth following that one which I am doing right now. Great, yeah, it's great to ask your updates from you on that group, Justin Kappos. Yeah, so I've been in Tokyo talking at the Open Source Summit and at the Automotive Grid Linux event there and also meeting with a bunch of the automakers. They're deploying something that's a variant on the Tough Project, that's a CNCF project. And apparently my talk caused quite a stir because there's two different articles, one in LWN, one in an automotive venue that were written based on the talk I gave without anybody talking to me, like interviewing me separately or discussing afterwards that I just saw today. So yeah, at least they seem to be getting more security awareness, thankfully. Great, spreading the word of security all over the globe. Amy, I saw you join the list, but maybe you are, you appear to be unmuted. Better? Yes. Oh, I don't know why that works, but hi, yeah, I'm back from a week of WED. We've got a logo that is finalized, I believe, because I heard no more complaints and we'll be moving forward on getting that all put in beautiful places and with a color palette and probably some fonts as well. So good fun. Fabulous. Robert, on the phone, if you can, oh, listen only, updates below. Further discussion on formal verification plan today on the policy call. So people who are interested in that should join that call. And yeah, Robert, if you could share stuff on the Slack after the call, that'd be great. So that people can follow along who can't make it to both calls. So I appreciate that you chiming in there. Do we have Santiago here for the supply chain? We're going to chat about the supply chain proposal. Let me just ping him and see if he's joining us. I'll wander by his desk and see if he's around. Well, we'll get started. Great. So while we wait to see if that's happening, does anybody who has been around for a little while care to share a story about how you got involved in this SIG? And particularly if it's a way that somebody else might, and you picked up an issue and you did a thing or you gave a presentation or did something that then contributed to the group and made you feel like you were contributing part of it. I'm Emily Fox. I work for the National Security Agency. And I got started after listening to Justin Capos' talk at CubeCon Europe and decided that it was really interesting all the work that they were doing because it's work that I've done within my own organization. And I thought it would be a great way to contribute back out as one of the things that the NSA can do in the open source community. So I started with looking at a couple of the issues and asking Justin a few questions. I submitted a few tickets and then made some pull requests and then started commenting on the think security day ticket and then got involved in that. That's really how I got started. Thanks, Emily. I also want to point out that like, because Amy just dove in and made a bunch of changes to improvements to the guidelines for the security assessments, kind of based on some, I think there was some discussion in the group about things not being clear. And as a new reader, she was able to make those things more clear. And then I noticed that there was inconsistencies across the edits there and edits elsewhere, which led me to know that I should put more things in the style guide. So having a new reader make, clarify things, like kind of helped us grow the whole, you know, our process a little better and making, you know, like every time somebody goes through this onboarding, it makes things a little smoother. Are there any questions from new people about what Emily did and things where you might not know to do, do you know what I mean? Like how did she know to jump in? Maybe I should ask that. Emily, how did you know where to jump in? I have a habit of looking for trouble. Just going through and if I don't have the ability to explain it to like somebody in kindergarten or second grade based off of the material that I'm reading, I figure it's always an area for improvement because just because I work in the field and I can understand a lot of things that are going on, doesn't necessarily work when we're trying to expand security awareness outside of our field. I work with a lot of developers, system administrators who are more or less completely clueless when it comes to security and how to apply it to cloud native architecture. So even just documentation and guidance, which is usually where things are, they leave a lot to be desired, always start there and then just pick something, even if you're completely clueless about it and just run with it. Because the worst off that you do is you provide support in a documentation kind of capacity and you learn from it. Otherwise, you might find that you have a lot of experience to lend to the group. I think that's super helpful. And I think what I'm hearing is that there are people who are very used to that process of, yeah, we expect you to just jump up and do stuff. And there are other people who haven't been in a group where that's the norm. And so there might be places, particularly the folks, I think Erin and Gareth who are chiming in on the new member stuff. There may be places that we haven't thought to write down like, hey, do this thing that some of us are accustomed to being in this open-sourced world where you just like jump in and do stuff. Which is, and to some degree like maybe in contrast with other groups that people are a part of or other areas where maybe not all groups are so much this way. I don't know. KubeCon's an interesting proxy for things like that. KubeCon keeps growing, but 70% of people in EU were brand new, they'd never been before. And if you've been to most of them, it's easy to go like, I see all the same people all the time. Actually, there's way more people just joining the broader community all the time. Yeah. And I think that we aspire to support asynchronous communication, right? Like Howard's super active yet he's in China. So a lot of it, like he helps lead the policy breakout in the afternoon, in my afternoon, somebody else's middle of the night. And I think that we want that to thrive, that people can be parts of this group and not be present at one meeting because they're in a different time zone and still participate in all the discussions. And likewise for KubeCon. So thanks for mentioning that about KubeCon. I had no idea that it was 70% new people. Fascinating. Does anybody else have a story? I have an interesting tale. I walked down the hallway and found Santiago and he's now in my office. So I wanna be ready for that part. Oh, hello. He's ready to talk, but I don't wanna interrupt the newcomer story. Oh, well, the newcomer story was waiting for to see whether Santiago was gonna join us. But I think we have Santiago and at least Justin Cormack, unless you had a newcomer story, you were dying to tell Justin Capos. Nope. Okay. So I wanted to give a little space to talk about the supply chain proposal and I'll actually just share my screen. And cause I think we've got two out of the, there were a few people who chimed in. But Santiago, do you wanna just introduce the concept while I share my screen and bring up the issue? Sure. So the basic idea is that during the, in total security assessment, we realized that there was not a lot of content aggregating information about software supply chain security in general. This meant that for example, all of the software supply chain compromises are not somewhere to be like, how to say verified or there's no history of like, all of the compromises that happen every day that you can just go and look and find. There's also no information about how to like, tighten your security release process and like cloud native world and, and or references to like academic information that you can find where like the whole idea came from. So I basically drafted this proposal in which we basically start with aggregating all of this software supply chain compromises for people to query and explore. And hopefully in the future, we can expand this to also include like resources on how to tighten your security release process and then further into more like abstract, like a knowledge base of software supply chain security information. Yeah, and I think I'll also chime in because I think that I just became, one of the things that we did with the in-todo assessment is we kind of helped clarify the edges of like what in-todo does and doesn't do. And then it raised all of these interests. I remember, you know, like an interesting discussion on like, oh, well, this stuff is outside of the scope of in-todo, but Santiago, you actually know a lot about this. Sketching out the whole landscape seemed more of a sig thing and too much to put on the in-todo project. And so it would be like, where are there, either maybe there are gaps or maybe there's just other things that we want to help point people to close these gaps. But I also want to leave the floor for other people who chimed on this issue to said that they wanted to help to talk about what you envision helping this becoming. Yeah, I mean, I think we talked about trying to give people an idea about the different kinds of supply chain issues that they could understand how they how they feed into the different kinds of things they should be thinking about. Because I think that people often just hear the term supply chain compromise and there's actually kind of lots of different kinds of compromise that people don't understand. And so generally just I'm not sure how much a list is actually going to help. I think examples are more helpful because I think maintaining a list is going to be very difficult given it's a rapidly increasing area. But having concrete examples and pointing to the kinds of issue that caused that and the kinds of mitigations that are available for that kind of issue is helpful and give people background on the kind of level of risk there is. Yeah, and Emily, I'm just bringing up your since she's on the phone, she can't see this comment that you made about typecasting attacks, right? That to maybe draw from that list so that there could be typecasts with examples rather than a time-based list which would imply that we're going to like somehow keep it up to date. Yeah, so my worry and also like something that I would I kind of think that we need is the ability to create types or categories or classes of supply chain attacks that happen. There's a lot of potential attack factors within that space that a lot of people don't even know about or they don't even think about it. The supply chain is probably one of the last things that most people look at, especially if you're just working on something small that blows up into a startup. It's having that listing or at least a point of reference for people to go to about the kinds of ones that are out there, what they look like, the character traits that make them up and what the corresponding impact of that looks like. I mean, just thinking about Docker last year and all the crypto mining container that was on it and we're still finding even libraries doing the same thing. People understand the attacks are happening but they don't know necessarily how they're being in or what to look for to prevent and that's really what needs to happen. Not necessarily a full blown out listing of every single thing that exists I don't know that that's humanly possible but more lumping them together, identifying groups of like objects that they're seeing now and what could potentially come out of that. I mean, I agree. I don't think we just need an exhaustive list but I think everybody here is saying that we're basing off of this incidents, drive some insight. So I think in a sense we do need like a knowledge base that we can build off and that's why I think it would be a good idea to at least have a list that you can just query or like, hey, all of these things have happened and then we can evolve from there and have other documents living in the same space saying, hey, so here's this taxonomy that we came up with and types of attacks and probably these are some technologies that you should take a look at if you are concerned about this specific attacks on this specific family of problems and so on and so forth. So yeah, and I think the, I like the idea of having a list to refer to like, here's a bunch of examples and I think that there's a way to present the catalog. So if it weren't exhaustive, it would be fine, right? It's not like it's a CVB database where we need to have a list of every single one that has ever happened, right? Santiago? Yeah, I agree. And I think having like this list, I think it's also good for like people to contribute and go and say, hey, I read this article, like I think it's a supply chain attack. I'm making a full request trying to add it to the list and let's discuss about it. I think the benefit of having that list makes it so that people can just walk in and have a discussion. Yeah, I like that idea. Like if there's some sort of invitation to contribute to it. Right. If I may, I would like to extend this classification I hear a bit because coming from a startup that never has enough resources to even do all the understood best practices. Supply chain management for, or software supply chain management definitely is a cultural thing because I have to educate my developers. So it would be very helpful to identify even in the most roughest of categories, the low hanging fruit. What are the first three to five things I should protect against? And what are those things that I should only do in order to protect against, I don't know, a nation state attacker or something like that, which is not on my direct threat list. Yeah, absolutely. I think that things like patching Jenkins are very much on, should be on the list because these are things that people are compromised for a lot and Jenkins plugins and stuff like that. These are things that are actually really common and we can definitely find examples for them and they're very relatable and they're not nation state attacks at all. Yeah, I agree. I think also we need to think of having this grow a little bit organically in the sense that all of those are very, very good ideas but I think we probably want to start with something small and bite-sized and then eventually start growing into a guide that's prioritized for different types of threat models and then have this type of taxonomy that also grows and it's discussed about. I feel that if we try to go too broad and do everything at once, we'll eventually have a debt project with like half-baked ideas, the very little value. Well, I think at Santiago as the facilitator, I think you have an opportunity and an obligation to make the first iteration fit into the scope, right? So we had scoped this as a relatively small first bit and so I think pulling together the people who, like after we have this discussion and people give feedback from the wider group, like making best use of the brain power that has volunteered to help to get something within that relatively small scope that then if there's enthusiasm to do more then somebody else can take on that initiative and expand it. So I think that approach would be very much in keeping with what we've been doing. I think those are very good ideas but I think it's also great to start building hype and have something that can say, hey, what if this, it's up there and then we can go on to the next thing, so on to the board. Although some of those ideas inform like what this first catalog would be. So I think it's having that come out of it and then you can also capture all of the different ideas as potential next steps. Right, yeah, I was thinking of ticketizing all of this and saying, hey, all of these things are desirable, community wants them and there are like something that we can work towards in the future. Yeah, and I think that like, we might keep the, keep it as notes in the issue and then break out the tickets after, you know, where, what the first thing is gonna become. Right. Are there, in spirit of this discussion, are there other ideas, ways that you would imagine this might come to fruition that would be good? You know, I just listened to this, but it occurs to me that at some point is supply chain protection as well as the tough and all of these things need to be somewhat transparent at the end to the actual developer, meaning they should be intertwined or embedded with the existing or most popular tools that there are. For example, someone mentioned with Jenkins. Jenkins may have already some protection mechanism as to how the CICD operates and how it protects, for example, all the incoming flow and the sanctity of it, whether it's hashing mechanism or whatever. So is our goal going to be at some point that we create a guideline that we can publicize and also sell to most of these popular tool providers that basically controls all the development in the world. And so that this can be embedded and become ultimately transparent to the developer so that every developer doesn't have to start thinking from the scratch as to how they go about protecting their whole CICD and the whole supply chain mechanism. Is that the... Well, I think it's our habit too when we recognize improvements that could be made in open source things, right? Or into vendors where they have an open repository that we generally like write up issues. And we did that in the course of the in-todo assessment. And I think it's really the first step is to identify all the possibilities. And then we can move our way through making recommendations. I think this proposal is making the recommendations to improve the situation of supply chain security is one step beyond the current proposal. But I think that if things came out of it, like, oh, this is a common issue that if this part of our ecosystem did XYZ better, like writing up an issue with that recommendation, like with that observation is something that people should just do as a matter of course. But like we seek security saying, here we have a recommendation to the cloud native ecosystem about supply chain stuff. I think is like let's do the catalog first and whatever comes of that and then see what the pacing is on the energy to take it to the next step. I agree in general. I just wondering because things are happening quite fast, right? And if other people are doing similar type of thoughts and they're already embedding some mechanisms to protect their chain and the CICD pipeline and we are also proposing something. And then I like to see that all these efforts come to some sort of a real useful end at the point where people are actually using this and not duplicating it or proposing similar or going after the same problem over and over again. This is our show, there's enough problems to go on. Basically, the proposal came from the fact that this catalog does not exist that any of us could find and currently only exists as a note in the in-toto GitHub repository, which isn't very visible. And so really this is just a relatively small effort to take that sort of valuable list of supply chain compromises, right? And then surface it in a more useful way more broadly by making it part of the security repo or catalog or more, I mean, it could stay where it is. And I mean, the group will kind of make a specific recommendations on that. But also because it has specific relevance to cloud management, that's more gender important. Yeah. Hey, can I propose that we move on in the agenda just so we have enough time? Yeah, I was just pinging JJ who is not here yet. But I wanna wrap this and officially turn it from proposal to project with people belonging to it. So Santiago has already volunteered as a facilitator and then there are people who've chimed in on the issues who are willing to work on it. And I wanted to just sort of, and I think that we've talked about the scope of this initial effort. So is there any other tweaks to or recommendations about how this might be run as a small project before we hand it over to Santiago to kick off that effort? All right, great. Then I'll update the issue right after the call. And Santiago, if you would coordinate via Slack or your preferred mechanism and facilitate something offline asynchronously or synchronously or every you choose and then report back. And if it would be helpful to have a follow-up during one of the weekly calls, we can do that as well. Okay, sounds good. Fabulous. All right. So I think with or without JJ, we should, Emily, I'm gonna hand it over to you to talk about SIG Security Day. So kind of at a decision point with the overall construct of today, we have a room of pre-reserved for about up to 200 people. The question that we need to have an answer on is what kind of format are we going to run? So last two weeks ago, we had a presentation on unconferences and how those are run, which is not the way that normal concepts are run where we put out a CFP and get a bunch of talks submitted and we collect from there. So right now, we need to know if we are running the whole day as an unconference day or a normal conference day. This will affect rooms set up in layout. The current proposal for layout is a classroom style or a bunch of chairs in the room, round table distributed throughout the room. This would allow for more collaborative discussion to occur and follows closer to the unconference design and the last one is theater style, but I don't know that that's necessarily going to work for us. So I wanted to open it up to the group to find out what everybody's preference is. And actually, what I'd like to propose is that we talk about the format, like what we want to, how we want the day to go in this big group. And then I think the small group can figure out the room layout based on what's most effective for the format. Does that make sense? Yep. I think it's just that we have, we can accommodate the unconference, which we weren't sure about two weeks ago because we can set things up as discussion and there may be in these different ways. So we know it's possible. So I think we just need to narrow it down to three options. So we have basically conference style talks all day, unconference all day long. But my original idea was talks, unconference and then a talk at the end as like an anchor talk to kind of keep people around. And so we have nine, 15 to 12, 15 presentations, the open spaces and then the anchor presentation and then we wrap up. I think that's the, I feel like it's a good agenda that gives a mix of both for people. And if we do the rounds, it will facilitate the open spaces. Yeah. Just to chip in like this sort of format has worked really, really well for DevOps days events. Like it tends to be just a good mix of like structure and then like freedom. So I'm good with that. The email that we got from Emily Ruff is that the event needs to run from 8 a.m. to 5 p.m. So I'm pretty sure that given Michael's proposal, we can certainly make that work for us. And I personally am a fan of the idea with the round table layout to enable more collaborative discussion, especially if we can do more of the unconference session at least part of the day, which is part of the, one of the original goals was to get the right people together at tables to start having conversations and understanding that security in a cognitive environment is not easy, but it's something that needs to be done. Yeah. I think that, I think Michael, you like, you miss the sort of like a nuance to the, that Kalia contributed is that the like, which I think can happen with whatever format, like whatever degree of unconference stuff in it is that people are, if the more, like if it's like, if everything's unconference, then it's more self-generative, right? Everybody comes in with that expectation, which doesn't mean necessarily that there aren't anchor things. There aren't some prepared presentations. And I think the big question that we want, that we need to resolve today is whether we will have any CFPs. So we could, like one of the things that JJ had suggested is doing this format, like Michael's written down, which now I currently have up on the screen, Emily, by the way, that we could do the, we could have whatever presentations that we choose to do be invited so that we're not both managing a CFP and managing an unconference thing. Like, that we're keeping- The unconference thing doesn't require tons of management on the front side. I'm talking about people, how people feel in preparing for the event. If we do a CFP and choose a few, like two or three people to present, and we have dozens and dozens of people who have prepared a present, like, you know, it may change the flavor of the unconference to have a CFP and an unconference. Do you know what I mean? That's what I was talking about in terms of expectations. Yeah, and I'm not sure that we want- I'm probably just biased from having done several of these events, running them myself in this format and participating in a ton of events in this format, and that they tend to work fairly well. And what the presentations allow people to do is kind of prime the conversation. I would actually prefer to have some form of a CFP just from the perspective of that. It causes us all to get out of our own echo chambers and our own areas of bias and try to solicit things from outside our group so that we can pull from resources that we don't necessarily have, or we don't see every day, or we don't hear from every day. And then the open spaces, the way the open spaces work is more not necessarily that we need to have like prepared content or anything. Michael, I just want to let you know that since you missed last week, we had a half an hour presentation about what open space what is. So- Right, so there's many different forms of unconference. So I just want to make sure that we're in agreement with a type of unconference we're talking about in this case. So I think you and Emily can get together with JJ and talk about it in great detail. What I want to make sure that we have the whole, like that we have more space for is the pros and cons of doing a CFP, right? And get feedback on that from the wider group because what we heard. So just hang on. We heard from Emily two weeks ago that if we, so that it was already, all of the CFPs have already gone out for this timeframe. It doesn't mean we can't do it. I'm just saying that like the amount of time we will have to give to reach out outside of our bubble will be shorter than other things happening around KubeCon because of the... Yeah, we also have the advantage of a bunch of people getting rejected come mid-August that we can pull from as well. Yeah, I think the numbers play in our favor here. So Barcelona is an example. The CFP dates for KubeCon were even closer than they are for San Diego. Reject Conf actually ran an entire two days. I think even with multiple talks going on at the same time, populated solely by people who'd been rejected from KubeCon and they still had a CFP problem where they had like more submissions than they could take. So I think just down to scale of KubeCon at this point, I think if we put up a CFP and we put a deadline on a week, we would still be inundated with submissions. I think we would be inundated with submissions and I think they would be all the people who normally show up at KubeCon so I'm just talking about to the diversity point. That's all. And if we wanna do outreach that requires a longer... That will require more effort, right? And because if you want to make sure that it's a diverse set of people, right? You need to, as opposed to inviting a specific set of people who are outside of your normal bubble, you want to make sure that many of those people to your CFP so that you can choose the best options. So I'm just mixing up the conversation. I'm not saying that I'm not gonna be a decider on this. I'd like to put a call out for other people who haven't spoken to chime in on, give feedback to the team on CFP, yes, no, how to do a CFP to make it effective. And Emily Ruff who's not on the call will actually be, who's a CNCF staff person will help us execute on the CFP. So this is more to like have people in the group share with Michael and Emily about what your hopes and desires are for this. See my concern on this whole unconference thing and so forth is that, I mean, it's a great idea for being a storming but at the end of the day, you need to have a focus. We must have a focus as far as what we want to achieve. If we don't have a goal that we at least put forward in front of the audience, I mean, the audience can obviously, depending on their comments that can change, I understand that it can evolve, we need to have something as a focus as to what we want to achieve through the security day and where we're heading, some goal which could change based on the people's input and so forth. If we don't have anything and just go as a free form, can work probably on the first time, but I don't think it should continue like that and that's not very, I don't see how that is very productive. So I'm gonna get with Michael after the call and we'll get JJ and we'll probably have some conversations in the big security events group and we'll come to a resolution and then we'll update the ticket with the status. I do have to run right now, so I'll check back in later. Thanks, Emily. And to TK's point, this is not unstructured, no matter like whether there is unconference format or not, the ticket has very specific details around what is going to be accomplished and I think the goal of the day is primarily to bring together people to exchange knowledge and share across what their practices are and what they're doing and what Emily had said in the previous breakout was that the output would be primarily recordings of the prepared talks and then maybe additional notes that people chose to take them, but that the goal of it was really community building and knowledge sharing for the people in the room. I think documenting the outputs of unconference is really important. I think that having something that is not documented, CNCF event is not helpful if people aren't there and we should definitely encourage classes. Yeah, I'm a fan of doing that. But that's very different from saying our goal is together to create a X, Y, Z and at the end we will have that thing. I know, absolutely. Yeah, I don't agree that we need to go in with a preconceived outcome. I think having unconference is a way of bringing together people who have to find out what their concerns are and what they want to happen, what things are important to them and then we can then determine outcomes at the time, which I think is pretty important. Great. All right, so we will wrap my goal. Oh, great, go ahead. I wanted to get two more points of feedback from people real quick. One thing that CNCF suggested is a price of $199. I feel like it's kind of high as if we're trying to do more of a community oriented event. Does anyone have any point of feedback on that or higher or lower? Keep it as it is, who cares? Look at it, maybe you, Gareth or Justin if you have any, Justin Cormack. Yeah, and also people should feel free to type in in the chat, but yeah, I would like, thanks for bringing it up, Michael, I'd love to hear your questions. Yeah, I think that's an interesting question. I think if we could at least have some way of making it optional for people who can't afford to pay, that would be good. Okay. Yeah, I'd be happy for people to come who are not coming to the main event and therefore not paying X thousand dollars or whatever it is anyway to come because to make it more accessible, if possible. Yeah, off the top of my head, that would, I don't remember anything that expensive at Barcelona, things were, caveat, we managed to crash our currency. So I can't actually remember the dollars to pounds thing. The CDF event, which was the biggest event in Barcelona, that was roughly 300 people, I think. That was, I can't remember if that was free if memory serves, or if it wasn't, it was like $20 equivalent. There were events that were probably more like $120, like caveat currency. They're requiring people to charge at least $50, which I think is primarily around avoiding no shows. Yeah. And so I think, I'm sure we can say like, hey, if this is a hardship for you, like whatever price they decide, if the price would cause you not to come, let us know and we'll provide. There is a, just like a headache problem also with paying something. I know there was some event or something I had wanted to drop by and it wouldn't have been an actual problem to pay for it, but I couldn't logistically go and pay for it to just go and show up. So I think we do want to just be able to wander in. Well, I think they, well, I think that's a good, let's take that as feedback and we'll see how we can logistically make it happen. Yeah, sounds good. That's all I needed. Me and Emily will make sure that we update the group next week on this. Thank you, Michael. Thanks everybody, feel free to shout out on Slack. I think there's an events channel if you have follow-up feedback and thoughts after this. All right, cheers. Have a great week, everyone.