 Okay, and that's five after the hour. So this is Dan Kahn, Executive Director of CNCF, and I am actually in Paris today, closer I think to a lot of our regular participants. We have made good progress on this first chapter or preamble to the Cloud Native Telecom User Group white paper. So I want to thank everybody for their involvement so far and see if we could try and talk through what are some of the open issues that folks are aware of. I don't think Alex Salkever could make it on this call. So I'm curious if Lucina or someone else might be able to say what are some of the areas that are most contentious here. I'm actually, I think Alex is also going to be able to remove a lot of these comments the next time he goes through here. So that was the main thing that I was looking to do on the call today, our hope, if we can reach a rough consensus on this, is to be able to publish this white paper and preamble and announce it in time for KubeCon in two weeks. The other topics is that we do have this joint Tug and CNTT meeting that's there's two of them, two hours each occurring on both Monday, November 18th and Wednesday, November 20th. And I did want to encourage as many folks as possible on this call to attend. And then Lucina and Taylor, were there other, let's see this, yeah, so we, and then so one of the big areas that we need to discuss is the CNF definition. And then another one that I wanted to highlight in the white paper is the diagram of what used to be on past, present, future, and I just replaced that it's now at the top of page eight under the section involving the stack from BNFs to CNFs, where I tried to simplify it drastically and would like feedback on whether I succeeded and whether that new format makes sense or not. Lucina, could you find that? Yeah, it's that page eight diagram on the next tab. That's the footnotes. You're not looking at the right document. It is, yeah, exactly. And there we are. So I previously had a past, present, future version of this and it was specifically linked to some ideas about functionality in ONAP Amsterdam versus ONAP Casablanca, where it might be in the future. And so I really tried to simplify all of that away and just talk about this CNF architecture. And are there other, yeah, so we need to talk about agenda items for the joint Tug CNT team meeting. Taylor, were there other topics that you wanted to discuss on this call? I think this is probably enough for this call. I think if we wanted to take a quick view of the paper, the chapter one, and then maybe dive into the items that folks want to talk about, including the CNF definition. The request for comments, I guess I'll just repeating that we're wanting to get feedback before Wednesday and we're planning on setting the agenda. So this is a LF wiki. If you have an LF ID, then you should be able to update the wiki, add items to the brainstorming. And we have kind of a tentative skeleton. We're thinking lightning talks on the first day. And maybe some more in-depth working session on the second day and potentially a panel. But if you have ideas, please add them to that. Maybe one thing to follow up on the definition specifically, Dan, to try to help people that are in different parts of the world and may not be able to attend. Just a suggestion to have a follow-up to today's discussion of the chapter one white paper items and put out some suggestions for time. So if we can get those on and I'm willing to join an early morning to make it easier for people in Asia Pacific to join. Yeah. So if we scroll to that page, I believe it's page five is where we have different alternatives. And I wanted to throw out some principles to try and select it here. And I think we could probably do it fairly fast, which is I'm very interested to link to I believe it was Frederick who made the suggestion link to Etsy as a informative reference. That I think there's a huge amount of work that have been done in the past and a lot of valuable background that people should look at. But I would really like to try and avoid making normative references externally, where it requires you to be on top of all the Etsy material in order to understand the meaning of this document. And I'd like to try and minimize the normative references we made period at all. I do already have one exception to that, where we're making a normative reference to the cloud native definition. But because that documents three sentences are also controlled by CNCF, it's a I think a simpler process. And so I will come in and I think make my own all six suggestion here. But I guess I would love to see is there anyone and I was curious to hear on your perspective that has a perspective that a CNF can't be about whether it just a container can be a CNF or whether it has to be a pod or whether it can be a collection of pods. I think I think the fundamental question is what do you associate with the letter C if you associate containers and there is one answer. If you associate cloud native, then naturally containers or, you know, maybe even pods are not enough. Pods are certainly better because there is the assumption of using Kubernetes for orchestration containers, you know, you can use without Kubernetes and therefore could be heavily contested whether that could be considered cognitive. Sure, I will say that I helped coin the CNF term. And we were always clear that it was cloud native network function, not containerized network function to try and make things a little bit more specific. But that doesn't totally answer my question about trying to limit exactly what a CNF is. I would say not limiting it to containers or pods. Since I expect the platforms, including Kubernetes to use whatever underlying blocks make sense. I think the functionality may look similar to a pod or container. But there may be something that's not a container. And I don't think that's the definition of a container. And what it does is what I think you care about. And then more specifically, all the different parts in that would be the principles around being cloud native. And so you suggest that go on, go on. I would say that a container is an implementation of one part of that and just like pods, they're an implementation. And the technology that's implementing those, if we point to those and we need to grow beyond that, then we're not going to cover it. Or if someone came in and changed those and it's from someone's perspective of caring about the principles, maybe a pod is no longer cloud native. Unlackly, but that would be why I would say let's focus on the definitions of what they mean versus the implementation. I tend to approach the kind of cloud nativeness from the benefit and in the telco context, certainly the benefit is the desegregation, but also the unified lifecycle management via Kubernetes APIs. And so I would not link it to containers necessary because we might want to introduce new runtimes, handling VMs or Cata containers or whatnot, which are strictly speaking, not containers, not just Linux containers is something else. And therefore, if we limit things to containers, then we sort of shut down the cloud nativeness towards those technologies, which is certainly not something I would support. Just my two cents on containers. So containers are excellent for an example, but it cannot be only about containers. Exactly, that's it. Like it can be used as an example, but like either containers or bots, but I think like limiting it is not perfect. I think it's worth pointing out that the kind of five the five alternatives that we we've put into the chapter one document. I don't think any of them mention containers. I think that's important to note. There's a lot of talk of microservices and immutable infrastructure, but I don't think there's any mention of containers in those definitions. So this is Ramki. So I think it may be worth actually pointing out the distinction of the concrete example. So what I'm seeing is like, if you go to, for example, the RAM components, for example, CU, especially the DU, there the movement is just around containerization, but not really cloud native. I think I can, in fact, add that I can volunteer to add that. That really is a pretty concrete example, which is emerging. So then that draws like, hey, if you want to just go containers, but not truly cloud native embracing Kubernetes, and this is like a method to do this with an example versus just saying, you know, it's always cloud native, correct. So part of the way that I think of cloud native is if I if I have a piece of software and I stick it in in a cloud native orchestrated system, will my system will my application gain the benefits, the majority of the benefits that that people typically look for in such an environment? So, for example, can I scale it horizontally? Or can I get it to auto heal and recover? And is the configuration declarative so I can configure it in an easier and more holistic way? And so I think part of it is trying to try to drive the definition in that path. And I think part of the problem that we're going to run into is like, yes, you can build some like something that follows the cloud native definition, but and then stick it into something into an orchestrator that does not support cloud native principles or cloud native orchestration. And even though you've built it in this particular way, many of the benefits like you'll still get benefits out of it, but you won't get that. It's it's when you couple it with the orchestrator that you get that you that you maximize the benefits. So that's the heuristic guide that I tend to use myself. Frederick, can you go ahead and recommend one of the five options though, based on what you just said? Sure, let me read the five options. So and it looks like someone's accidentally deleted part of all one and all of there was all one dot one. I don't have access to the version history. Can someone put those back if you have like undue capabilities? I do. It'll just take me a minute to find it, though. But I don't think I'm the one who broke it. I just have suggest access. So I don't think I did. Well, that's ongoing. I think one of the big difference between the different alternatives is some of them are talking about cloud native network functions while others are talking about cloud native network applications. And I think it's worth pointing out that while, you know, typical telco functions are cloud native network functions. Network functions themselves are usually defined by standards like 3GPP, while application can be anything like an OSS or a BSS as well. So naturally, application is a much wider category than network function and a much less already defined category than network functions. So for that reason, maybe it would be better to talk about applications and not network functions. If then you are adamant not to link into any other normative definitions then network functions are very clearly defined by ACNFE and then the network functions themselves are defined by 3GPP. So maybe it's a better option to talk about applications. Sorry if this is unnecessary complication to the already complicated discussion, but I have to sort of say this. Yeah, this is Watson. As far as the definitions, one of the things that keeps coming up is the grouping of microservices or if you want to say containers or pods or VMs or whatever, and then the a single microservice pod or whatever. And so within cloud native, a group of microservices is an application. So within the Epidocs, it looks like there's a group of a group of a functionality can be a network function. So that's some one point of confusion. Yeah, I'd agree with that. And I think the what I tried to add in for one dot one and one of the others, I think was was to use the link it to the definition of a virtualized network function component which is the bit in Etsy, which decomposes that higher level function into those multiple bits of functionality potentially. Right. And so with a kind of cloud native network function, that cloud native network function component could be a microservice. Right. That's where the direction on the all four and all five we're going with pointing out there's a concept of component in Etsy. All right. And then hit undo or something and get the stuff back just from hitting undo. It might not look very nice. But if you if you click on see new changes at the top there, you'll be able to see what happened. It'll be crossed out, but you'll be able to read it. And I can't get to the version history. And I'm not saying that new changes. I don't know. I don't know who's sharing, but in seeing new changes at the top, it's grayed out next to help. That should let you see if we scroll down what the what was deleted. It's straight straight through, but you'll still be able to see the words. Oh, that'll work. Can you highlight those and we drop them back in? Thank you, listening. All right. One more time. You got to do it twice. It did a strike through and then you can do the end strike through after. OK, there we go. So I think that all one was trying to. Expand on what was in the one of the other white papers to have the Etsy. Definition that it was added. Yeah, and. It was calling out the specific terms from the Etsy definitions that were useful rather than just saying as per, you know, whatever the document reference was. So and then. I don't know if we want to break down these. What it doesn't have in all one is a. It doesn't define what well-defined external interfaces or well-defined functional behavior is. If those have definitions somewhere else. They leave it vague enough that that could be anything. What is what is a well-defined external interface? And this could I think there was someone mentioned benefits. As as a one way to look at things. The problem with having benefits is as your as your part of your definitions. It doesn't it leaves it open to interpretation. So then you could say if you want segregation, well, you could do segregation in many different ways. So that that would be the only thing there and in any case, this is just an expansion, I think, of the from the other white paper to make sure and include those parts. It doesn't include some of the things that folks have mentioned like the cloud native network components. It does mention part of the virtual network function, but then points over and I think all one dot one is trying to. Add in part of the cloud native. Definition or what what is that main out of the preambles and principles document and expand a little bit on the Etsy definition, it looks like. Yeah, so it's all dot one one dot one. Sorry, there was a comment on alt one that the CNCF cloud native definition wasn't wasn't kind of detailed enough about what we'd want to see from a cloud native network function. And so I added in that that bit about immutable infrastructure from the cloud native principles document that was being written. Because I felt it called out what we were looking for from a. You know, in terms of guidance for the software vendors, if you like. But the rest of it was the same. More or less sounds good. And can. Can you scroll down listening to all one dot two? So this one I was trying to build on this based on I think the alt four and five. I added this one in. So it's taking some of those ideas are the direction of all one dot one. And then linking it a little bit more towards the cloud native side. So this is mainly to do a mapping. So what are we looking at for folks that are doing cloud native already that are interested in? The net cloud native network functions. What would that mean? And then if you're going the other way, trying to say, how do we take something that we understand from the NFV world and move towards cloud native? So this was talked about a little bit earlier. It seems like a cloud native network function. If if we take actually, let me step over, if we take a virtual network function, it seems like a virtual network function is a cloud native or could be an application. And so a cloud native network function. Could be a cloud native application. So it's it's a specifically an application that focuses on the network domain. And that's that has a good definition. And and then this is saying it's similar to a virtual network function. And it's specifically saying similar because I think there's going to be pieces maybe like the virtualized and the virtualized hardware abstraction are probably not going to be part of a cloud native network function. That's going to be there's going to be something pushed out. So it won't actually be in the the the network function itself. That would be taken out in a virtual network function. It needs to know how to work with it. But that's potentially not going to be part of it. It may be part of it, but that's why I'm saying it's similar versus the same. And and then Reeves, the parts that you haven't heard about the immutable infrastructure, declarative APIs. What I added in was composed of microservices to your one dot one. I think that's important. It wouldn't be well and proposing that a cloud native application is composed of microservices. That's that's already a defined definition of what those applications are. So if a virtual network function is an application, then it seems like a cloud native network function would be an application and you would follow the standards. And then if we have that, if it's composed of microservices and other parts that allow it to be an application, will micro services are very similar to the virtualized network function components that are defined in Etsy. So now you have a mapping on both the application level, the network function and the components that it's built from. And I think that would allow people that are doing application level, but the development and deployment to know on both sides, if you're familiar with the networking world or the cloud native platforms, what you want to do. And then I think the rest of it is as one dot one. So that goes down to the saying what Etsy defines a virtual network function as and then going on from there. But what's not defined in here, but we could add, probably should be breaking down this as a paragraph would be what are virtual network function components? I think going back to one of your earlier comments as well about what is a well-defined external interface and well-defined functional behavior, we could add that they are defined by industry standard specifications. You know, Thomas mentioned 3GPP, for example. You know, that that I think that's how I would read it in that they are defined by an industry specification. And I think that would be a worthwhile addition just to quantify a little bit what we are referring to. Otherwise, I think that's a really good definition of the addition of similar and composed of microservices makes it more sense. And to me, I think clarifying the VNFC, mapping it out, I think makes perfect sense. I think the VNFC mapping would be to more of a part within a microservice. I think if you add it, I think that tells the story very clearly. So is do we want to add in the concept of having to tie the mechanism to talk to a CNF to a set of specifications? Because this is something that will probably happen organically, organically anyways through the market. One of the things that I want to be a bit careful with is that we don't we don't deny groups who have more esoteric needs or want to or want to experiment so they can try to push the the boundary further. Like perhaps what we could do is say for the purposes of certification or so on, then yeah, you absolutely must use a well-defined mechanism. It seems like we're mixing implementation along with the definitions for the the standards we're talking about where we're saying those standards have a definition for the well-defined external interfaces, for instance, and being able to point to a specific standard that we think is important. For example, I think we should make sure it is example. Yeah, that definitely has just an example because otherwise I think Frederick's concern is is met. From the standpoint of saying you're from a virtual network function, we're saying that those standards, like one of them, is you're going to use virtual hardware abstraction. So to be able to you're at some point, you're going to implement some type of connectivity to the network and hardware, but you're using some type of abstraction layer. And it seems like when you get down to the external interfaces and functional behavior, there's there's this edge between what the standard is and then how you're going to implement it in the virtual network function. I don't I don't know how far we need to go talking about implementation versus saying any type of behavior should be implemented following cloud native standards. If if you're if you have a standard that requires you to, let's say that maybe of either the functional behavior or the interface from the standard that you're wanting to integrate with would not allow you to do it in a cloud native way. I think that should we shouldn't make the definition of a CNF limited to a standard that's not cloud native. Instead, I think we should say this network function that's implementing that functionality that's required in the industry because it's already out there is not cloud native. And I think that would be OK. So we could say we have. Ninety five percent of our network functions are now cloud native. This set, which are critical to the business, are not cloud native. And here are the reasons why. And then you work on the standards to allow them to be implemented, if possible. But what we're talking about is a set of principles. And deaf and will not print definitions, but principles and they. That you can follow that will give some benefits. If the benefits do not meet your needs, then you select something else. What we're saying is if you follow the principles and they give the benefits, then someone should be able to say, I've followed all the criteria and meet those, the. What's required to get the benefits based on definitions. So that was one thing that that, you know, I I couldn't really place I couldn't really place. And then you refer to a standard, which is not cloud native. Which standard did you have in mind? Just curious, I'm you referring to three GPP or or or Etsy NFV? When you said it's a non cloud native standard. Well, I don't know why they're one of those. Well, I'll respond to it. Frederick, and then you can add. What what I was saying was if there's a standard out there. So this goes with. We need to be able to integrate with Brown. Phil, and there could be things I've done a lot of work with stuff that's legacy, you can have stuff that's been running for 20 plus years. And you need to keep integrations. So whatever it is, I'm not saying that three GPP is is legacy. What I'm saying is if there's something in there that you have a definition for some interface because it's something that's running and you can't implement that in a cloud native way, that's OK. It just happens to be one of one of the one particular application that you're going to implement that's not going to be able to follow all the standards. That's OK. Whatever it is. What what I'm saying is the cloud native network function definition should focus on being cloud. It should follow all the principles and definitions to be cloud native. And then and being able to implement as much of the existing applications that are needed in in the NFE world without. Without it being without compromising what it means to be cloud native. Sure. So let's say let's say if there is a standard that talks about an interface between two network functions that require, you know, layer two functionality. Would you claim that that that is something that is not cloud native? And it's not something that should be implemented in a cloud native way. Absolutely not on that particular example. That that example can be cloud native in my mind. I mean, that's specifically what stuff like network service mesh and other, you know, many other projects and are trying to solve how to do these layer two things in a cloud native way. I think that you can do all of if we say OSI layers in a cloud native way. If you go into very specific examples, I'm sure that we could go through and find something that we say this is not possible to do in a cloud native way. And you don't have to think about networking. There's enterprise applications and many other applications that you could say the way you've designed this does not allow you to build a cloud native version. You'd have to redesign it completely, which is OK. Not all principles are going to be beneficial to solve all problems. And this is Watson. Here's one thing also to keep in mind with the definition of cloud native microservices and so on and so forth. Even in this paper, if we were to say, you know, put with definition, we want here, if you have a monolith and then you say that it's cloud native communities just going to say, no, it's not regardless of what we put here. So there are certain certain patterns that we might consider anti pattern. And, you know, it's just we're not going to be fooling anyone. So it's something to be aware of. So some of the charge is going to be that some of these things that are ported over our monoliths and not microservices or not, they don't use microservices. I think I think fundamentally these standards that we're discussing very, very seldom define something that dictates a certain way of implementing a network function. So whether it's implemented as a network function or as a million of modules which are microservices, these questions are typically, you know, orthogonal to what these standards define, which is basically what is the protocol we are using for communicating and what are the state transition diagrams and so on that we need to adhere to. So I see in many cases that when it comes to telco standards, they sort of ignore whether the implementation fulfills the cloud native criteria or cloud native definition or not. They just look at how these functions communicate through their APIs or through their interfaces. So I don't see anything wrong here with the approach. I just wanted to understand what when you said, you know, non-cloud native standards, how do you mean that? Well, can I have a little bit on this particular one? Yeah, go ahead, Frederick. Yeah, so part of what I would, the reason I brought that particular thing up in the first place was first worst-case scenario, and I don't think anyone's doing this year, anymore is we don't we don't say it must be the host user, it must be Mehmet or, you know, here's the Blast, the Blast list. I in these standards, I'm I'm glad to hear like the other various standards don't push into the implementation to to that degree as well. So for me, that's that's a very good sign. The one thing that I was thinking of is we need to make sure that there's some form of flexibility for for operators to be able to choose what what they want within their their infrastructures and also the flexibility for vendors to pick and choose things that that work for them. And I want to be a little bit careful because we we we say that industry best best standards like that. You know, which standards are we talking about? Which ones are going to be the ones that are Blast or or not? Like for me, that that could be a best practice that we drive for saying we highly recommend you use industry, well known standards and and so on. But but I also want to be careful with not creating a definition that becomes dependent on an external on an external standard. And my preference would be that we that we have part of the kind of native path. The you say what you're high. You say how you communicate with the outside world. Like you can say I speak Memev, I speak Vihl's user, I speak HROV directly, DBDK or so on. And you specify with payload that you have, like my payload is going to be IP or Ethernet or MPLS or something else. And that way that you then give you're not created a declarative setup that allows your orchestrator to pair things together. You give it enough context that they can start pairing things or tell you when things will work while at the same time providing the flexibility for for future innovation and and for operators to be able to to standardize if they if they choose to do so as well. From the standpoint of implementation, when it comes down to whether it's vendors trying to help build things or the operators and either defining or the platforms that are being created, all of it, whoever is working on this. For all of the brownfield, folks are going to want to integrate with existing standards from wherever the standard bodies so that they can but utilize existing infrastructure, integrate with other groups. And I don't think that defining having a declarative manner for saying, here's what we want. They either a network function or platform is Frederick saying, I don't think that stops us from using existing standards. What the suggestion is is we don't have those external standards as part of the definition of a cloud native network function. Instead, we say, here's how a cloud native network function should behave. And here's how we expect it to be developed and the platform support that's expected. And you can talk about all the different layers, which are in other areas, not in the center. And then as far as implementation, you're saying, when you're following these principles, we want to be able to support existing standards. Well, that's that's would be developing an application to meet a specific standard. So I don't think there's anything that we're suggesting to define being cloud native that would say you're not able to meet a majority of the standards. I just put it as a note that there could be specific example application or I'll say, virtual network function or a NFV platform component that you wouldn't be able to implement in a way that someone would recognize it in a cloud native way. But as far as following, if we had a cloud native definition of a CNF that's fully cloud native and not saying it's using it's it's using an external standard and it must have those interfaces, then you're still open to implementing this doesn't block us in. And that seems like when you would say, what's an example of a cloud native 5G session border controller? Well, that's probably something that we could have an example section. How would you create that as a cloud native? And you'd probably break that down and say, here's how it could look. So it's not stopping either integration or implementation of those standards. It's as Frederick said, we're not locking ourselves into expanding. Someone could build a brand new Greenfield platform that doesn't maybe use this completely different protocols that gives you all the same benefits and and goals that that a network operator may want without using existing standards or they can integrate either way. OK, I think we're going to have a particular point then. So I think the plan is with this definition and we're coming up on the hour and what we're going to do here. We were going to schedule some follow up calls. Ideally have have it available for some of the folks that are in Asia Pacific that weren't able to join and give them a time to review. This call is recorded, so hopefully that can be sent out and folks can review, listen to these and add comments. We'll try to have the original one and all one back all one and all one dot one, sorry, which had comments and folks can add to this and and then get some, I guess, more feedback from hopefully more operators that are that are out from what I'm hearing it. It sounds like the. Part that is agreed is or maybe moving towards agreement is a cloud native network function. Seems to be we could say that it is an application, a cloud native application. I think there's agreement on that and it's based on components or pieces. And maybe we can say that's microservices, but there's I think we're saying. It's a the application level versus a CNF is a microservice. At least I'm hearing that there's more movement towards that. I think that would be all four if you look at the definitions to simplify it versus all three. So it's a network function is like a cloud native application, which is similar to a virtual network function. And that's made of a microservices, which are similar to virtualized network function components. And not to say we're going to use all four, but it sounds like at least that keeps coming back up that I at least from the NFV world, a virtual network function is composed of many little parts. And that's similar to a cloud native application. Yeah, I agree with that. And then we. Seemed to be in agreement that there needs to be something talked about, what are some of the principles? Some of them are pointing out immutable infrastructure, declarative APIs, microservices, and that repeatable deployment process. That's one of them that keeps coming up in reference to the cloud native principles, specifically saying if it's a CNCF definitions and we're talking about cloud native, those may be moved into a later chapter. So it may not be a different document. And then some type of mapping to the Etsy standards for for understanding. So get having an understanding of for folks going one direction or another would be desired, however the wording is going to be. And then maybe something regarding being able to implement existing standards and how we word that whatever that that portion needs to be looked at. That's that interfaces and functional behavior. Does anyone have anything else at about four minutes? When are we looking to have that follow up call to review the definitions? Do we think? Well, I'm guessing before Kubecon. Yeah, before Kubecon, I posted some suggestions in the chat, I think Alex is the only one that responded and I can drop them in here. But we're kind of at the end of the call. So let me drop it right in here in the action items. Well, I'll put it right here in there. So I'll put them in the document. Thank you. So I was suggesting five a.m. Eastern for Tuesday, that's tomorrow. And that would be the coincide with the normal talk on music group third Monday call time. If that's unless that's too soon. But thinking that we don't have a lot of time for. We're going to get feedback if we're trying to get this done before Kubecon and publish. There's just not a lot of time that we could spread it out. Maybe, you know, it just depends on what's the main thing I would like is if people would promote to get eyes on this and get some feedback. One last one last thing as well, unrelated to the to the white paper. So I just want to make a quick announcement. So there's an edge computing world events coming going on in Mountain View in early mid December. And I'm part of the program committee to help load it up with with people on the networking track. And there's still a couple slots open and I want to make sure we get some cloud native talks in that particular path. So if you're in the Bay Area or are OK with traveling in that time period, then get a hold of me on Slack or LinkedIn. I'll see about carrying you up with the with the organizers. You know, I just want to talk that out as well before we break. Thanks, Fredrick, for bringing it up. This is an empty cell. I'll touch base with you guys. Yeah, it's a good one. Thanks. Perfect. Thanks. I think you're welcome, too. So my, my, thank you. So the thanks, Frederick. Maybe post to the TELPA Music Group Melling List and the Slack channel about that. Yeah, that's a great idea. I'll send that off as well. So I'm not hearing anything other suggestions for a follow up. I will say that the main reason I was doing tomorrow at five a.m. Eastern was I know that there's some conferences going in Shanghai and I think that it ends on Wednesday and I could see folks traveling to trying to hopefully get some of those folks to join. So they'd see this in their evening, but not midnight. So that would be good. I guess I'll post and if I put another post in the Slack channel, but we can schedule those, maybe get them on the calendar for 5 a.m. Eastern and 8 a.m. Pacific on Wednesday. So two more calls to get some feedback. I think that the meeting, thanks, Lucina for posting this. I think the meeting on November 18th, which is during KubeCon, probably be canceled unless someone else is going to run that. I'm not going to be on that call. I don't know how many people would be available. Does anyone want to volunteer to run that and keep it going on November 18th or we can just cancel the call? We'll post about that. Taylor, this is Taylor from CNCF. Do you want me to go ahead and cancel that off the calendar then? Please. Okay. Thanks. Can you follow up with me after the call regarding those other two meetings? For November 5th and 6th. Yeah. Yes. Thanks, folks.