 HA is asking the question, what do you do when one component fails? Okay, what happens when one component fails, what do you design for when one component fails? Disaster recovery given a failure domain is what you do when all the failure domain fails. Everything is wiped out, right? Of course, you have some other failure domains, but that is lost. So that's my distinction. And obviously disaster recovery, normally people immediately associate the failure domain to a data center. That's the common understanding, I think. But failure domain is a fractal, you know, kind of constant. It can be many, it can be many things. This is a georeplication and disaster recovery or bleeding into each other. Disaster recovery is like a set of tools to restore the failed site. That's the old, I'm not hearing you very well, but that's the old way of thinking, right? As soon as you say restore, as in, I was backing up and then I have to restore it to somewhere else. That's exactly the old way of thinking. We now can do constant sync between our failure domains so that each have a copy of the state or enough of the state so that they can continue work if you lose one of the failure domain. And that's really the message that we have to give in this paper to say, look, there is a new way of thinking now and new options provided by the technology. And you can really set up your failure domains in such a way that if you lose one, you don't have to stop. Your service is still up and you can continue to serve. I like the georeplication. Sorry, go on. I was just confirming what he said. I was using a bad mic and what he clarified was kind of what I meant about georeplication kind of taking over disaster recovery. Okay. One of the things I wanted to add is we're giving the orchestration more work to do. That's a good thing as we go move towards more of a declarative model for disaster recovery and letting, letting, letting policies make those transitions in those when they're within a cluster. That are understood and when they're between clusters as storage can often be, it's less understood. So somewhere along the line that checklist for orchestration, I would like to see a discussion around that so we can get to the same nouns and verbs. And who's do who's taking on what role, or what entity is taking on what action. That's, that's also another good point. I really like the concept of HA being defined as, you know, the failure of, of components, whereas in people's minds, the R is, is the failure of, you know, a group of components, or, you know, and often that's tended to mean a data center but I think, honestly, we should kind of look at this in terms of a failure domain or an availability zone, because the, the same exact concepts that apply to two data centers also apply to two racks or, you know, two availability zones and a cloud provider or whatever. I think what we're, what we're talking about is, is sort of losing the entirety of, of, of a physical, of a physical location and that can be a small or large component. And I think, yeah, just just following on from what Tom said there as well, you know, how the topologies affect the orchestration, where you're, you know, where where you're discussing where we can, you know, potentially discuss how different systems replicate or, or, or provide, you know, data protection across sites or across failure domains. Versus, for example, you know, what's what's also quite common is, is to have distributed topologies which are actually matched across multiple locations or across multiple, you know, sites or whatever as well, and middleware that's required to do that. So, so yeah, there's, there's, there's a lot of interesting topics there. I really do think that this this could be one of those things that, you know, it could be a hundred page document if, if we're not careful and I would, I would strongly suggest based on, you know, what's happened in the past right that, you know, we want to make sure that we actually produce something. So, scoping out at the beginning and figuring out which sections we want to deal with is, is, is important because I would, it would be lovely to do this incrementally I, you know, we may be able to put together something that just defines terminology and concepts, for example, and then we could, you know, expand on it to provide additional detail in other areas and the document can become a living document. Because the, the worry is that, that this becomes one of these mega projects and it takes us a year before we actually can release anything and that would be sort of less, less useful. Yeah, I'm just, just want to add to the discussion of how to call it, if it's disaster recovery or to your redundancy or something else. I ran into the situation that disaster recovery is more used in the sense of business continuity. So, I have seen and heard people using disaster recovery for making sure that your workforce still has an office to work or your workforce still has internet connectivity, or that you have a contract with Home Depot to bring in power generators, things like that. So the term is really also used in different, with a different meaning. Yeah, that's, that's, that's fair. We could easily spend two hours debating the term. I suggest that we, you know, that can be something we can, we can talk about for sure. I'm not, you're right, I'm not entirely sure what, what the, what the final terminology should be, but I do strongly believe that once we kind of highlight the scope, we'll be able to, we'll be able to make that something useful. The, the, I kind of feel that the scope of the document is where people will have the most opinion. So, just, just in terms of next steps, Rafael, if you, if you have the time to, to put together some, some bullet points or topics or areas that you think we should, we should cover in a document that that would be a good start and then maybe you can share it. Share the Google Doc with the group. And I'm sure we'll get sort of lots of comments and lots of feedback. Okay, I can do that. I also would like to do what Quinton was suggesting. Maybe I can bring this team up to speed with what I have already created. Sure. Yeah. And just give you a brief, you know, maybe I'll create a deck that summarizes all the content that I have to see if we can, you know, if there is anything that we can reuse or it's interesting for this team. That would be absolutely fantastic. Yeah. Do you, do you think that this would be, that this would be something you could do for the beginning of January, maybe? Yeah, yeah, I think so. Sounds good to me. Really? All right then. Okay, so, so we'll, we'll, we'll show you that in for the, the second Wednesday in January then. Okay, wonderful. That sounds great. And thank you so much Rafaela. This is, this is a brilliant, brilliant topic. Does anybody else have any other questions or any other items we want to raise? Because otherwise I think maybe we can finish this goal a few minutes early. Quinton, anything from your end? Or Philip, sorry. Yes, Phil. I just, maybe pretty unrelated. I tried to file periods for CNCF Sandbox and filled out the form and I'm a little concerned because nothing came back, not even an email. I have a link to the spreadsheet I can dig up for you. Yeah, I, I can, yeah, I can, I can send you that link as well. The best person, if you're on the CNCF Slack, the best person to ping is, is Amy Scavarda Perrin, who's the CNCF project manager. And she does the, she organizes the scheduling and the project voting for the Sandbox. Okay, what, could you repeat her name, Amy? Amy Scavarda Perrin. It's, it's, it's AMYE. Okay, I will try that. Thanks. I put the link in chat to the spreadsheet. I see, like, GitOps, working group, Perius, Datastore, that query twice and then he's on Docker swarm or I don't know. Anyway, there's a few entries in there. Okay. You'll want to check the form responses tab. My link might go straight to approve projects tab. Okay, perfect. We'll do that. Thank you. Oh yeah. Yeah, it is actually in that spreadsheet. So you're, you're good for that. Perfect. Awesome. Anything else? So just, just one kind of public service announcement. We probably have more deep technical work than we have capacity to do it next year. We're going to have to do a lot of project check ins and evaluations of various things. Short summary. I think if anyone foresees themselves having enough time in the new year to, to serve in the capacity as a sort of senior technical person on, on this. I think it would be a good time to give it some thought over the, over the holiday period. And then we can, we can sort of start talking about that more in earnest in the new year. Indeed. If, if just echoing what Clinton said, you know, we're, we're, we're looking for techniques who can help join the second and can help with project reviews, but also, you know, working on documents like, like we're discussing today. All right. Thanks everyone. I think we'll give everybody 15 minutes back if that's okay. Have a good rest of your day. All right.