 Hello. Welcome to today's light relief from everything else that's going on in the world. I think we are without Amy today, so I think Taylor will be driving the slides for us. Yep, I'm here. Awesome. I'll start sharing in a couple minutes. Great. Yeah, we'll just give people a minute or two to come in. Has everyone else seen an increase in spam, Gmail, comments, document comments rather. And I haven't, but in CNCF documents or elsewhere? I don't know what documents they are because I don't open them. Random Russian forms and comments that just mentioned me apparently. I'll be smart enough to open it. Yeah, I think it's probably best. But I guess, you know, anybody can tag anybody else, right? So I mean, yeah, I guess it's a new phishing scam. Well, so there you go. Public service announcement. Don't click on Google Drive comments unless you feel confident, you know, who's made them. All right, Taylor, do you want to start sharing the slides for us? Yeah, one second. Great. Thank you. All right. So welcome, everyone. Normal rules apply. You've made it this far, so I guess you knew how to join. Let's skip forward to the agenda. So we have a special guest today. I actually think maybe we should try and do the SIG updates, Bill, unless you've got any particular time constraints. Shall we do the SIG updates first? Because then Bill Mulligan is going to talk to us about some conformance ideas. And I think maybe that will have more discussion. So should we do the SIG updates first and let anyone object? If it's possible, I would prefer to go first. If not, I can also go second. All right. Now, if you have a preference, let's do it. All right. Over to you. Cool. Thank you. And Liz, thanks for having me today. In case you guys or in case anyone doesn't know me, I'm Bill Mulligan. I recently joined the CNCF. So hi, I'm really excited to work with all the smart people on the TOC and in the wider CNCF community. And now I guess maybe like two weeks into my job, I get to do my first presentation for the wider community at this TOC meeting around one of the initiatives that I'm helping and would like to kind of put forward as an idea that we'd like to have comment feedback and input from the members of the TOC. And so a little bit of background on this initiative. What I'm going to be kind of talking about is the cloud native network function conformance initiative that we're interested in. And so a background on the telecom industry in case anybody isn't familiar is originally there was like physical machines that were special built for kind of like one specific work purpose like a firewall or an ingress or what have you. And then with kind of the advent of cloud virtualization, a lot of people just basically took those physical machines and put them in VMs and like called it good, called it modernized and there we go. And now as we're kind of going to the next generation of cloud infrastructure towards containerization, the problem that we'll run into is we now take those VMs, put them into containers and once again say, okay, we're done. We're really missing a lot of the benefits of the cloud native ecosystem and the benefits of cloud infrastructure or things like Kubernetes can provide. And so I think one of the things that the cloud native ecosystem has done so well so far is really focus on at the infrastructure layer, what is conforming Kubernetes? Because one of the problems that we saw in the open stack world is that everybody had their own flavor of open stack and it really became does it work on this stack or does it work on this stack? And there wasn't a lot of interoperability between a lot of different vendors on different layers of the ecosystem. And I think Kubernetes has already solved a lot of that, those problems with the Kubernetes conformance program at the infrastructure layer. And so now what we're thinking about doing is applying those same concepts to help us ensure interoperability also at the application layer. And so Taylor, if you can go to the next slide or I don't know who's running it, sorry, or can I can I control the slides? And so kind of what we saw is in this evolution from VNF, so virtualized network functions to CNF's cloud native network functions is originally like it was just VNF's or better metal machines. And but now as we're going towards a cloud native world, we have a lot more moving parts in there. We have a lot more brownfield legacy from things that are running all the way literally down to like copper wires all the way up to containerized very cloud native network functions. And so one of the problems that we see is it's a little bit of a, oh yeah, so there's, MANL is management and like orchestration. So when you're actually like running, installing, upgrading like things in production. So if you're familiar with the ONAP project, that does management and orchestration of actually applications running. And so one thing that we, as we're moving towards CNF's is not only is there kind of like greenfield cloud native CNF's being developed, but there's also brownfield applications too. And one of the questions that I think is especially applicable in the telco domain, but also across wider domains too, is how do we, what it actually is a cloud native application? How do I, when I'm building something new create a new, create something that's actually cloud native. And when I'm looking to modernize my previous like VNF's, how do I make sure that they're built or modernized in a cloud native way? And right now, I think we all kind of know the definition from that the TOC wrote about immutable infrastructure, microservices, declarative infrastructure to help make high impact changes frequently and predictably with minimal toil. But that's great kind of like as a two second 30,000 foot like view. But the real question is, is how do we actually implement those best practices in the real world? So next slide please. So what actually is the CNF conformance program idea? And so the idea is to help telco vendors and the telco industry in general, to help solve some of these problems of how do we deliver cloud native best practices? How do we ensure interoperability between all the different vendor stacks? And how do we make sure that we can develop new applications in a cloud native way? And so what we want to do is to create a program similar to the certified Kubernetes program that allows us to take what we know, we can say this is a certified Kubernetes distribution to actually help us declare what actually is cloud native at the application layer. How do we put those cloud native practices, cloud native best practices actually into applications? So next slide please. And so the real question is this has been kind of like around for a while. And why is this super important to help out this industry today? And why am I bringing it forward to you today? Well, this actually is not something that's in the future. This is actually that is becoming a pressing need for the telcos today. So in a recent survey that was done by the Linux Foundation Networking, surveying the usage of Kubernetes in telco environments, almost 90% already running Kubernetes in any environments. So it already is widely used in the telco space. Next slide please. And this isn't just something that's in like testing or development. Over 50% of those telcos are already in production today with Kubernetes. And the slide I didn't include is they expect by next summer, next June, which is really, if you think about it, only about like eight months away, over 50% of them expect to be in large scale production. So this isn't something that's just a pilot is really running at a large scale, which if you think about the telco industry, they don't do anything small, you know, you start counting in the tens of thousands or hundreds of thousands. So next slide please. And I think the most interesting thing about this is in the telco domain, they're running both like the actual network and more like IT like workloads, but it's not just the stateless like web applications that Kubernetes originally began with, but it's actually running the core network functions. So if I picked up my phone and called Liz today, that connection could be running over Kubernetes right now. And so I think it really is important to be able to help move the telco really world industry into a more cloud native way and help them kind of like build these best practices as they're trying to modernize their infrastructure. So next slide please. And so, yeah, if I can have this one please, thanks. No, the goals one. Yeah. And so that's really at a high level, what this enough conformance program, like kind of our goal is, it's really like help companies better understand what cloud native means for telecommunication workload. In the same way that we were defining at the infrastructure level, like what Kubernetes means, we want to be able to help companies at the application level understand what actually cloud native means. So next slide. So our idea right now is in the program structure to create kind of like two different parts. So one is a CNF working group that will define the definitions of cloud native and the process of kind of like certifying CNFs. And the second part is actually like a test suite initiative, which provides the actual like tests and frameworks. So if I'm a developer at company X and I want to like build a new CNF or cloud native network function and test out it actually is cloud native, I can go download the test suite like run it against my application and say like, yes, it is cloud native or it isn't or like these are the things that I can improve on. Or if I'm looking to modernize an application, I can do the exact same thing. So next slide please. So what we really see ourselves, I think if you read the first line of the slide, we really see ourselves as the upstream definition for other industry work groups to be able to use in their downstream implementations reference architectures and standards to be able to like implement like specific like telco stacks. Now we're not trying to define like a specific telco stack or like specific telco like applications. We're really trying to help them understand and this is where I think the experience and the expertise of the CNCF really comes important here is that we understand like what cloud native is and being able to provide kind of like that horizontal like definition of what cloud native is across the industry, which can then be used in like further downstream initiatives. And so some of the people that we've spoken to who are already interested in using this are groups like CNTT, OVP. So CNTT is the Cloud Infrastructure Telco Task Force defining a reference architecture for the telco industry based on Kubernetes. OVP is the OpenFV verification program, which provides a badging program around network functions to ensure interoperability between different vendors, infrastructures, and network applications. In addition to those industries like outside of the CNCF, we also see a lot of ways to collaborate with many of the CNCF and Kubernetes working groups, including SIG app delivery, security networking, and the Kubernetes conformance working group. And actually, I think this last one is actually super important. I think we'll kind of like flesh out how we kind of think this program could come together. So next slide please. So what we really kind of like see this and if she does as is similar to the concepts borrowed from the I would say like hugely successful Kubernetes conformance program. So there is the Kubernetes conformance working group and Project Sonoboy, which together, if you think about it, in some ways provide like a spec and an implementation to understand what Kubernetes actually is in the real world. And so what this allows us to do is this separate the so the working group would allow us to understand, like define what actually cloud native is in the same way that it defines what Kubernetes actually is. And the actually implementation would be similar to Project Sonoboy and Kubernetes SIG testing, providing the actual like testing framework to able to test this against infrastructure or applications. So next slide please. And kind of some of the milestones that we'd like think about to like kind of target is in something like three to six months get this working group formalized under a specific SIG. And in the same timeframe in three to six months submit the CNF like test suite as potentially a sandbox project similar to Project Sonoboy. And if you're interested in learning about how we're thinking about the structure right now, we encourage you to check out this poll on GitHub and dive into how our community is talking about this initiative right now. And so if you like check it out right now, there's a lot of people commenting from really across the industry. And I think diving through this, you'll kind of see how we're trying to right now pull together all the disparate interests across the telco industry. So it's the service providers. It's the platform vendors. It's the actual network function vendors. It's the standards bodies. What we see the telco industry kind of is really all of these are all tightly integrated with each other. And sometimes are at kind of like they have differences of opinion of how things should be done. And what we see the benefit of kind of bringing this the cloud native to the CNCF is that the CNCF is really the neutral body that can help all of these different groups understand what actually cloud native is and how that can benefit the telco industry. So next slide, please. Next slide, please. So one of my slides got deleted. So the the ask that I would have for you right now as the as the TOC. Let me just actually drop the slide right in now so that everybody can see it on the same page. So there's kind of like three questions that I'd like to like pose to you all as the TOC is like who in the industry, who in the ecosystem, who among yourselves can help us define what cloud native and what a CNF is from the definition level. Who can you recommend that we speak to to help us be involved in this initiative? We like have a wide network in the telco domain and we're reaching out to as many people as we can across all these different groups. But we know the TOC has a lot of experience and expertise and may be able to have a wider network than we have. The second one is in terms of the structure, where do you think this would best fit in the CNCF in the in the Kubernetes ecosystem? And does the TOC think this would be an interesting or worthy initiative? I know we also have some people from the community here that have also been involved in this on the call today. So I think they could also provide additional comment if we're interested. But other than that, please feel free to ask me any questions that you have so far. I have a question, Bill. Thank you for great presentation. So there was a slide about supporting testing on a multiple levels application and the infrastructure testing support. Can you elaborate on the infrastructure testing support? What is supposed to be covered there and how deep will it go? Yeah. So we kind of see that as like a secondary goal in terms of like the infrastructure and what that would be is looking at like is like our infrastructure actually implemented in a cloud native way. I think our like really like immediate and like short-term goal is actually just really just looking at the application. Though like some of the service providers that we've talked to, the actual telco companies that we've talked to have been also interested in looking at like, are we sure that we're also implementing our infrastructure in a cloud native way? So do we actually have declarative APIs? Do we have immutable infrastructure? And are there ways that we can test for that? So that could be kind of a potential like secondary like stuff. And so really helping the telcom industry understand what cloud native is. Got it. So it's going to be case per case, right? It's not something that you'll download the tool and determine if it's built in the right way. That is more for each one. Okay. Thank you. For people not in this meeting, what's the best way to get in touch with you? Yeah. So sorry, I will also add my contact information onto a slide after this. So the and also Taylor Carpenter who's helping with me with this too. We'll also, also if you want to get involved like in this implementation specifically, please feel free to comment on the poll request that you can see here. But my contact information also drop it in the chat right now is just bmulligan at linuxfoundation.org. So please feel free to reach out to me. I'm always happy to chat with people. Yeah. And also the second part, yeah, Taylor, maybe you want to jump in with what's happening on the chat here. So the CNF conformance like test suite already has, Taylor correct me if I'm wrong, is it weekly meetings? So we're working to split things up between the new working group and the test suite itself. The meetings that are listed on the CNF conformance are really about the test suite and another initiative the CNF test bed. So if you're interested in getting involved with the test suite, then that's probably a good place for the working group. We're tentatively looking at 9am pacific on Tuesdays, but we got to find a space for where to start conversing about that. It was talked about during the telecom user group meeting on Monday as well, but the CNF conformance Slack channel is would cover both. I'll drop my email as well. If I may jump in. Sorry, folks. Hi, this is Bianca. Thank you, Bill and Taylor for your awesome presentation. I just wanted to add that at KubeCon CloudNativeCon in two weeks, there is a meeting, a community meeting that's open focused on this topic on this working group on Thursday the 19th. And I forget the exact time, but it's either 8am pacific or 9am pacific, one of the two. And so that would be another place to come back to after this initial conversation and then whatever branches of conversation happen to re-engage and move forward together. We're hoping that a lot of attendees from KubeCon find that valuable as well. So that'll be hopefully a big group. Thanks. Great. And thank you, Bill, for the presentation. I guess the question really for TOC is, do we want to see this falling under one of the six? I mean, it feels to me like it would be a good idea for us to at arm's length kind of be involved. It's a definition of what CloudNative means in this particular space. I think it's a great initiative. Lee already looks like you've suggested having a chat with SIG network. And I can see like the runtime overlap that Ricardo, you mentioned. Are you thinking about things like the kind of DPDK dependencies? Right, yeah. That's what I was talking about. And how you run the functions and how you schedule the workloads. That was my thought about it. But yeah, I can sync up with Taylor or someone in the group and figure out what SIG might be best. But I think network is another one, right? And Taylor, you're also mentioning SIGAP delivery, which I guess there is an interesting question here on if we start certifying certain network functions, which are kind of applications as being CloudNative. Does that say something about certifying a broader class of applications? I kind of hope not. I think the idea is to start with a smaller focus. So we're saying telco or maybe you could say networking applications where telco industry is part of the network domain. And those type of applications which don't always act the same as Bill had talked about. So keep it at a smaller focus and then if there looks like there's something useful to expand or have another one, then that could happen later. That makes sense to me. So from like a SIGAP delivery or SIG runtime or SIG network, any of those, the working group is more of what is that subset that's needed to help in the networking and telco domain? I wonder whether administratively, I mean, we have the SIG, the SIGs are there to help us with the administration, to help us with the communication. I don't feel like the actual, like the group of people who are going to work on this, you know, they can come from wherever the interest is. My natural kind of inclination is that because it has the word network in it, it fits nicely in SIG networking. From the, when you look at stuff below what we, you don't see my air quotes, but application level, I'll turn out the application, so that when you look at all the layers and Kubernetes is really about components and layering and add-ons and everything else. So below the application, if you start looking at additions beyond what Kubernetes conformance and the IDE test, now you start getting into all of the extensions and now we have like operators coming in. And that sort of level, when you look at telco and the network industry, I think that would very much work well under SIG network. When we focus it in on just the applications, and if we're trying to keep it as high up as we can, but telco applications, then it may fit better under app delivery. And I guess it depends if the scope is expanded to deal with other layers. Does the CNF conformance cover the things like, I don't know, latency and jitter and that kind of network characteristic? So from the test suite itself, there's capability to test all sorts of things. I mean, we've added recently support for using cluster API and checking, does this host have cluster API enabled? Is it being managed by cluster API? So you can talk about infrastructure, but that's a test suite thing. When we're saying the conformance program and having like a certification and the working group defining what would be there, I think it would just depend on do we care about that at the application level? The telcos themselves, I mean, operators are going to come in and say, yes, we need to know this because we have agreements that we must meet. I don't know if we want those type of functional requirements as part of the program versus saying it behaves in a cloud native way. And you need to do other things to make sure that you've implemented functionality requirements like jitter is not beyond something. So just looking through the conformance tests, that being within the SIG network, it doesn't necessarily constrain the focus of conformance to layer three or therefore, not proverbially, but to the OSI model. If that was part of the concern, what's the most prominent example of a CNF that you're looking to verify cloud native conformance of? Can you say that a different way? When as you articulate and characterize the definition of a CNF, the canonical use case or example that you give is what? Okay. So one of them that I guess an example that we have in there is just a simple IP forwarder, which you're going to have that capability. And you could have something like doing deep packet inspection on stuff that could be a capability in a firewall or it could be if you split things up, maybe it's an individual component that's running. So if you break up the words of what network function, the actual definitions and saying something providing a capability on in the network or the network packets, but when you get into telco use cases and stuff, you start saying, oh, okay, this use case actually has DNS and it has some type of authentication and access control, often radius. But if you would start looking at how would I build this in a Kubernetes native, which would be an implementation and cloud native in my mind, then maybe you'd go, well, why are we using radius? Why don't we move to something else? And you see that in some projects where they've actually moved on to other things. But normally it's going to be those higher moving a lot of data. If you're familiar with the mobile networks like evolve packet core, you're going to have gateways at one side that come in and they have to deal with some type of session manager for the different connections from the towers, keeping up with those and moving in between and then pushing it through until it gets into the core data network. And then eventually you get off and your phone hits, whatever, some voice service or video service or because this could be delivering TV or whatever it happens to be. But those are going to be the normal applications like when you hit, this is a video service. That's after it's already gone through that core telco or network core and moved on out. In the interest of time, perhaps, Bill, you can answer Josh's question about telcos that are involved in this conformance effort. And then I think we should probably try and move on to the SIG updates. Yeah, absolutely. Yeah. Yeah. So as I was saying before, we're reaching out to people all across the industry and we also already have multiple telcos involved in the effort. So specifically like here in Europe, Vodafone and Orange in the U.S., we're talking to a couple of, yeah, okay, thanks Taylor. So also Balkanda Charter and talking to a few of the other major carriers in the U.S. right now too. And so our goal is to really have kind of a cross-section of the industry because I think the vendors and the service providers are really all tightly coupled together. And so make sure we have a good representation from each of the groups. And I am suggesting that unless anyone thinks it's a terrible idea, we should normally have this working group fit under SIG network. You know, that absolutely still encourages participation from anybody from any other SIG as well. Yeah, Taylor, if I think if I were to read into it a little bit, that or maybe I'll say it like this, that things that are dealt with within SIG network aren't necessarily, I guess I said that before, aren't constrained to the network. So SMI conformance is an active initiative that's going on, for example, that's somewhat, I bring it up because it's a similar concept, so easy to relate to. Its implementation is done in CRDs and so those are deployed using all the higher level constructs. But given that service measures in general, they touch on a lot of those things that are outside of network, but are somewhat network centric in there in its focus. And so it's sort of an example of like, I don't actually think if you would take any project in the CNCF almost any, I don't know that any of them like totally cleanly fit into one SIG versus the next, they just kind of have a center of gravity. But I don't think that there's any artificial or intentional constraints put on the projects themselves in terms of what they end up incorporating or how much they end up engaging in other SIGs. If it was easy to do, I would put it between, I would just straddle SIG network and SIG app delivery for the working group. I mean, as far as it goes, there's, and it's in the documentation for the pull request, which I'll drop. But the test suite is definitely, and you know we've been talking with you for a while, but the test suite is going to cover all those different things that you were talking about that SIG network is already doing. The SIG app delivery is a baseline in a lot of ways when it talks about packaging and defining best practices for deployment. Those are going to be a starting place for a lot of the best practices for telcos. And then you're going to go, what do we need differently from what SIG app delivery that may not be, that may be more specific. So, yeah, I don't know. I can't say which one. It seems like it's going across both for the working group. And I'll say the program and the working group, but I don't think that helps with Liz. You're talking about administrative issues. If we're across both groups, I don't think that helps unless both of them. Exactly. I think it's just kind of, there are several SIGs pick one. I don't know if the working group have a preference or if someone from, I mean, Liz sort of stepped forward pretty quickly there, but maybe there's someone from SIG app delivery who wants to make a case. Why don't we Table it now? Let's table it for now. As I said, I don't think it's the biggest, you know, just administrative really. The initiative is the more interesting part of this. But I do feel that we have 21 minutes and we should give the SIGs a chance to tell us what amazing things they've been up with. Thank you very much, Taylor and Bill for the presentation. People that would you recommend for getting involved specifically from the CNCF and Kubernetes to talk about networking for applications, please send them to Bill and I so that we can get them directly engaged. Thank you so much, Liz. Yeah, thank you. SIG app delivery. Right. Yeah. So just a very quick update. There are a few things that we do have some very nice progress. And the first is regarding to the operator working groups under CNCF SIG app delivery. So the working group are basically continue working on the definition of white paper for operators. It's basically the white paper for people to understand better about what is Kubernetes operators, what's the difference with operators with several other projects. So this white paper is kind of blocked several weeks ago, but we have already make new progress there and we are very close to finish that white paper. And we also get a lot of valuable feedback from the community how to defy the operator's definition better for the community. So we can check the documentation there for more details. There are a lot of discussions or even debates regarding to the details. But I think the right now the direction is very clear and we are very promising to have a nice white paper out there. And the second update from this thing is regarding to the application delivery demo project. And we also have very good progress and engagement from the community there. And if you check the GitHub repo over there and the application demo, the same application has already been transferred under the CNCF organization. And we do have a lot of contributors from different projects to contribute demos and the user cases for different projects and tools. And we're also leveraging these contributions from the community as a main part for the CNCF delivery. It's basically a talk about how we can use the same application to demo different kind of tools and projects in the ecosystem. For example, you can use CNAP to package this application and then you can use Flux and Argo CD to do GitOps. And then you can use Flagger to do the rollout. You can use Argo rollout to do the rollout. So it's basically like using the same application for wires of demos of the ecosystem. So people will get better understanding about what different project can be used, especially in a developer facing workflow. So this is the main purpose of this sample application Advil. So if you have any ideas or any integrations you want to see in this application sample, please feel free to contribute your ideas. Just a demo and a sample will help a lot to the community. So this is what we all have today. Very nice. Contributor strategy. Hey there. So just briefly, for governance, etc., we're going to be running a project paperwork, micro workshop at KubeCon. The idea is to help some of the CNCF projects with their graduation requirements or projects that want to be in the CNCF with their sandbox requirements. Please, if you know of projects that are facing a graduation threshold, please direct them to that session. One of the things that came out of this was that we actually generated a project paperwork checklist because we realized that there actually was not one place that listed all of the requirements for all the different graduation levels. We have our graduation official graduation doc, but it leaves some things out and I've actually opened some at least one issue about that. So and it's really helpful for community managers, project managers, companies to actually have some place they can look at that has all of the requirements listed. At some point, I would like that to become an official CNCF document so that projects do have that as a helpful thing. And we'll talk about our process to do so. The, I think Carolyn is here, so I'll go over. Let's see. Carolyn, are you here? Nope. Okay. So for contributor growth, the contributor growth team is working with Linkerd who came to contributor strategy looking to grow their contributor community. They've also gotten the template contributing file, the contributing file template up, which is one of the requirements. And they're now working on a template contributor ladder. And again, this is all in the templates project for projects to copy who are looking to get their paperwork together. Right. I'm thinking for that, you know, particularly around the paperwork side of things, we should make sure that Amy is in sync on this because, you know, she's she's been, I think, doing the actual sort of checking up on what paperwork projects are doing. And it would be great. Can we get that sent around the TSE mailing list? I'll link to that. Sure. One of the other things I need to actually come up with based on the issue that I filed is a proposal for keeping the various places that the requirements are expressed in sync. Because we don't currently have a sort of concrete process by which say the sandbox entry form gets updated and the printed requirements get updated at the same time. So that's still a to do for our team. Great. Yeah, that I completely agree. The documentation certainly has some inconsistencies and it's great to tidy it up. Yeah. So appreciate appreciate the work on that. That's good. Any questions? Right. Lee. Right. Well, a few updates since last we spoke. So there's within a within sync network, there is a couple of projects that are under review or one in particular that's under review ambassador. So it's proposed for incubation. I don't know. I suspect that Matt, I don't know if you're if there's if you're ready for comment here, but that team is curious about the probability that that due diligence might come back before cube con because because of it's a venue to talk about those things. Is that a question for Matt Klein? Yeah. And so yeah. Mr. Klein, if you're there, but otherwise they were they were asking for an update recently. And so so speaking of cube con, there's hey, sorry, I'm here. Yeah. So from from my perspective, the DD looks good. So I'm not exactly sure what the what the next process is there. I think if we think the DD is is finished, do we have a public period for comment? Right. Yeah. I would I would recommend a public comment period and period of time for the rest of the TOC to weigh in. Great. Sounds like we could kick that off. Yeah. Nice. Nice. All right. Very good. So we have a couple of upcoming presentations of the projects that are listed here. There was an last time that we met, we talked about a few different topics. One of those was some points of interest of talks that were given at Envoy con. And so one of them being around VPP is a technology and and it relating to Envoy. And so we've invited that same speaker to come rehash a bit and kind of engage in some conversation. Under the service mesh working group, there are a few initiatives. Last time that we gave an update to the TOC, we talked about the 60 service mesh patterns that are being socialized and have a request for comment out. So there's a spreadsheet that's linked there. The service mesh interface conformance initiative, or SMI conformance is SMI as rather the SMI project is asking for to meet with regularity as kind of a separate work stream on advancing SMI conformance, which is great because there are seven service meshes that claim conformance with that spec. And we can't wait to see those validated much in the same way that CNF conformance was kind of spoke of Sonaboy, sort of a similar thing for SMI conformance. There's SMI office hours at KubeCon being held by some of the maintainers. They'll talk about SMI conformance there. There has been a couple of meetings on that go that that touch on the subject that will not touch on but discuss service mesh performance as an up and coming proposed specification and up and coming proposed sandbox project. Part of those discussions have been engagements with a couple of researchers focused on distributed performance analysis. So understanding the behavior really from a performance perspective from a network centric perspective, the behavior of distributed systems, so microservices, and how different types of microservices and how chatty they are doing analysis on those. So yeah, I think all of those are works in progress. The patterns is probably the kind of a public call for call for comment. That's that's about it, I think. All right, thank you. Any questions? Who do we have from observability today? It's a me. Hi. So just current status of ongoing work. There are some discussions around semantics for metric labeling. For other reasons, of course, we have open telemetry who is defining a lot of things. So just to make sure that there is interoperability between open metrics and primitives and open telemetry on the other hand, and all of them at the, that's the same thing, or there's one holistic thing. We had the first project introduction, which is basically a thing which we introduced where their projects within the observability space come to the SIG, talk about what they do, who they are, who the key players are, what their goals are, to seed the SIG with what's happening within the wider ecosystem. We have two working groups, at least in an internal incubation state, where we basically want to take discussions and package them into subgroups to then report back to the main call. Reason being that we can't fit all of the stuff which we have into the calls anymore. And most people seem to prefer talking about it instead of writing an email list and such. So we needed to create some new spaces where people can just have those discussions outside of the main call, of course, else we would never finish. There is a plan for the litmus project to the next introduction. And there is open metrics, which we would like to suggest for incubation. I already talked with Chris A. about this, who thinks it's a good thing. Also, obviously, open metrics is fifth in the end user survey. We are once again offering to do due diligence, but obviously I'm biased, because I'm both SIG chair and open metrics founder. Just to note that I have this plan. And that's it. I'm going to sound very ignorant here, but I feel a bit unclear about what's open metrics and what's open telemetry and maybe what's open tracing. Yeah, well, there's lots and lots and lots of opens. So the super short history open metrics comes out of Prometheus that was started 2015 as a thing to standardize the metrics exposition format of Prometheus as a truly vendor-neutral or project-neutral wire format. Then you have open census and open tracing. Open tracing having a focus on API definitions and on how to deal with tracing on language level. Whereas open census had the focus on being a standard library for integrations, to start exposing metrics and traces and logs and such. And open tracing and open census merged into open telemetry. And yes, there's a ton of opens. It's quite convoluted. There's more opens even, but these are the relevant ones for now. This opens in observability today. I just had to explain this for some of the executives at work in great detail. And you have to throw in cloud events as well. So open metrics, open telemetry, cloud events, and you get the trifecta. Oh, Chris is saying that open metrics is aiming to be an international standard. Is that through the IDF or something? There's multiple pathways through that, but maybe Richie could speak a little bit more. Yeah, so the working doc for open metrics is in the form of an ID, an internet draft, which will be submitted to the OpsWG within IDF. And then hopefully it will become an RFC. I already talked to the chair of the OpsWG, and they're basically waiting to take this and get it through the system. Nice. All right. I think we'll need to hear a bit more about that. Maybe at least understand. I'll need to at least understand what these different open projects are, but it sounds good. Sounds very good. Any other questions on that? Or should we move on to which is the next SIG? Runtime. I guess we have three to get through in five minutes. We don't have a lot of time, so yeah. This is Ricardo and SIG runtime. So quickly some updates, mostly around presentations and community outreach. We reached out to some projects and also we have some presentations. So on the containers and runtimes, our next meeting is on Thursday. So we have the crosslet team present. That's basically WebAssembly running as the kubelet. So you can run WebAssembly workloads with Kubernetes. So it's a project, early project in the works, but exciting technology. So we're excited about the presentation. Tryout is another project that we reached out to and that's basically a container image registry. We have a few of those, but this one is written in Rust. So we're eager to see what the differences are there. Lucid is another WebAssembly runtime started by Fastly and we reached out to them. So hopefully we get a presentation from them. Then on the H IoT, AIOps space, we have a presentation from Kubeflow schedule on December 3rd, obviously after KubeCon. So we're not going to have a meeting during KubeCon. Fogflow is a project that allows you to run workloads at the edge, similar to KubeEdge, but it doesn't run on Kubernetes. It runs in containers, but they're looking to add support for Kubernetes. So they presented at our last meeting. So they're part of another foundation called FIWARE, but we thought it might be interesting for them to present. K3S and a project in sandbox already for running Kubernetes at the edge. So hopefully we're going to have a presentation from them too. And open your edge computing workloads and also a sandbox project in the CNCF already. And we want to have a presentation just for informational purposes and for community outreach. And then finally, so we have some presentations at KubeCon. So we have a runtime intro session. So hopefully we'll get more contributors and people excited about the sick and getting more traction. And then also the container orchestrated work group is going to have a panel at KubeCon. So yeah, that's it for the update. I think, sorry, it took four minutes. All right, for those of us who can, let's run over quickly. And he's here from Six Security, Emily, I think. Yes, it's Emily. Hello, everyone. This is my first time. So I'm going to go really quick. I'm going to go backwards. So Cloud Native Security Day North America is a virtual event on November 17th. We have over 800 folks that are signed up for it. And we will be running a capture of the flag activity at the same time throughout the day. At the end of the day wrap up, we'll be talking about the activity. And there's a dedicated channel during the event just for the CTS. We'll also be promoting it on a Twitch livestream tomorrow at 3.30 Eastern time. So if you're interested, tune in. Switching back to the Cloud Native Security White Paper. We've had a ton of positive comments and feedback from the community. Everybody says how much they loved it and how much they needed it. So our next steps are seeking editorial help from the CNCS staff if that's available, getting final sign off from our lovely Six Security talk liaisons, and then hopefully being able to coordinate with the CNCS for a blog post about those updates. That's it. Amazing. I'm sure Amy and Chris can help you with those requests. Storage. Hello. Hello. I'll be super quick. So for the Profica project, we've been working on the meeting with Justin from the TSE. So thanks, Justin, for all the effort in there. As we've been going through the DD, we've come across a couple of items which mean that the project is now looking to be submitted as a sandbox, rather than pushing forward with the DD. And this is mostly around being able to prove production users of the open source version of the project. The Open EBS project, we are going through a review process with them for their move from sandbox to incubation. We had another chat with the team today to discuss some of the licensing concerns. And we're going to wait for them to come back to us with some options. Longhorn presented, and they are looking to move. They have a proposal in place to move from sandbox to incubation. They presented to the SIG. We're just giving the review. At face value, we don't think there's any issues to stop a recommendation. So that's probably going to be going forward to the TOC to ask for somebody to come forward for doing the DD. The project presentations of note, we have reviewed with the data lifecycle framework who have updated their presentation and updated some of the documents to address some of the issues that the TOC had when they lost, voted on sandbox, and they are resubmitting their project for consideration at the next vote. And we've stalled for a couple of weeks on the performance of benchmarking my paper, but we're going to put in the last bit of effort to get it out before KubeCon. And then finally, we've recorded our session for KubeCon, and hopefully again gain some more traction on the community. And one final small thing, the CNCF storage landscape white paper has been renamed to be more simple, and we're calling it the CNCF storage white paper, so as not to have it confused with the actual CNCF landscape, which is obviously a very different beast. And that's it for SIG storage. Amazing. I think that's all the SIGs. We have overrun, so please redirect your questions to the mailing list. Thank you, everyone, for your time. Thank you. Bye, folks. Bye.