 So, we'll get started right now. It looks like we have a full TSE Jeff, Jeff Brewer here. Yeah, he's here. Cool. Nine out of nine. Perfect. Yes, I'm here. Awesome. Cool. We'll get started. We have a fairly, you know, somewhat packed agenda today. We're going to be welcoming some new TSE members, and we're going to be welcoming some new TSE members. We have a full TSE roster. We'll discuss kind of the project presentation meetings that happened last week and how that went. Talk a little bit about CNCF SIGs. We have a annual review presentation from the Spiffy. Community since it's about a year since they entered the sandbox. And then we'll kind of open it up for any community discussions, backlog, et cetera, et cetera. Let's get going. Next slide, Taylor. So just a little heads up on some new projects that have entered the sandbox, both brigade and Cubedge came in. So great to see those come in. I kicked off the vote for Creo to enter incubation this morning, and we're still waiting on a little bit more due diligence on OPA before moving to an incubation vote. So I think we're waiting on Mr. Brendan Burns to put in his due diligence there, and anyone in the community is welcome to provide input there if they have had success using OPA or have any critical feedback. Yeah, I'll be ready with that next week. Okay. The next meeting. Okay, sounds good, Brendan. Who else was talking at the same time? This Joe, is it Creo or Cryo? That's a good question. I would like to clear this up. As far as. Cryo. Cryo is the preferred nomenclature. All right. Good to know. Cryo. Okay. That's going to take me a while. All right. Yeah. And then thanks, Brendan. And you know, anyone in the community is kind of welcome to comment on OPA too. So as, as the due diligence is going on, especially if you're using it in production or have any critical feedback. Cool. Next slide. Most important news. So we have two new TOC members that have joined us today. So. Liz Rice has come on board and has taken. Kelsey's slot after he stepped down. Due to commitments. And then Michelle Noralee has taken the TOC selected. Slot. So I'm super excited to welcome them both. And I've been really thank both Kelsey and Quinton for all the kind of amazing work they've done. And I've added them to the emeritus thing. So with Liz and Michelle on the call, you're welcome to say hi or say anything in terms of your thoughts of being on the TOC. Thanks, Chris. Yeah. Hi, I am. This is Liz. I am super excited to be part of this. I, because I've inherited Kelsey's chair, I have somewhat less than a year. And I'm quite keen to make sure that, you know, things have happened in that slightly less than a year. So yeah, I hope that with the rest of the amazingly smart people on this team, we can make some things happen as far as the TOC is concerned. I'm also really excited to be here. So yeah, thank you everyone for the opportunity. I've been hanging out around doing CNCF stuff for a few years now. And so I just feel really grateful to be a part of this particular group of people. And I think I'm most looking forward to the CNCF SIGs and that being formed, I think that's going to provide a great menu for a lot of really interesting conversations around cloud native SAC. So just really pumped. Thanks. Awesome. Glad to have you both. Just in order of kind of governance related things. We are seeking nominations for the TOC chair, which will close at the end of this week. And then we'll do the formal election. I believe Liz and Mr. Joe Beta has volunteered. So if there's any other TOC members that are interested in that slot, I'm going to make a comment on the issue posted below. Cool. Next slide. Just reminders on our wonderful cube cons coming up. So Barcelona is the one that's kind of the immediate on attention that everyone should look at. We publish the schedule, which is great. Thanks for your patience on there. I know it was a little bit delayed, but it's packed. Some sponsorships are available towards the end of this week and now in terms of attendance, we're tracking for probably somewhere around a little over 10,000 folks attending, which is a little bit wild. We had about 3000 or so signed up before the schedule was even live. So after that, we have China and North America coming up. So if you're very interested, feel free to reach out and we're happy to have a conversation around any of these bets. Next slide. We have a kind of shameless final call for summer code. If you're interested in mentoring projects, we have an amazing kind of set of ideas already there. But if you're interested, feel free to reach out to me or me or anyone. That's part of the GSOC admin list. Slide. So yeah, project presentations. So we've recently moved to this model where every second Tuesday of the month, we're kind of going through the backlog last week. We had a three project presentations, which kind of worked pretty well. I don't know how people feel about it, but I think it kind of went pretty well. We're going to continue to do this. If there are particular projects that the TOC wants to see slotted for the next one around next month. Let me know since you essentially get the control. Well, the schedule for that one, but any other feedback from the TOC or community on, this particular method of going through the backlog. Yeah, Chris, I was just wondering, I think we originally planned to do this every other week. So all the in-between weeks between the TOC meetings, my thinking is that we've got a ton of existing projects up for annual review. And then we've got an additional backlog of, you know, projects wanting to come in. So I think we probably need two of these a month, not one. I don't know what the general consensus is. I don't want to overload everyone with presentations either. I think we're going to end up with this never ending backlog again. If you don't get rid of some of them. I actually had a similar question, which was, is there a, or what, what is the annual review schedule? Is that part of that backlog? Is there a separate list of? Yeah. You could build that basically from, if you go to the GitHub repo for the CNCF TOC. And if you look through basically all the sandbox projects and their entry date, you could kind of see when they're, when they're due. I don't, I don't think we're too crazy for the next few months. Maybe it may be a couple, but I'll see if I could kind of go build out that, that list. And a personal thing is I don't think we need another meeting a month right now. At least I'm not feeling like we do, but I'm happy to oblige of, I have people on one. Yeah. I guess the question is if we do three a month, you know, how long does the backlog last in months? And my guess is it's many, many months. And I guess that's too much. Do we need presentations? No, not for everyone. So it's, it's basically you kind of request what you want for graduated projects. Yes. There's a hard requirement. Yeah. My feeling is that if we, if we do a bunch of presentations where we're just never going to get to any of the other work that we would like to do. So I think my personal preference would be to try to do the, the project stuff, probably async, like, is it possible that we could look through GitHub PRs and different docs and then if people feel that we, that we need a presentation and we could do one. Yeah. It works. If you link off that project board, we should kind of see what's, what's due. I mean, we have to fill up next month's meeting anyway. So. So is that saying essentially before we do a presentation with kind of have a, free presentation, I mean, essentially a step where we say, do we want to spend time on the presentation? Yeah. I mean, that's, that's, that's my feeling is that I think if, if people would have presented previously, we could just ask them to send us collateral, whether that be slides or a doc or a, or a GitHub PR. And then I think maybe there could be some, some reasonable review period where we look at everything. And then, you know, we can just do a, you know, a little bit of a review period. So that seems like we want a presentation. We could ask for one. I'll just try. I get what Quentin is saying. I just think that maybe for the time being, we should continue with one meeting a month since, I mean, for me, I'm still getting on board. And I know there are several other new members on the TOC. So I would love to revisit this idea. Now I agree with you there, Michelle. I think changing the process before we've got used to the current process. Yeah. Unless we think that there have been presentations that perhaps we shouldn't have had. Yes. Sorry. I, I wasn't necessarily suggesting that we cancel the presentation meeting. I was mostly responding to having a second presentation meeting. So I'm just trying to avoid us spending a ton of time in presentation meetings. Yeah. I actually, I was just going to second maps idea because I think when we faced a similar situation in the steering committee with charter, this sort of dividing conqueror approach worked pretty effectively for burning down the backlog of big charters. And, you know, yes, we won't get a presentation from every project, but that's, it's probably better that we don't have that. And we cover the backlog that we wait for nine months to cover the backlog. The other thing too is that I mean, my feeling is that hopefully once the six startup, I mean, shouldn't we be pushing, you know, the first tier of reviews to, to them, right? So I think that would also help. Absolutely. Yes. If I could chime in, I think it's really important though that we're communicating to these projects. Just because I've had a couple of projects that have been in the queue. Close to nine months and they're reaching out weekly every two weeks, wondering what is going on. And I don't think that's a good spot to put a lot of these projects in and this weird, what are we waiting for? We're on the backlog. Are we ever going to get scheduled? You know, I think it's only fair that if we don't feel like some of these projects are going to be reviewed, that we're prompt about letting those people know we're asking them, you know, for more information upfront and trying to get them on a schedule so they understand where they stand. Cause that's just been my feedback I've gotten from a couple of different projects is they feel like they're kind of just hanging out waiting and they don't know what's going on. So maybe we could improve our communication out to those people. Yeah. Just one last very brief comment. Cause I was the one who put the proposal forward to, to have these meetings. The intention is not that they'd be mandatory for all TOC members or anything like that. That they're just a forum where if people want to find out about a project that is wanting to get into the CNCF, there is a place they happen. If the TOC member or anyone else in the community is interested, they attend that meeting and if not, they don't. And obviously if there's a TOC member who would really like to find out and interact with the team, they, they can just, you know, request that that, that presentation be postponed until some date when, when they're able to attend. So, so yeah, don't think of this as extra workload. It's, it's additional optional information available to everyone and they're all recorded. So you can watch them afterwards as well. Can you point me to the recordings for these? Yeah, I'm trying to find it right now and it's not obvious. It should be on the CNCF YouTube channel, but all. Okay. Okay, cool. I'll send you some stuff offline. Cool. Okey-dokey. Let's move on on this topic. CNCF six, just a reminder that the vote is out. Really looking forward to kind of getting this improved and just a reminder that we'll be bootstrapping this process with kind of the governance security focus who's kind of been a great kind of beta slash pilot kind of customer for this. So vote is out to check out the CNCF TOC mailing list for it. So keep going. Going. All right. Now we have the annual review for one of our sandbox projects. Spiffy slash buyer community. So I'll hand it off to either Sunil or Andrew who will be giving the presentation. Oh, hello. Hey, everybody. Can you hear me? Yeah. We hear you now. Oh, Jesus. Star six. Hey, everybody. I'm the car. I'm driving like that. I'm happy to talk to. Talk to the slides and give you guys all a quick update on, on the Spiffy inspire project. I'm going to talk to you guys. I'm going to talk to you guys. I'm going to talk to you guys. I'm going to talk to you guys. I'm going to talk to you guys. All right. So we'll go ahead and give you guys a quick update on the Spiffy inspire project. I can't see the slide. So I can go by slide number because I remember the slide numbers. I swing by on slide 16, which is the overuse side. And I'll start from there. So as a reminder for those of you who are new to the CNTF. We're having the same thing. Attention to the world of authentication and security and Scantip. and staff that are designed to effectively provide and promote a way to securely identify software services in increasingly dynamic and heterogeneous environments. Spiffy, just to level that across the board, is really a set of specifications, right? And it's encapsulated within three elements. First is something that allows you to find, you know, how a service mutual identity identify yourself, you call that as a GID. Second is a way to encode those GIDs into some sort of graphically verifiable document. We have two forms of that. First, we started with X509. We also have the chase on the token format as well. And third, but not least, is ETI specification that allows for applications that in perspective to get these experts as part of their runtime. I mean, that's the role of the whole. Spire is the, one of the implementations of Siffy basically allows us to take those three standards and let you actually do something with those in an environment without having to do too much, too much heavy lifting per se. Some of the use cases that come up around Spire primarily been around the areas of secure authentication amongst services. Another one that's shown up over the last years. I think we lost Sunil unless I'm going a little crazy. Yeah, I think we lost him. It shows a no phone. Oh, there we go. I'm here guys. Sorry about that. I don't know if I should. No worries. Oh, it looks like it cut out again. Maybe come back to Sunil when he's got a better connection. Yeah, that's completely a reasonable option. Everybody, can you hear me again? Yeah, you're back. All right, well, I dial back in. Hopefully this will be stable. I'll make this quick so we can move on to somebody's stable location here. Yeah, so let me go to slide 17, which is the timeline slide. So if you remember from the time that we brought this project in, I mean, the history of Siffy Inspire, it can be rooted back to almost 2002 going back to some of the work that was happening inside of Plan 9, which was in Bell Labs. A lot of the learnings that I think the community has, thanks to work by Joe Beta and others, stems from the initial implementation we learned about at Google back in 2005 towards loss infrastructure. And since then, we've made some really great progress, not only getting Siffy Inspire deployed and launched at CoopCon North America 2017, but then having this project welcomed in since then in April of 2018 as well, which was last year. And I think that's the conference where Andrew and others were able to spit in the keynote and talk a little bit more about the project as a whole. If you go to the next slide, you'll see that since that time, we've had a truly interesting uptake in terms of our Oldwell community. We've got 432 participants in the Slack channel. Not all of them are actively participating day in and day out, but we are seeing the slow and steady up and to the right, both in terms of active participants as well as active messaging across the board. Our community, our conversation happens in Slack. We have a variety of mailing lists that we use to accode documents or to communicate thanks to people at, just because that's the way we do things, but most of the day is happening inside of Slack. And we're pretty excited and particularly by the most recent uptake in activity. So if you go to slide 19, you'll see that across the board, and this is just a representation of some of the companies that have really been jumping in here, including Square, VMware, Uber in particular, Tullio, Pinterest and a few others, who've all showed up and have been spending time with the project trying to understand how can they actually align their use cases with what these building blocks allow for them to do inside their organization as a whole. Some organizations like Pinterest are very much of the mindset to be able to sterilize around SPFY and the SPFY identity format itself. They already have the machinery and the equipment to be able to do secure authentication based on the technology that they've already been working on for the last number of years. Other organizations like Square and Uber are looking at being able to replace the existing forms of service and system authentication across the infrastructure a whole lot. And so what that's translating into is just a myriad of capabilities that are finding its way into both the standards and SPFY as well as within the open source code base itself that inspires a whole. The numbers of these projects in terms of stars and commits and contributors, these are nice, these are interesting, we're working very hard as a community to continue to drive that. We've become fairly disciplined, we've always been fairly disciplined in terms of how we engage our community. We have regular community days, one supporter now, we bring the community in together, the next one's happening in May. And so being able to use that as a way to continue to promote not only SPFY and SPIRE but to promote the adjacent ecosystem of technologies, whether it's in policy or anything else in between TOF and notary and things of that sort. And so we've been pretty excited by kind of a pull from other communities caught into learning more about SPFY and SPIRE as a whole. If you go to the next slide, slide number 20, you'll see here some of the features that we've been working on as a community. So on the left side, what we consider to be some of the core building blocks of SPIRE from the code base. As I mentioned before, John as a transport mechanism is something that came about very early on. A lot of folks said that we needed a mechanism, aside from X509, that allowed for these specific attendees to find their way through some sort of a middleware device where there was an HIK way or a load balancer or something on those lines. So we very quickly heard that to move forward and build out a SPAC as well as implementation support within SPIRE's infrastructure as a whole. Workboard API work continues to develop. We're working with a number of participants on that. One of the ones to highlight on the call is Google. So we've been spending time re-engaging with Google and the Istio team around trying to identify ways in which we can kind of align our thinking, our resources, and our story around the value of multi-factor authentication for services, which is how we define SPIRE. And then being able to talk about the value that brings not only to folks that are in an on-mesh world talking to Kubernetes, folks that are talking to off-fashion infrastructure as well, which is a large chunk of the Fortune 2000 as a whole. So we're pretty excited about some of the work that we've seen as well as some of the foundational engagement from our partners like Google, from ThoughtWorks, who has a consultancy who's bringing a lot of companies into this hold and teaching them about what the value of SPIRE is. And there's a lot more down the path as well that we worked on too. On the left, on the right-hand side, you'll find basically a listing, a snapshot from our website about the number of plugins. So as you'll remember, one of the key features of SPIRE is the fact that we've built a fairly accessible, fairly easy to consume plugin framework that allows for people using SPIRE to write their own plugins. So if you want to be able to do node access patient, if you want to be able to use your own upstream CAs, if you want to use your own key management systems, or if you want to use your own back-end data store, we have a plugin framework that has been fairly well exercised by a number of folks, and we expect to see more of these coming forward over the coming year. If you go to the next slide, it'll take you to some of the integrations we've had. So customers and folks that are using this I think are looking at us and the community of open source technologies as well as commercial vendors to showcase how these technologies can be used together. And so over that time, we've had a number of great opportunities to engage in folks across both the issuing side, such as those that issue specific identities, as well as those that consume specific identities. And I'm not going to read this slide to you, but you can get a sense of who those stakeholders are and the kind of work that we've been doing along the board there. I expect to see more happening on the world of CAs in particular. I expect to see more happening in the world of more traditional identity and access management systems as well. We've had a number of folks in the community asking us about our ability to plug into technologies like Venify and CyberArt and Okta and others along those lines that I think are already embedded within the large enterprises as a whole. So we expect to see more work coming with those communities over the coming year as a whole. If you go to the next slide, this is the last slide, we're just really kind of focusing on our roadmap over the next year. You can read this slide for yourself and I won't share the details there, but this is going to be a very great year for us. Let's start starting with Kupkan Barcelona, which is happening in just a few months. We have, I believe, five presentations from side channels and from other community members including Uber and others talking about the work that we're going to be doing around SPIRE. Some of that work is going to be highlighted around things like high availability. We've already got HAA built in the terms of being able to run multiple SPIRE servers to have bill over, but we're looking at beyond that. We're looking at load testing. We're looking at kind of integrations with systems like this too as well. We're also looking at trying to make SPIRE just a hand of a lot more turnkey with Kubernetes. We had quite a bit of feedback in Q4 last year about the fact that our documentation, our examples, our libraries were really not well built for somebody who was starting with Kubernetes and wants to get started with CP Inspire. We took that as a challenge and over the last two and a half months, but turned through and really done a 180 in terms of our footprint and telling the story of how to help people use Kubernetes Inspire as whole. I expect more work to happen there over the coming months. I expect more work to stop it around making this stuff accessible to people. The early adopters really have a burning pain or they have a really good understanding of PKI at scale. Most folks don't and most folks shouldn't really have to. I think what we're really hoping to do is work with the community to build more examples, to build more case studies, to build more webinars, and to continue to drive and showcase why this support not only for their infrastructure, but as they move towards a cloud native world. With that, I'll put myself on pause and happen to take any questions anybody might have. So hey, Sunil, this is Brian. Inspire 1.0 production ready. Is that when you expect to have users starting to use Spire in production or do you have some already? So right now, Brian, I hope you can hear me right now. The production users that we have closest to this, yes, we expect two people, two organizations by, actually three organizations by Q3 this year, to be moving into production. I won't share those names quite yet because I don't want to set those expectations for them when we don't have the clearance to share those names yet, but two of them already are in staging, they're in the middle of roll-on, they're kind of a production into their infrastructure and they're in the middle of driving some requirements around load testing and some of the additional security, obviously they're going to be doing against the load based as a whole. We have a third that's going to be spinning up their exploration in their staging environments in Q3 and we think there's probably another two or three more beyond that as well. I think by the end of this year, when we get to coupon North America, whenever that might be, is when I expect for us to be able to talk about having at least three, four, or five production services, production companies, or sorry production implementations of Spire being deployed out there, but we're not at that point yet. So I'm not here to tell you guys that we're all ready to go and that Spire and Spiffy are ready to make their move forward, we're not. When we're still building our community, it is nice to see the progression, it is nice to see the engagement. We still have a lot more work to do to get this into the hands of more production environments as a whole. Are there any other, one thing that is being discussed is what projects need, are there any other services that CNCF could provide to you that would help your project? I think the only service that comes about, and this might be a broader conversation with other projects that are not necessarily backed by a larger enterprise, a larger enterprise splitting, is there's always more around how do you make this content accessible to audiences, right? And so part of it for us is getting the opportunities to work with great technical writers, getting to work with great content producers, whether it's video or audio, and just trying to promote more of the story through better storytelling as a whole. Storytelling is hard and it's expensive for the best ones out there. And so opportunities where we're able to tap into the CNCF collectively. I know there's a service that has a lot of great features which we have been taking advantage of, but particularly around the storytelling natures, around comms and marketing, the project in a material way would be helpful. Now I understand that we're a sandbox project and there's a sandbox project. I don't think sandbox projects are pervy and have access to those types of services that they're available at this point, but that would always be helpful. Enload that site file as one of the sponsors will continue to drive that initiative forward as best as it can. So the people you'd be trying to communicate with would be additional contributors or some early adopter users that you could get feedback from? I think some of the feedback that we're looking for is if we're trying to build interconnectedness between the CNCF project, at least as one set of organizations, then really being able to showcase and have engagement with more of the broader swath of Kubernetes users. Now we might have a bit of a mismatch, right? The Kubernetes user base might be different than those that are looking at Spitfire or Opa specifically, right? But I think being able to have different vantage points through which people can give us feedback on Spitfire and its accessibility. What does Spitfire mean to me as a Kubernetes user? What does it mean to me as a GRPC user? What does it mean to me as a top or notary user? I think being able to have perspective from different communities into the project is always helpful. But then again, we're one of multiple projects in here, and so I'm not going to say here that we have the time to be able to work with all of them, but Kubernetes as a community, as a first class community amongst the others in this ecosystem, I think it's one where we're looking to actively engage way, way more because I've been part of the work with John over the last quarter as a community, but also because we think there's a lot more to go beyond that as well. So that would be one area, Brian. I think that would be great to get some engagement. Have you connected with SigAuth subgroup in the Kubernetes projects at all? We have, yeah. So in 2018, we spent quite a bit of time working in concert with what was happening in SigAuth around trying to identify mechanisms around workload identity that was going to be needed to not only Kubernetes, but also useful to Istio and useful off of Kubernetes as a whole. I think that there's wiggle room and space for different ideas to exist in there as there should be, but it seems as though, much like with our project, we've had to focus much on really kind of driving where a lot of the interest had been, which for the most part of 2018, until we started hearing about this in the back half of 2018, had really been coming off of Kubernetes. And so that's where a lot of our effort and time was spent really optimizing around what Stiffy was and what Spire needed to be able to deliver 4%. That said, though, I think it's a great opportunity for us to reengage that group. I think there might be some learnings there and some learnings both ways. Even with Istio, for example, I think we went down to Google about a month ago or so, and we had a great conversation. I think both of us were heads down working on our projects, and we picked our heads up for an hour and a half, and we're like, gosh, you guys are doing this, and you guys are doing this, and there's just so much more overlap in terms of the world, and rather than create competing ideas, especially when we're trying to promote same concepts to the same users, I'd like for us to try to find more time and opportunities to engage and align, especially because we're part of the same community as a whole. So a lot more work for Sightail and others in our community to do to make that happen. Okay, thanks. First of all, I really enjoyed your presentation. I feel like you're saying all the right things and focusing on really awesome things like working on community building and making your docs more approachable and going in depth and having these conversations with potential end users and kind of seeing what features that they need, that all sounds great. I'm just really curious. I actually talked to some of the HashiCorp people about how and why they ended up using, I think it's just a spiffy, but I'm curious to know what kind of teams are you talking to or who do you end up talking to at other companies like Pinterest and Uber, like what teams, how does that conversation start? Do they reach out to y'all or do you kind of target a particular group of people? Yeah, sorry, this is Michelle. I can't see faces. I'm assuming this is Michelle. Hey, Michelle, it's nice to meet you. By the way, we never met before, but it's nice to meet you. The communities that we have engaging with us, the personas inside organizations that show up and I'm curious about something to inspire, let me give you one way of looking at segmentation. We have a lot of organizations that a lot of startups probably are not finding their way too spiffy per se. I think that for many folks, spiffy as a concept is particularly valuable and particularly useful when you are a hybrid cloud adopter of some form or fashion. If you're born in Amazon or if you're born in Google, if you're born in Azure, the tooling, the security constructs for the most part are good enough, I think for a lot of folks. We're not seeing that kind of engagement, just in terms of community transparency. We're not seeing that kind of engagement with those sorts of teams because this isn't a higher order bit for them to worry about. Where we do have engagement is in, let's call it two classes of large enterprise. One is I'll call Nuvo Enterprise. Organizations that are less than 15, 20 years old, something along those lines, don't have nearly the kind of technical debt and heterogeneity as you might find in a prototypical Fortune 100 that's been around for 30, 40 or 50 years, but recognize that as their infrastructure starts to age, as their infrastructure starts to expand beyond their existing footprints and as their personnel start to turn over, some of these foundational technologies like Pinterest or Square or other places like that that have been built by security engineering teams or in some cases, identity and access management engineering teams start to show their wear and tear a little bit. We oftentimes will find ourselves engaging with folks that are in those two types of organizations to actually explain to them how we look at Spiffy and Spire as a potential next step in your journey as you become a cognitive organization as a whole. Now you brought up HashiCorp which is in all of these organizations that we're talking to, it's a great company, it's a great piece of technology around ball specifically here, but I think one of the things that we hear from folks is this idea that we want to evolve beyond the model of utilizing some sort of a secret. You recognize that secrets are important and they are the way in which we do business today, but I think when people look at PKI they look at it as a black box and look at it as a dark art that is completely inaccessible and you know could never possibly utilize the thing at scale and I think when they look at Spiffy and Spire they think they realize that there is a lot here to offer, there's a lot in terms of being able to use Spiffy and Spire in conjunction with Valk today, to be able to deliver value for near-term use cases and long-term use cases that they move to the cloud. The other set of customers that we have are the Fortune 5000 core security engineering teams that have been building out their own Kerberos based authentication infrastructure and look at this as a successor to a lot of the work that they've been doing there as well. So in some ways it warms their heart that these constructs and ideas are not too dissimilar from things that they've worked on for almost 30 years going back to the Athena project at MIT going back to 1981 and so we're re-engaging with those folks as well. The last thing I'll say is that we also have a set of stakeholders in enterprise architecture. So the number of enterprise architects in lines of business across the prototypical Fortune 500 enterprises that show up and say we have a mandate to move x percent of our infrastructure into Microsoft Azure and some percentage of that is going to run on Kubernetes. How are we going to make that happen? They find their way down to the security layer of this project that they're into and they start to realize that they're going to be beholden to processes and methodologies around authentication that oftentimes require days if not weeks of workflow time to engage with the security team to get the right set of credentials before they can actually turn the button on and launch an instance of whatever they have building in the cloud. So oftentimes they will find about Stiffy and then they will bring us Sightail into their community and into the security team to teach their security organization about what's happening there. So we're getting pulled in by various stakeholders. Does that answer your question Michelle? Yeah it does. I definitely got a good sense of what kinds of people and teams are reaching out to you to talk about these kinds of things and why. So thank you. Are there any big challenges? Like this is a lot of stuff you're working on. How big is your team and do you have any big challenges? I know Brian already asked this question and you mentioned technical writing is an area that you'd like some help with but is there anything else that's concerning? Well I think it's probably I mean to answer your question Sightail as a company is three or five people. We're destroyed around the United States around the world. It could always be bigger like any company could be but I think we're we do really good work with the size that we have. We also have a really engaged community. There's a set of individuals that are probably on this call and beyond that are really really passionate about being able to breathe life into these kinds of constructs to be useful in Kubernetes off Kubernetes and worlds beyond that as well. I think one of the things that we always worry about and maybe this is just the nature of being an early stage project like this is is we always worry about missing out on perspective on missing out on use cases missing out and not seeing something the way somebody else sees that because they've been living it they've been breeding it for the last 20 years and they have something to share there and you know I worry that you know we don't we're not doing enough to make sure that there are forms or mechanisms to people to participate not only in the code but in the design right we're still in the design phase of some of these you know aspects of both the code base and the specifications as well so you know making sure that it's not just Sightail's perspective that's that's represented here trying to be intellectually honest about the fact that we're not necessarily the owners of a project with the stewards of a project and we have some perspective but there's a heck of a lot more that's out there so I did find ways of getting more feedback earlier on the design process I think is something that we're always always degrading to see but aside from that you know you know we've got roadmap items we've got work to get done we've got code to get built you know I don't think that there's much there that that you know is beyond the grasp um that we can't handle at this point awesome thank you so much I appreciate the perspective I won't take more time but I think this brings up really interesting points and threads we can talk more about great thanks Michelle any other questions for me okay well thank you for the time and I appreciate the opportunities to connect with you guys we'll we'll see you in Barcelona thanks Neil thank you all right moving on I think we're pretty much towards the end of the call today so unless anyone has any other discussion topics or things to bring up we could give people about 10 minutes 10 minutes back in their day all righty cool all right take care everyone thanks for showing up and it's great to have some new TSE members we'll do the TSE chair election next week take care bye