 I think it was sub-situations, someone else's problems. Yeah, exactly. Cool. So shall we get going? We're about 10 minutes into the call. I don't know, we may end up being a short call today. Yeah. I know for example, like the one thing I'm aware of is the desire to go and turn the technology tree into more of a roadmap. And I think that that is going to require a little bit of work coming up to the next meeting before it actually is useful to go over it. I think that's a good place to start them. OK. So yeah, definitely, that's going to require a little bit of work because I basically just have the same tree that I had last week, which is good and all. But the other one is that it's sort of rapidly becoming, the world is moving on. So things like, I got word yesterday from one of the folks who's working on interdomain that they sort of basically have it working now. And now they're cleaning things up and testing across different clouds and so forth before they go ahead and push their PR. I saw we also have a preliminary DNS implementation, too. We do, we do. It's really well done as far as it goes. But there are still some questions that the person is asking that need to be resolved before you get there. If I'm reading it correctly, the current implementation won't do the fan out quite correctly. But all the right pieces are in place, which means that once we get the fan out functionality there, I think it's in the right place. So there's also great progress coming down on security. Apparently, forward security is now working. Backward security is being looked at. Cool. When you say forward security, that's passing the spiffy SVIDs up the chain? It's doing the right thing for Providence for JWT tokens up the chain. JWT tokens, OK. Yeah, and then the trick is that coming back properly and then the ability to safely and properly do healing based upon the return to JWT tokens. OK, that makes sense. Well, do we have anything else that we want to discuss today? I don't think that we do at this point. I mean, the the important some of the important discussions we need to have around around the release, I think are going to require people like Nikolai to be to be present. Yeah, I agree. Let's see. So a couple of comments. Oh, listening, I pointed out that work surface special.io is live. Yeah, I'm still blown away by the quality of the website. So yeah, no, it really is. I mean, I find myself being tempted to go paying Luke on certain updates and say, hey, here's the update. Can I get your just case check on this? Because clearly, your taste is better than mine. So yeah, my my one concern is that the the what is network service mesh document has been promoted to the first page on docs. So we need to fix that up. Oh, OK, yeah, definitely do fix that up. So cool. Hey, welcome, Joshua. You sort of just wandered in and we've determined that we have a bunch of homework to do for the next meeting, but we don't have a bunch to cover this meeting. So what's the is the is the glossary pretty much done? Are we still just the work in progress? I think so. I mean, there has been stuff committed to the repository on the glossary. If they're a thing, but obviously everything is always subject to improvement. OK. Yeah, my my understanding is like we've where it we're no longer listing the glossary as a main item on the agenda. So I think it's pretty much done except for except for minor improvements, as Ed mentioned. So if you if you want to use that or you want to share it around, that that should be that should not be a problem. Is there is there a specific contribution you were looking to to make towards it? Or is there something that you think needs to be expressed in more detail? Yeah, there's stuff that I've been trying to work on for. He doubt along the lines of the OSI model and then the different components and glossary and CNF general. And I don't know, I just keep going around in circles when I'm thinking of the different pieces that we have named here. So like the local mechanisms, tunnel interface and MMIF and these types of things. And remote mechanisms and stuff. And it seems like to me, some language there that people are familiar with as far as like layer one, layer two, it seems like the local mechanisms are like layer one, they're like virtual layer one or something like that. And and then maybe the remote mechanisms are things that are layer two and above those types of things. I didn't see it might be useful to start using some language that other people are familiar with, I'm not so sure. But I don't see the like OSI model use maybe once or twice. Yeah, it's one of those things that sort of goes both ways. And it kind of depends on who the audience is. If you're talking to networking people, the OSI model is super useful. If you're talking to devs, they don't even know it. Yeah, well, so I'm I'm a dev. And to me, I'm serious. You're also a very, very curious stuff, right? Well, the thing that I have a hard time with when going into any domain is when people change the language. So I'll do a pass on something like this glossary. If I wasn't familiar with it and I'm looking at these this terminology. And then I go cross reference to a networking book. And I'm saying, OK, I'm not able to cross reference here. I see some words, but where's this this model? And then when you're in, you're in a dialogue of six or seven people, a group, and they're talking and they're networking people are talking about layer one, layer two, or three and all these things. And you're like, wait a minute. You know, is it that NSM kind of goes around these things or or what? And it seems to me that sometimes I was thinking maybe sometimes some things get lost when we start talking about software data planes and the difference between that and an ASIC and MMIF kernel interfaces. These are all things that maybe I'm wrong. But it seems these things are kind of like with Ed, which you would always say they are virtual represent. It's kind of sometimes when we think about it, sometimes it's a mistake. We think we made the physical into the virtual. And that was a problem if we force that abstraction too much. But it's all layer one. So there are better ways of, you know, some ways are better than others as far as implementing layer one. But then after that, you have layer two, which solves or brings up other issues, solves other problems, these types of things and they need to be addressed. And I think where my point is that there are certain problems that are addressed at every layer. And that's where I when I'm in different discussions, that's where things get lost with devs. Devs don't believe any there are any problems like so like the spanning tree protocol, like the layer two ethernet type problems. We don't know anything about that and we don't care about it. It must be it must be done, must be fixed. You don't care about that. We only care about layer three. Exactly. That's where I'm getting that. Well, and this is a matter of personal opinion for me. I think it is ludicrous how much we still care about layer two in this day and age. I know you can make you can make a really strong case that the two central sins of networking, the two things that have brought the most misery to the world. Well, I actually put three in there would be number one, the ridiculous ways that we weld IP to ethernet, right? And that we basically kept L2 along. I mean, which effectively comes down to shared media was the original sin and that led to all kinds of stupidity in L2 and therefore all kinds of stupidity of the interface between L2 and L3. So shared media is the first sin. The second sin was having IP addresses identify both the location be used as both identifiers and locators, which means now your identity at the IP layer is tied to location in a way that's really helpful and leads to all kinds of crazy. And then the third sin is tying TCP connections to IP addresses the way we currently do IP addresses and ports in such a way that they sort of mush together in an unfortunate way that makes the transport layer a little bit screwed up. And the good news is the, you know, Kubernetes is pure all three, which means it's done away with the shared media myth. You know, locator identifier separation still a little bit of a mess. And then, you know, when it comes to TCP and it's sins, quick is coming and quick has not made those mistakes. So lots of things are getting better. Yes. So makes all makes sense. So the one thing I would say, though, is whenever and you guys are better at this type of discussion, like whenever I'm in some of these conferences and I could have told us the Fred before, when there's when there's a discussion with you guys, it I can see people don't really ask you certain questions because they're just like, you know, and they're not. Maybe they don't want to look silly. But when I'm talking with people, one thing that maybe it just is silly. People don't believe they need a software data plane. They don't think that they need any data plane. They think that the IP tables, kernel features, all that does all of it. We don't care about that. Why do you need any of that? No, I most of the time, they're right. So I mean, the way I usually describe it, trying to explain this to network people, right? Because network people are like, oh, but, you know, they have to do blah, blah, blah because of performance and scale. And my response is to turn network people and say, look, that the cloud native people will decide what they want. They will find a tool that solves the problem in the most straightforward way. And they will call it good up until the point they hit the wall on scale and performance. So it is an argument to try and go in and say, hey, but bloody, bloody, bloody, blah, lots more complexity because scale and performance, that's a losing argument, generally speaking. And part of why it's losing argument is that quite honestly, if you're sitting on the other table with the cloud native people, at least half the time and probably closer to 80 percent of the time when someone tries to buffalo you with that argument, it's bullshit. You don't care, right? So where I see people actually starting to care is, you know, when they hit the wall on scale and performance, right? So on the IP table stuff, you know, you came in literally 18 months ago and there were lots of people already hitting the wall on that, where it simply did not scale. And so, you know, they came back and it's like, well, we'll do this IPVS. Well, which was a little bit better, but still doesn't really scale or perform when you actually get a scale up. So you've got a bunch of people who hit the wall there. And now people are saying, well, we'll do it with the IPVS. And it'll be interesting to see to what degree that actually scales and performs. It'll clearly be better than what we're doing right now with IPVS. But my guess is that once you get a critical mass of people hitting the wall there, they'll have people looking for solutions as well. And again, I think this is actually smart, which is you try and solve your performance as best measured, not imagined. But, you know, it is it does make the conversation different than what the network people are used to calling. Yeah, I think there's there's a few things going on as well. So first, I think people are more comfortable talking to you than they are talking to us. Like with us, they'll say, they obviously know what they're doing. There must be something right there. I don't I don't really see it, but I don't want to. But but I don't want to look stupid by asking a question. And so that's where our messaging becomes very important to to help with with with them to understand like that, not only like. It's not the question is not only like, do you like how do you do this stuff? But you would do even need it in the first place, like most developers, if they're saying, I don't think I need this. That's perfectly fine. And in fact, we would encourage them to not use it if they came up to us with some of the something that looked like a the opposite of a need. And so when it comes to another issue that I think that we're that we're going to to see is I think we start looking at the two different communities. So if if you talk to someone like I use Ian as an example, you talk to someone like Ian, who's very enmeshed in the telecommunications industry. He and he's looking for like that that SRLV support and like how do you maximize that overall performance? It's like you talk to you talk to the people who are looking for his type of services. There are there are going to be all about let's maximize speed. Let's get throughput, you know, while controlling complexity. Developers couldn't care less or they So what they end up doing is they end up that's part of the reason why we focus on the on the Sarah narrative is that, you know, when I talk with the developer and say, well, why do I need this? And I said, well, usually you don't. But what if you but let's say that you had a workflow where you were connecting a pod to a financial VPN and you didn't want to expose your entire cluster to it. You want to make sure that that specific workload was the only thing that was able to connect to it because of your business security policies. How would you do it? And then usually by then they say, oh, OK, I see I can see where I would use MSM for that. And so so it really it really depends on on the on the user where like they they know that there's some interesting amazing magic that goes on, but they really don't want to care about it. It's it's literally it is the embodiment of embodiment of the sex situation and hitchhikers guide to the galaxy. And and I don't think they're wrong about about that, because even if they knew about the problems that occurred in the tokenspace, what could they do about it? And so it's it's good for them to be able to focus on on their on their specific problems that they have in need and make sure that they build something that can make use of new new improvements going on on the infrastructure. Yeah, OK, so the app developers one and they don't care. Like they just aren't they what we're saying this fourth profile. We're talking about profiles. Maybe there's a fourth, fourth profile. It's like an infrastructure developer and a data center type person is setting up the networks and stuff in a larger data center. Let's say a government type data center or something where there's going to be you have to care about performance at some some at some level. Maybe it's not a telco, but you're you're hitting that. You have to be mindful. You just can't set up the infrastructure however you want. And they don't seem to be the biggest networking guys oftentimes, or they could be, you know, I don't know. Well, it's like if you want high performance, then you have to do things for high performance. That's always been true. So they could do just willy-nilly anything and we'll keep working, right? Network Service Mesh is carefully designed to keep working. But, you know, if they want all kinds of cool tricks that their physical network could do for them, they may have to do something to expose that via Network Service Mesh. So I had a fantastic conversation with a person who actually sets up data centers and and I found that all of my usual discussions that I typically have with people did not feel appropriate with with this individual. So when I was describing Network Service Mesh to them, one of the things that I that I realized was that the data center has a couple of problems that they're running into. So the first one is the they have no insight into the workloads that are running on top of them, which means that they cannot adjust for the type of workloads that they that they need. So if you just need standard networking, that's fine. If you want to bring in something that does something special, then they're they're very limited, like they can provide something special, but they're very limited in their capability to to do so or or or express it out. And when they do so, they they end up use they end up expressing out APIs that are that are potentially tightly couple them to that particular family of data centers and so on. So when we were talking about Network Service Mesh, it was like, you know, well, what what additional services or things could they provide access to and potentially bundle up as a surface? So if you wanted something that that provided, you know, even something is like it could be something at a high level, could be like a VPN or might be something at a lower level that does something special in their infrastructure to use some traffic management or to or to guarantee some type of quality, then being able to to request for those things with in a declarative way with labels and so on, is something that they could build towards that would give them a unified interface for requesting those type of those type of things. And so so he was quite excited with the concept of Network Service Mesh from the from the purposes of being able to expose out and refine the capabilities of the data centers fabric. I've had similar conversations as well. So but that's a very specific type of infrastructure person. I think your average infrastructure person that we're probably going to run into in the beginning is going to be enterprise infrastructure. So not the data center person, but the person who runs the clusters. And to be honest, I think the biggest use case we're going to have for them in the beginning, it's probably going to be Sarah's Sarah's use case, you know, literally hooking up VPNs from one organization to another. And I, you know, that turns out that's a crazy difficult problem even today. And it's not uncommon for that scenario to take several months, sometimes up to six months to to establish connectivity. Wow. So if you can go and say, hey, we can do this, you know, once you've signed the paperwork, so he doesn't fix the legal side entirely. But once once they've signed the paperwork and have agreed to share to share a connection, you know, the my hope is that they can they can set it up in five minutes. That's my that's my hope. You know, you share you share the key that share the secrets. And then you use load up network service mesh and say, connect me to this thing with these secrets. And then you have a you have a pod loaded that that's or VM loaded in your in your infrastructure that just that just does its thing. So no, it's a lot of it is about keeping the world simple. It turns out that there's only really one feature that people are looking for in layer one. And that's the things you shove in one and come out the other. But you go to layer two, the number of people want and what features they want. And the fact that the features conflict with each other gets to be really gnarly. Yeah, and the way that I that I try to think about it is so also, have you have you heard of the term link local? I have. So so what I try to think of is the NSM view wires, as we're calling them, is trying to keep link local, actually local between just in two connections. So that way, and and above that, you can have frowning and so on. But it literally tries to constrain as much as possible, the link local to a to a very small to a very small domain. Makes sense. That I want to work on enterprise developers now for most of them. I have a bunch of things that I was going to try to push into the doc that Jeffrey is doing. And I guess there's the other doc that is the more of the, I guess, on the vendor side. So I guess there's some things there you should probably, I don't know, in the end merge everything. But I'm trying to trying to, as far as on the CI CD side, trying to pull the best practices on over and try to look at some of the things that MSM brings to the table. One of the we have another doc called the out of band doc for the desk bed. And they're saying, OK, what all is installed here? That is what we're saying out of band will kind of installed in a way that is not maybe Kubernetes type native. So outside of right. So and then say this is one of the drivers for using the MSM in the test bed is because, OK, now we're installing things using helm and getting away from the imperative file scripts for installing and trying to get closer to the declarative and these types of things and trying to say, OK, this is proper CI CD, nicer installation scripts that can be used in or within the orchestration for Kubernetes. And then you guys are talking about self feeling and everything. Some of that stuff, it's all wound up together. So trying to pull that in and then the reasoning behind why something is even cloud native, you know, having things like what you would say, and loosely coupled and other things why you can't have everything all coupled together, most likely all in one big VM, three different concerns or however many and then call it cloud native. I think that that's maybe some of Jeffrey's concern. And I know that's some of our concerns. Yeah, I mean, the good news is there's a lot to be drawn from the cloud native definition itself, right? So you start, you know, the really top place to start is a mutable infrastructure. And I suspect that 100 percent of everything you're doing for out of band deployment violates that, right? Then this coupling, I'm not sure that 100 percent of everything you're doing for what you call out of band violates this coupling, but I guess a lot of it does. And then minimal toil. You guys can comment on how minimal the toil was in doing all that stuff, right? So like right there, I'd say, look, you know, you guys went in totally eyes open. You wanted to be able to get performance numbers. You made very, very well reasoned choices around the out of band stuff. But that can't be the way the world works in the in the limit of actual deployments. Yeah, yeah. The new moza, new mozone struggling to be pinning. That's all going to be like with the immutable infrastructure. That's going to be all probably out of band and trying to talk about how we're going to bring it in scope and make it native. It's going to be part of the discussion. So yeah, but yeah, all that stuff. I want to somehow circle it back into. Um, it seems like a piece that could be for NSM talking about how you bring things. If we use that language in band, out of band, we decide to keep their language bringing things more, making them more cloud native. I mean, I would actually, I mean, you may just want to make it clear, which is you have the non cloud native things that you're doing and the cloud native things that you're doing might make it a bit clearer. That makes sense. Yeah. Um, I know that phrase out of band. Yeah, but I think the reason why Dan prefers those terms is that for certain, for certain communities and people, those are, those are fighting words. Like, what do you mean what I'm doing is like, how? Yeah, I know that there are certain communities that are very attached to doing non cloud native things and don't like it being pointed out. Yeah, which is, which is part of the reason that we're, that we're looking at using the term bronze rather than. That is perhaps too shiny and durable a metal, but yeah, I trust Dan's wisdom in this regard. But I, you know, I did nothing, nothing that you do to massage the terms changes the facts. There's significant influences who desperately want to go to market as vendors with their utterly non cloud native solutions and show them at customers who are SP's and desperately want people to stop pointing out how non cloud native they are. Yeah. So my goal is to not. It's really to say this is what it means. And here the arguments, if you're not doing these things, then you're not cloud native, but I'm not going to, you're not cloud native. And for CI CD, these are the goals for it to be cloud native so it can be orchestratable and things. Yeah. Otherwise don't get the benefits. Yeah. Actually, instead of bronze a CNF, like perhaps the, perhaps there needs to be a term towards. As I mean, the entire concept on that stuff was to provide a progression. So as a, first is to provide a progression. So if you're trying to become a best practices, cloud native never function, like yours, say, here's a reasonable path. That things you can do to move up the, to move up the, to move up the, to move up the, to move up the, to move up the, that things you can do to move up the, to move up the chain. The second thing is, is risk mitigation for the operators because your risk profile is going to look very different. We take up a bronze CNF or main goal CNF. And so I think, I think that's a part of what's been in the happening is my, my hope is that what happens is that the operators, they, they don't look at it as a rubber stamping of a CNF where you just had to lift and shift minus things that require privilege and stick it in a container and instead look at it as an a, well, our risk profile is we will only accept gold CNFs and we will review on a case by case basis bronze and silver based upon, based upon availability in the market and need and so on. And so, so my hope is to provide them with a, I will refrain from pointing out some of the other entertaining monikers that have been suggested to replace bronze. Yes. So I was just saying they were, they were not, they were not friendly. And so Okay. And so I have for now. Yeah, but keep, keep telling us when you hear things that, you know, where people are, are unwilling or unable to, to tell us. Cause like this, this is very, this is very useful as well. Yeah. Yeah. The rule of thumb I was saying, if I hear something, you know, 50 times I'll make a video based on it. Things have been changing a lot lately, but we keep saying things over and over. Then I know we can do a five, three, five minute video on it. I was hoping this glossary or something along these lines. If it's, you know, we keep using this terminology, then that might be it. So see. Yeah. To paraphrase the department of online security. If you see something say something. It's, it is, it is very useful. Like it's, it helps us work out if we get the messaging right and helps us work out where we need to, where we need to improve. And, and it also helps us work out where, where we are getting things wrong. So sometimes the questions are not due to a lack of understanding, but because there is understanding there and, and they might identify the problem. Awesome. So Joe, do we have anything else that we need to discuss in this call? I don't think so. I think, um, I think it's pretty much up. All right. Cool. Talk to you guys next week. Thank you very much. Thank you.