 It looks like Jeff free is not available to attend this. So does anyone else have topics I'd like to discuss as opposed to the meeting notes? So I think that Frederick was wanting to talk at some point about release notes, which I think it's something probably we should walk through at some point. I know that there was also an actual item from yesterday's meeting about looking at how to take some of the stuff in the technology tree and turn it into a proper roadmap. So there was, let me stick this in the chat. There was this stuff, better yet I'll put it on the agenda that would be even smarter. Yeah, I mean, it's essentially, it's a visual representation of the dependencies between various pieces of work. And in most cases with links to the spec around it and some attempt to sort of thematically group things that sort of have to be done together. But there are some things we have specs for that are not made it into this picture. And there are some things in this picture for which we still could use some specs. I'd like to think of it as a... You're very, very faint, Frederick. Yeah, I think my headphone is not picking up with the microphone, so I'll have to probably talk into the phone directly. Yeah, so I'd like to think of it as a skill tree. Where we spend our time is what we get back in return. Yeah, no, it's drawn this way precisely because of the way that Dan talked about the technology tree and civilization in his keynote. Ah, okay, so there is a dark correlation. Oh, no, no, absolutely. I'm remarkably devoid of original ideas. So, but I mean, even then, this tree is something where you'd have to explain what some of the different pieces are, right? So you'd wanna have a documentation where you walk through sections and you highlight the thing and you talk about where it's going to be feature-wise and then that kind of stuff. My proposal yesterday was to actually keep this in spec, if I am unmuted, yeah, I am. You are unmuted. But yeah, you might use other opinions here. Should we keep it just as a link to this presentation? I think that's a good place to start, but I don't think it's a good place to stop. Okay, so we're 10 minutes in. Do we wanna dig into any of these items? Do we want to go and write a little bit and come back next week? How do we wanna proceed? I think that we should first check if Fred wants to go over the release notes, if that's, that would be slightly more urgent, I assume. Yeah, so do you wanna walk through those, Frederick? Yeah, I'm sorry, I'm having some trouble with internet over here. This conference internet is absolutely horrible. This is commonly true. Yeah, I'm just waiting for Google Docs to load and it's not loading for me, so. It's more complicated than I thought. Yeah, I mean. It's too complicated. No, I actually forgot that we still have to, I don't know, to put the messaging that I kind of skipped this meeting, but there was some discussions that you were trying to figure out the messaging about NSM in general, that should go into the site and probably into the release notes to some extent, because we here have, again, this RFSR architecture has been built for Kubernetes. These components include, blah, blah, blah. And then, yeah, there's discussions, if this is the right wording, if this is what it's going to say, et cetera, et cetera, so. Yep. I mean, some of it is just like, wrote work, it's just somebody has to spend time like on the to-do for getting started. And we need to just start putting images down as they become available, like once we've signed them in. In terms of, we have a to-do for inserting the logo, the logo's there, so we can get rid of that. Yeah, I mean, yep. I think what I would like to know though, is like, is there, from a high level, is there anything that we want to call out that we haven't called out? And I think that's probably the most important thing. So, let me actually, let me show you as an example of something I would love to see us do with our front page. Go take a look at openpolicy.org and scroll down to use cases. From policyagent.org. Yep, now scroll down, this is where they got the index of use cases, but keep scrolling the places that the links will take you on the front page. Well. Now, also note that there's literally, if you scroll a little bit to the right, or you know, because we can't see the full width of it, but it shows you this diagram for the use case, and then if you scroll a little bit to the right, oh, I'm sorry, maybe it's, okay, yeah. It's martial below for you. For me, it's left to right. But basically, it shows you the diagram and then like a little terminal window that shows you what goes into it. And it does this for all the use cases. And it strikes me that if we did something like this and also had, you know, it set up in such a way that you could actually run those use cases, because you'll notice that you can actually select the text in the little images that they have of the, you know, so basically, if we had something that ran through, okay, this is how you go and run the VPN gateway example, right? Then literally when people land on our front page, they can see some of the examples of what we're about and they can try them. I'm really, I really love the way they've done use cases on this page. I don't know what other people's opinions are. Yeah, these look good. Well, are we saying that for the part where it looks like there's a piece of code, we're saying that we're having the YAML, like our YAML declarative for the CNS for NSM? Is that the idea? Well, and or, I mean, so if you had a terminal window piece like here, you might actually, you know, show, okay, this is how you go and you run it. Your Q-Control, apply or home, install, blah, right? Okay, we can do that. And then you get to see, you know, effectively a very simple walkthrough of the whole thing. Sort of set up as a really quick snapshot like that. So not long and meandering, but literally something where you could see exactly what you were doing and see results immediately. Something that makes it super simple. Okay, so installation, not like configuration. Yeah, so it would be things like installation, home install NSM, home install VPN, the Q-Control to redirect the, or home install NSM monitoring, the Q-Control to redirect the Skydive that shows up as a clickable link to whatever that local host port would be. And then you show the picture of what you would, something like what you would see in Skydive, right? That kind of thing. Okay. It was kind of what I was thinking. You've got probably the best visual sense on the call. So I would very much welcome your thoughts. I guess the, we were Fred and I and some other people were talking about the different profiles. So there's the application developer profile, the operator profile and the, you know, like maybe CNF developer profile. And depending on what's- One use case each is probably a really good way to represent it. Does that make any sense? You know, so basically, you know, sort of a, you know, sort of leading with, you know, you want to offer NSM to your, to your Kubernetes cluster. Here's how you do it. That's sort of use case one. Use case two might be, you want to take advantage of the VPN gateway network service and point as a developer. You know, and you could show the yaml of what you add to your file, right? And then maybe the very last use case is you're, you know, you're a network service. You want to develop a network service and we could show like, you know, the legal blockness of the SDK for that. Does that make sense? Yes. I think that would be good. Yeah. Cause I like the notion of profiles. That's absolutely true. Right. Use cases for each one. I mean, it'll show each class of user what they're, what they're going to get out of it. You know, like someone who's Sarah, what does Sarah get out of it? She gets something very simple that she can consume or your, if you're an operator, you know, we can work out, we can work that out as well and say, okay, this is what the operator gets out of it. So, and there's definitely more, more personas that we want to, that we'll eventually wants to show off. But I think we should probably be limited to three on the, on the website itself. What are the three that we really want to express? I think the ones that we spoke about here, probably the highest, the highest impact is. Yep, I would agree. Seems like the, those use cases for getting started can be done separately from this document saying release nets. Are you, are we using this as a guide for all the things that want to be, that you want to be done with the release? Or is this literally the release notes and all of these items have to be part of it? So what I was talking about here is, yeah, so I think this is working out the release notes, what we have in front of us here, what I was suggesting was basically redoing the front page so that it grabs people. Does that make sense? Sure. Maybe then we could say the getting started, what's part of the release notes here. You direct people to the front page. So just going back, we didn't have, yeah, homepage redesign, so I see this here. And specifically you're talking about how to get started based on use, someone's already putting it in. Thanks. For the release notes itself, do we want to keep this item in here or pull it out? Like, is it necessary to have a getting started section as part of the release notes? Or can we pull this out and know that it's being handled somewhere else? Possibly bottom of the front page of the website. I'm okay with either direction. If we do a getting started location that is more likely to be up to date over time, because we, like if someone sees our 010 release notes and we're up to version one or two, then definitely want them to be the newer version. But at the same time, there is something really nice about being like, you're in the document and it's like, how do you install it? And just having like one or two quick line-iners is like how something works might be interesting. But it may be, this might be a little, because of its flexibility, it may be better to stick this inside of like getting started guide somewhere as well. You could always have a link from this to wherever it is. And ideally the getting started is gonna be, as you're saying Fred, it'll be kept up to date. And it doesn't matter whatever release you're looking at. If someone is looking at a 0.1 release, but you're on point or 2.0, then you would, I would think you'd want to send people to whatever the current getting started is and not have people getting started on something that was released a year ago. Yeah, I think you're right. Yeah, and I think what we should do then is we should pick a URL that is long-living, like network-service-mesh.io-sh getting started or something like that, that even if we decide to redesign the entire website, that one URL will always point to or redirects to the replication. That sounds good. So they have this getting started, which actually goes outside of the main page, but it's not those use cases. I don't know where is the, I guess you just happen to be, you have to scroll down and see this. But if you have, well, it didn't show it's in the page, but if you look at the link, it's an anchor on the same page here. So this data filtering use case, you could have something equivalent to that where it's slash getting started or slash with the, I'm going to open it like this just so it goes, but something like that and a getting started section. So change this to be a link. Okay. Is that the idea here? There should be a link here. I think that's a good idea. Like we, if we add in a link there, then we can point to whatever that page is that we want to, that we want to do. Great. Are you okay with me resolving this one that to do? Well, I guess it says, I'm going to put it right here actually for the other time. Yeah, I think that should work. Okay. What are the other items? For the Docker images, did we ever come to a conclusion as to how we were going to, of what format we were going to use? What format for the Docker images or? For the tags rather. I think we got roughly a notion of what we were doing, but I don't think we came to final, final resolution. Let's punt that part until later then. Yeah, so I mean, I think the highest value thing for me then from this thing, because a lot of this stuff is just busy work. It's pretty easy to get done once. I just want to make sure like in the, in the what's new section, is this, is this what we want to just say is like, is this the, is there anything that we're, that we want to specifically call out? Yeah, I think that's actually a really good start. The Network Service Mesh project itself, we call out the APIs. We can, I was thinking about putting a couple examples So you're still very faint, Frederick, but I think I kind of get where you're going, because effectively, effectively you've got the Network Service Mesh architecture, there are some APIs that back it and then we have this reference implementation that we've done for Kubernetes. Is that what you're getting at? Yeah, that's what I'm getting at. I want to show like, because we're, this is a huge release. Like our first release has had like a year's worth of work. Yep. And I don't think we can do justice to the project by trying to call out important commits or similar, but I do think that we can show high level ideas and we started with, what is Network Service Mesh? What are the APIs? What is the architecture for it? And then just drive down into more details of what we're releasing until we get down to the concrete. And so the concrete, here are the APIs you can look at. Here are the, here's the reference Kubernetes architecture, which has real things that work today. Yep. Totally agree. Do you want to call this initial release versus what's new? Yeah, that's probably a good idea. Yeah, and so- Is all of this wording still good for this section on the Network Service Mesh API? I think it is on that part. Well, we'll need to give a couple specifics on how things look, but yeah, in a nutshell, I think that's good. Yeah. All right. So what are, this is talking about to do for specific APIs. So this would be, it sounds like interesting APIs for different personas or groups. Is that what you're thinking here? Yeah, like I'm thinking that we don't have to list every protocol buffer that we have, but I don't know. Yeah. Let's not. But I think that if we list some of the ones that we, that are, I guess, again, the highest impact ones, like I think the NSM to NSM or the- The remote API? Yeah. I think that and the surface registry are the really two critical ones that come to mind. Yeah, because if you understand those two things, then you pretty much understand how to interact with NSM as a whole. And you can, you can do useful things with knowing only those two APIs. Yeah, agree. We'll add in, add in to the node onto that would be useful. What is the API again? Called the remote API and registry API. You know, one thing might be silly on my part, but from the beginning, when we talked about GRPC and network service mesh, it seemed to me that the literal network communication was going to be over GRPC. And I guess that's, that's not the case, right? It's through different various cross-connection, regular network connections, and you could be all the normal stuff. It's just the API is GRPC. So that was, to me, actually was a confusing thing from the outside. So I thought it was somehow significant that that was the case or something. It's just essentially the API GRPC. Okay. Yeah, though that makes sense. Do you want to put anything on this like a small highlight what these are for? Okay. And is there any other ones that you want to put? Yeah, I think in this scenario, we definitely need to fill out a little bit more. And I think the visualization is well combined with that will help. There are existing visualizations for any of these APS? There is some in the deep dive that we can go and pull. I just realized it is a generator and I'm an indexer. In the Python sense? Possibly. Cool. Yeah, so I think if we, yeah, I think both of those combined, we'll give a short description about them. We'll link them to the registry API so they know where it is in the registry API. Show them the visualization. And I think those combined will be more than enough for this section. People may ask about, well, what about the pod or so on? And we can point them towards that when they want or in other documentation where it's more appropriate. But I think for the release notes, those two are good. Is there a API document, a living API document right now or something where someone can go and look at all of the NSM APIs? They are in the GitHub repo. So maybe add a link to this? You would probably want to add a link with a guide because they're in several files for reasons that are really useful, but really unhelpful if you're trying to write an API guide. Yeah, I actually think, Go ahead. I think in the, this is not something to really drive at this point, but it may actually in the long run be useful to even move the APIs out into their own repo so that you don't have to consume the entire Kubernetes infrastructure to consume the APIs. Very likely a good idea. But for the moment, this is a good spot for it. And I think we could give a link to where they're at, but I also agree with Ed. I think that's why I wanted to focus on those two is because you can pretty much build an NSM and get a good understanding as to how it works with just those two. And we could probably point people to, like the deep dive or something similar when they want to know more about the other APIs. And we say, we'll go find the relevant section in the deep dive. Yep. I think people are going to want to be able to go and read, well, I'll save it. I'm that type of person. I'd want to go look through the different APIs that are available if I'm writing something versus a video. I want docs and or code where all of the APIs live. Ah, sorry. I was thinking of the slideshow as opposed to the video because it'll have as visualizations with the protocol buffers. But if it makes sense to do it in a document form, I mean, we could probably do something along that as well. All right. So what about this next section? Yeah, I'll spend some time writing a description out on that, a first pass on that. And then we can beat up my wording afterwards. Basically, the idea that I want on it is just to say that the reference architecture that we described is high level. Like what we're describing is high level and we're saying that this is actually a subset of NSMs capabilities. So basically, this doesn't account for ENSMs or how do you do proxy NSM patterns. And so I think that, so with a brief preface of what the reference architecture is and then we can go straight into the actual reference architecture and the one last thing as well is we need to work out where do we want to put the glossary because it actually feels unnatural as to where it currently is with the to do. I immediately below the description. So that's probably the last thing that we want to, that we definitely want to call out as well is like, here's a list of all of our terms. But at the same time, I think the reason why it ended up with the to do there is because in order to really understand this next section, it may help to have the glossary available. Does that make sense? Yep. So I'll see about wording in such a way that we can we can get to that glossary. The only thing that bothers me in the glossary though is that the glossary may change over time and then words here may become a nonsensical to a future reader. So that's my only concern with it. Agreed. If this is for the release notes, then the glossary, if it's a snapshot in here, then it's relevant to everything you're talking about. So up here at the top, when you're saying initial release and going through things, there could be items that you're talking about here which may change in a future release, but right now the glossary would be relevant. Yeah, maybe. I would say anything that you talk about directly in the release notes where you could add a glossary items for this and then give a link to the current glossary for additional information which will relate to whatever the current release is. Yeah, the only thing that I worry about is this document getting, it's already a long document, so I'm concerned about the length of it as well. But we could have it as an appendix or something saying your relevant terms or something similar to that. Sure, or just put a link and delete everything else. Yeah, or yeah, a link to, I could also just do it. I could create a PDF of version 010 and say here's the glossary as of the state for release version 010. And then I could just link to that and then not have to worry about it ever again. Yeah, so I think those are the main things. I don't think I have anything else to really go through other than, eventually we're gonna circle back and we'll go over the known issues that we want to call out. But beyond that, I think I'm pretty happy with where it's at at the moment. Yeah, I think it's actually, we have a small set of miss that we still have to sort out, but yeah, we've actually done a pretty good job overall I think. Yeah, and the known issues that could even just be a, that could also be a link to a living document that says like, as we put it out there, I expect the list of known issues to grow. So we could put that in a link and say for version 010, here are the known issues with it. And then that actually ties us into the next version which is here are the things that are fixed. So that reminds me, I need to reach out to see by getting the website front page design kicked off again, unless you've already done that Ed. No, no, I think you probably wanna reach out to Luke for that. Yeah, so I'll reach out today. I'll send him a message on that. And yeah, I'll tell him I like, or tell him that we like what we saw in Open Policy. Like I actually think that's really powerful and I actually wanna use Open Policy now because I saw that. Yep, yeah, I mean, it's, they've done a really nice job at that front page. It's really quite stunningly well done. Okay, Ed, and do you wanna go over the technology trade or roadmap? Do we have time in the next? I mean, I can hold a few bars if you wanna bring up the technology trade. I don't think we're gonna make a lot of substantive progress, but we could at least introduce it. Okay. There's an incredible amount of value of just warming people to ideas. So this is an attempt to look at some of the stuff that we're looking at going forward. And basically what I've done is I've sort of taken some of the functional boxes. Like we've got a bunch of stuff we know we have to do about security. Getting inter-domain finished probably really depends on that. We've got a bunch of things that we wanna do around being able to get DNS support, right? That probably depends on various things around maybe possibly transitioning into containers to NSC monitor containers, that sort of control plane sidecars. As you sort of go through this and you say, well, I want hardware NICs. Well, properly doing hardware NICs is something for which you're gonna wanna inter-domain. That kind of stuff. And so building out the tree of interdependencies and then just trying to capture the things. And I use some of the blue and the green background just to make it easier to pick out where there are clusters of things that are related to each other. Does that make sense? Yeah, this. Yep. I'm still not sure why inter-domain. I mean, I know I have read the spec, but I'm still not sure why hardware NICs and SRIOV support is bound to inter-domain. Well, so basically what it comes down to is, let me sort of put it this way. If all you wanna do is drop an SRIOV into your pod, you can do that right now with device plugin. But of course, the interesting question is, what does that SRIOV NIC connect to? Right, that's the really interesting question is, what is that SRIOV NIC connected to? And the truth of the matter is, network service mesh where it really has value to add in the space is in allowing you to say, I want this network service to be on the SRIOV VVF. And the cleanest way to do that is with inter-domain, because then the people who are controlling the Torports, who actually are mechanically in charge of what shows up on that VF as a service, they can have their own manageable domain. I mean, I know the data center people I've dealt with, like approximately zero data center humans are ever going to turn over control of their Tor switches to some separate administrative domain that's being run by their freaking Kubernetes people. It's just never gonna happen, right? They'll run away from that because it feels dangerous. But if you give them the domain for those that DC network stuff and you expose it as network services, they can then show up in those pods as SRIOV VVFs or physical NICs. That's something you can get NetOps guys comfortable with. That make sense? Yeah, but I mean, isn't it like same domain? Like, I mean, if it's the Tor switch, I would kind of feel like it's something that can be within my domain or also. Within the domain of the Kubernetes admin? No. I mean, apparently, you don't much mind your Kubernetes admins than I do. Okay. The truth of the matter is like, you don't have to do it that way. It's just any realistic deployment I think it's gonna look like that. Does that make sense? Yes. I mean, because what we're doing with Taylor and essentially the guys from the CNCF CNF testbed is that in order to be able to insert the traffic generator traffic to inject it in the NSM, so that you can pass it through the routing chain, you have to figure out a way to essentially connect to the outside world and we call this kind of gateway or something. And even we have a spec about the gateway. And I was just wondering how this mix with this hardware and the accessory, et cetera, because we have to figure out a way to inject traffic outside NSM. Yep. I think what I'm hearing here is that there's probably a need to revisit those specs and pull them together more coherently. Yeah. I recently did an update to the interdomain that I would highly recommend folks look at. It takes the same initial idea and it makes it a little bit more flexible. And it occurred to me when I was doing it that it actually makes, it actually starts looking more gateway-like in some sense. And so that should probably be some revisit of the discussion about the gateway spec as well. Okay, but I mean, the bigger idea here is are we saying that because essentially the gateway is kind of the translation point between the physical outside world and the inside NSM world, if you want to call it like this. And then here what you're saying in this interdomain arrow to the hardware NICS SROV essentially means that hardware NICS SROV are represented as services that the NSM guys are supposed to consume like the NSM pots or clients are supposed to consume. So it's a bit. Yeah, what I'm actually suggesting is that SROVVFs and hardware NICS are actually local mechanisms by which these things can, they're local mechanisms by which you can connect your pod to a network service. It happens to be local mechanisms where, they're coming via the SROVVF and where the thing that's actually providing the service is a Torport, but they are basically local mechanisms. Does that make sense? Yeah. Okay. We definitely need to revisit it. Ed, it might be good on taking it off this call for to get with you and have you reviewed the latest updates for the use case that we're trying to implement. And then see if what you're doing for these diagrams on how it fits together in this tree already are covered or not. I think what's actually the most productive with this, quite frankly, is effectively the following, which is the stuff that you are currently doing, I think from what I've been seeing, like, Nikolai has super well in hand, there is stuff that you're clearly going to want to be doing at some point. You're eventually going to want to let an SM manager, a SROVVVF, right? And when you get to that place, then you're going to want to, when you get to that place, you're going to want to start considering the stuff that's going on in those facts. And so I would say that looking at them earlier is better. Does that make sense? Yeah, I think we may be there with the use case at this point. We're essentially putting, we're trying to have a CNF or that has the mechanisms to talk to the physical interface and whatever that would be. You could think that could be SROVV or whatever type of access, but we're trying to implement in my mind, and I think that may be what Nikolai is saying, that portion in the upper right. I think we're actually trying to get this working as part of the latest one. I think you may not have seen it. Yep. We may be at a point where we actually need what you're talking about. Okay, I mean, we can definitely catch up and make sure. Okay. Trying to go out a full screen and share it. All right. So I think that's it. Do it. There are some action items in the release notes. Do you have a link for the updated reference documentation, Ed, that you can drop in here? The reference documentation for... Yeah, you're saying there's the specs that may be more relevant. All the links from the technology tree are actually up to date, so like the interdomain and the hardware neck links in the technology tree, they're all up to date. So, you know... Oh, okay, great. Would this be the one that you're saying to review? Yep, exactly. I think that's what you were suggesting about how to use the local mechanisms connection. Great. Yep, yep. All right. Well, we're coming up on the hour. Is there anything else? This has been good. Thank you. Yeah, so one last thing. We probably need to add skill points to the skill tree. That's awesome. No, I think this is all excellent. And I think Dan's gonna be a bit... At first, he's expecting a roadmap, but then when I think we give him the skill tree, I think he'll be pleasantly surprised. Yep. Thanks everyone. See you next time. Thank you guys. See you. Thank you very much. See you.