 Okay, great. It's about five after so I think we can get started today. So thanks everybody for coming to the CNF working group meeting. There's not the meeting you're expected. Please feel free to jump out right now. The other thing this session is being recorded so just be aware if you come like voice something or say something on camera it will be on YouTube after this. So the link to the meeting notes are in the chat. Please feel free to add your name so we can know who's discussing things today. So the first thing I just want to point out again this is a new working group. So we do have an overview deck for anybody that's new today please feel free to jump in and join there. The second thing that I'd like to point out, or I guess on the overview, some of the people some people were on the CNCF telecom user group so the talk call right before this. And just in case you weren't on that. So there is is a difference between the two groups. The talk is going to be more an industry wide discussion on broader topics of challenges facing the industry and have more like white papers coming out of that. Well this group is kind of more focused on a narrow set of problems and trying to accomplish something more in the short term, and like have results around some specific issues outlined in our charter. So we will be kind of having a discussion about that later with the presentation from Frederick, and I believe he's on the call. So jumping off of that. If you haven't, if you're not in the CNF working group Slack channel on the CNCF Slack, you're really missing out. It's been extremely active over the past week. Thank you for everybody that's contributing to the discussion. I think there's been some great discussion there and I think kind of a summary of that will be presented in Frederick's proposal for the initial framework that we have so I think that discussion is really sparked some good ideas. The second part. Thank you to Swisscom and Deutsche telecom for adding their interest to the charter. Please feel free to add this to the charter to add your company as interested to the charter. Now why this is important is because as we're trying to set up like a formal governance under the CNCF we need to know who like the interested parties so then we when we go before the technical oversight committee we can show them that there are enough parties interested in this and who those parties are. So the technical oversight committee just wants to know who's interested in the different initiatives so if your company is interested. Please feel free to add your company as an interested party there. The next part is I'd like to just kind of point out like two changes in the GitHub repo that happened since our meeting last week. So to follow up on our conversation around should it be like conformance and requirements or best practices. We've changed a lot of the wording to best practices rather than saying conformance. And so thanks Taylor for making that change more details in the merge GitHub issue or GitHub pull request. And the second part is adding into the charter, providing a list of cloud native benefits as a best practice provides. So that's another thing has been added into the charter, right. This is an open source community so if there's anything that you'd like to add, please feel free to open a pull request or open an issue against the charter or anything in the repo. Taylor, do you want to talk a little bit about the tug and see enough working group roles. Let's all that you just added that. I don't think I added that. Okay, so somebody else said okay so. I mean, it's good. I mean, so that you kind of went over it at the start. And the main thing is, we want to both have a place where we can have more open discussions to cover as much and as many concerns that as providers and vendors and everybody in the top domain and Kubernetes can come together and. And then we also want to make sure that we have a place where people can come together and know that we're moving forward on on something that has been decided. So there's kind of two audiences and I think Daniel Burnay from Bel, Canada, and Vook from Dushetel com have both kind of talked about this and the CNF working group, the audience for the CNF and the CNF work group channel. The audience that we're looking at for the CNF working group are people that are already wanting to adopt cloud native and let's say Kubernetes based platforms and technologies and really looking to say, how can we most efficiently use these, how do we, we either already understand or lack a lot of these philosophies and methodologies, or we're starting to want and we're starting to want to adopt more so you could be anywhere along the transition the bell curve for adoption, but those that are already bought in. And then the telcom user group would be the place where we want to have discussions about things that may not be covered yet maybe it's something that isn't covered yet in Kubernetes but it's a need within the telco industry, or maybe there's so many options that there hasn't really been consensus within the community about those things, or alternatives that just maybe don't even look like anything yet. So that's really what the telcom user groups about in the presentation today for those that didn't see it. One of the main items was something that Jeffrey silence was talking about the telco drivers and concerns so we're hoping to go ahead and and re surface a white paper that he started out last year and gather that information so this is a lot of the questions that people have put in what are our motivations why are we putting stuff about Kubernetes best practices for CNS like why are we talking about this if we don't know the motivations. That's why we put the little benefits in the scope for the charter we added that, but we don't want it to be the main focus within the CNF work group we're trying to say is this relevant at all the CNF working group is actually the place where people go we know it's relevant help us to actually find the best ways to utilize these. So this specific network function that we're using and we're trying to figure out the best way that we can manage it the life cycle management and those sort of things in the telcom user group though we can go deep into those drivers and all the things that we can utilize and source that information. As it becomes available into the working the CNF working group as well as other groups so I'm the test suite itself I mean, being able to have more context, the CNF test but another initiative can utilize any of those as well as other groups like an etiquette with the reference architecture and reference implementation that they're doing on Kubernetes. And so I'm hope I hope that that provides like some context, and we want to make sure there's a place for the questions and comments and discussions that have been coming up specifically in the CNF work group but same. So go out of scope. Yeah, thanks. I'd like to open for feedback to Bill and try to see if anyone has any thoughts or discussions around this like roles and scope that we're talking about for the CNF working group. And you may bill want to even bring up the charter itself. And for those who haven't looked at it lately so that we can see what is the new version based on all the different updates, but if I'd like to get feedback if people spots and stuff on. There's an understanding on what are we focusing on first and where can we talk about things that will help the telco community. Hi Taylor, it's Tom here. Hey Tom. I think, looking at the slack over the past few days, the biggest query that seems to be in people's minds is where do we write down the business requirements that's driving all three communities. I think it would be, it would be good if there's a kind of an agreement understanding, whatever, as to which of the three communities that level of thing needs to land. Because I think it would, it wouldn't be suboptimal to try and write it down in each community. And so it'd be interesting to get people's opinion on which community that would be a good place to source that information. All right. Well, I guess there's there's kind of two parts to it that I'm saying, probably the telcom user group is a place to have business requirements that are available for any different group or community including those outside of CNCF. And make it available to anybody. So telco business requirements. And then specifically for the CNF working group, if you look at the best practice proposals, which thanks Bill for bringing them up. So the best practice proposals, one of the things that's in the template what we're expecting is for people to provide references and motivation behind stuff. So if you if you're proposing here is a best practice that we think a CNF would be good to follow. That's all we're saying with these best practices. They're not going to apply to every CNF because not everything is going to be implementable. But for the ones that are here's ideally a way that the telco application being developed, can best utilize and consume the capabilities and services within Kubernetes. And one of the things that they should have in the proposal is what are the underlying business driver. And it may be that so this is the one part that may be a little off from what you were saying Tom, ideally it would be in one place. I don't think that's ever going to fully be the case, especially distributed and everything else group and what could happen though is you may end up where someone is working on a proposal. And they're thinking about existing application and starting to talk about how would this be done, following best practices for Kubernetes like a Kubernetes native. And they may come up with that business requirement and they write it in maybe they're talking to you Tom and they're like, working it out and they're like here is the background business requirement. I would hope that at that point, we could also push it back to the tag, and then maybe it makes it to a larger source. And the whenever you're reading this proposal and you're looking here and going okay, here's here's the best practice, and it has this requirement and then it says, go see here for more details. Some of them may have a massive amount of context around a business requirement others could be short. That's kind of how I'm seeing it. One thing I want to like throw into the mix to is the vast majority of us and we've talked about it from like the, you know, CSP perspective right like telcos cable providers, internet service providers. I think long term, just network operators in general, are going to care about this stuff. So my personal opinion is is within the tug, I would like people like you, Bernier, etc to help me get telco specific business requirements that we would then push into this group and say, this is what we're hoping to get out of here because what I'm worried about is if we were to build them say in here. Then it's going to become which we've seen it, we've been really notoriously bad at doing this in LFN is the telcos come in and we shove our paradigm down everybody's throat and then the Bank of the Americas of the world you know the disney's the coax that like run massive, massive networks are trying to, you know, figure stuff out. Additionally, to it's been brought up by multiple people, myself included that we're hoping to get some of the big public cloud providers in here, and I would really like to see some of their requirements pop up into some of these individual proposals. I know I've been the biggest one harping on we need to design to requirements I want requirements and I specifically the selfish part of me wants telco cable specific requirements. So it doesn't necessarily have to be the tug but I would like us as providers to go into one of the forums that specifically geared towards us for us to capture our requirements and then push those into some of these you know more cross organizational cross domain teams. So that way our voices heard, but we're also not drowning out maybe some of the good ideas that would come from like the pure app dev side the public cloud side the enterprise side etc. So guys, this is Robbie. So I think requirement may be an overused term. So I don't understand that the comments can come from the CNCF to use a group. I know there are some requirements coming from the CNTT before and there's certainly a few But maybe what we really need here is kind of principles that we know are very important and maybe trying to understand what are the principal foundations that will make this work important not necessarily frame it as a business requirement or a technical requirement. Certainly, what do you consider a successful program here? What are the principles that we live by? If you've got, I mean, that is, you might just be right that requirement is an overused word but you know a requirement is theoretically here a thing that you need in order to be successful. So, you know what you're calling a principle in traditional software engineering we would call a requirement I think. The big thing is is I want to know what we're using to measure stuff. If we go out and make the bold claim as a group of collaborators that this is a best practice. How did we validate and measure that best practice to say it is actually better than what we had before that it does do something that we needed to do and that we're not just doing it because we're a bunch of nerds who like to geek out on, you know, cool Linux deck. So, so this is sort of so isn't that something which CNPT is doing. So in RA2, they're defining their requirement in RI2 they're implementing them and RC2, they're actually testing for conformance against these requirements. So, so all of that is being discussed so and and they do work with CNCF Doug. So why do we need to redo all of that here why not take it work in conjunction with CNPT RA2 and and and see what's missing what and that's strictly being driven by telcos. And why not bring other players like you mentioned Jeff, the cloud providers and the Bank of Americas and whatnot in there and see look at it what what what pieces are missing. And rather than redoing all of that here, take what's there, and then figure it out what's missing and what we need to do here so rather than resetting everything. I mean, this is crazy that every other year or every year we just fork off a new group and just for fun of it we start all over again. There's no point in doing that. And so, so why not we look at it has is everybody here familiar with CNPT RA2 and have they looked at it what requirements are there and also the RM the resource management resource modeling, which is which is going on in CNPT, which is defining it at an abstract level. Perhaps those are the things to be looked at to start with. So I think I agree we should, we should look at them. So certainly from my point of view, RA2, I've been trying to keep very focused on the requirements relating to the interfaces that an application needs from the infrastructure, which I think is quite a functional set of requirements, whereas I think when we're talking about business requirements we're likely to be talking more non functional stuff which I've purposefully not been capturing in RA2. Because that wasn't the scope of CNPT at the start. Let me try to address this directly because this has come up several times before, and it's also, it's not just if we look at the CNPT or an etiquette work. It's also other groups this can come up again so why are we creating something there. That's the question. And I wish Daniel was on here because he said this I mentioned again I don't think you saw this book you've kind of mentioned this. The audience that the CNF working group is focused on and to some extent the telecom music group is different. It's a different audience. So there's not a one size fit all elephant doesn't do every have something that fits everything. CNCF doesn't have something there's other groups out there that are that are doing stuff outside of life as well, but CNCF is focused on a specific type of audience, those that are wanting to adopt the philosophies and methodologies that are behind the alternative. So, and specifically, the ones if you look at CNCF or cell phone, see it CNCF is about showing and highlighting various options, you could think of it more all the cart you can go in and say here's how they fit together and try to promote interoperability between them, but they're not being opinionated. LFN is for an audience that says we need something we want prefer something that's opinionated. We want something also that's maybe a little bit. It's going to be more focused on supporting integration between different groups outside and philosophies. So if you look at RITU and the RITU and all everything designed from that it's supposed to work with specific opinions on how things should should be operated and work in production. And that's good for the audiences that want that, then you can go there and you have that. That's not going to be what you would look at if something came out of a totally different group out of LF. You have other groups that are coming up with other platforms and ideas which may be very useful for a service provider and vendors may say this fits our model. So the CNCF and specifically the CNF working group is trying to provide something that's following the philosophies that are within the Kubernetes and cloud native community and that fits the best, the most efficiently to Kubernetes. That's not going to be a match to what comes out of CNTT. They are two options, by the way. They are two options because there are two different audiences that they're both trying to talk to. Can I take that point up about audiences a second? Ian, before you do that, let's let Vook respond because I've called him out twice and I'd like for him to be able to comment since I was appointing to something he's talked about in Slack. I am struggling a bit to reconcile the things between the starting point where we discussed about the conformance or idea of achieving certain framework of conformance testing where we can prove different types of CNF if they are conformant to something that we are hopefully about to agree. As a cloud native and the discussion with the best practices. So let's say the biggest interest or biggest value that we could see out of such working group that is focused on really making things fit to Kubernetes or creating a set of practices and even recommendations for the conformance. That would make a CNF work in a Kubernetes in a native, unopinionated or very little opinionated Kubernetes as a value for us. That would be something where we hoped, okay, as a telecom user who is deploying their own upstream based Kubernetes. We will not be in a constant struggle with different vendors who are preparing opinionated setups. If you follow what I want to say. So, if we are now moving away from that. I see the discussions in a different Linux foundation working groups, simply like, as Taylor said, to opinionate and we were hoping something that could be a conformance against the generic Kubernetes cloud native platform. So I don't know how we can reconcile these two things here. I think that this is Frederick, but by the way, so I think part of what we need to look at as well as separate out some of the some of the layers because there's the concept like from what actor you're coming from what what type of thing that you want to do. So, if you're a consumer you're not telecom but you're, you're a consumer of this world. You're likely not going to care about like is it a CNF or the VNF you care that there's an API that it meets certain both functional and non functional requirements. And you can call it and consume it in an in an explicit way as the operator of this. You care very much about how this thing is is is ran and operated and one of the problems that's been expressed by multiple by multiple operators is that you have a very rich set of things underneath of you that you need to control and manage and how do you produce this environment is that you're not, you're minimizing as much complexity and trying to give something that's a little bit more uniform to to basically run a command and control over your over your infrastructure. So when, if you're the vendor, there's two types at least two types of vendors, major ones that we've seen the first one is from an infrastructure provider, how do I build an infrastructure that you can run these things on, following a common set of roles, which is where you have we focused on, among others. And the final portion on that is like your vendor of a CNF. How do you deploy into into a CNF infrastructure environment. And so part of the problem that we ran into is that we've had. We've tried to focus on too much in many of these groups rather than saying okay what are some of these things that that's core and then how do we get these communities to interact with each other, because then what ends up happening is that whoever has a lattice voice in. If in the larger community ends up being the primary speaker at the expense at the expense of others so by providing a smaller forum that we can say okay like what are the best practices of running in a, in a Kubernetes environment, and that doesn't mean that open stack is any less important or PNF is any less important. We still have to work out how to integrate all these things together, but for the purposes of this particular group. I think the the initial focus should be very tight and saying how do we, how do we get something to run in in Kubernetes how do we get something to, to say like this is how to how to, how to operate it in Kubernetes and then we'll work out and share this best practices and it doesn't mean that you have to follow these in these rules exactly the market will decide what works and what doesn't what is important or not important, but to be able to say these are the best practices you need in order to, in order to move forward. So those are some of my thoughts that but I have certainly there. I know they'll be insufficient. So I'm hoping that others can help fill in or tell me where where I'm wrong as well. I'll just maybe two more minutes tried to get it or to throw it in the round a bit more pragmatic and then the round could decide is it something relevant for this working group or maybe just halfway relevant. The thing is, as we are working with the many, many application developers vendors of CNS, like Eric, so Nokia as my many years, Cisco's of the world, many other smaller one. We are getting now to situation that everybody has something like a cold cloud native or, let's say containerized applications network functions of different kinds. But each one has a has a caveat. Yeah, but the best way to run this platform or to this application is if you take Nokia, what they call cast containers a service or Kubernetes, essentially, or if you take Ericsson or if you take this one or if you take that one. And then as as an operator who runs dozens of network functions, you're facing the situation that you have a cloud native platform on one side, you have a huge scale that public cloud providers are achieving and having only one type of, let's say, parameterizable and configurable platform. And then you cannot use that because simply the CNS are using patterns and developments and practices that they tied you into certain very opinionated train, which I believe it's nothing that's efficient for the future. So what we are looking kind of to get is could we establish one basic foundation cloud native upstream based that every cloud native network function can be conformant to and can work better or worse. So this is a question of performance in that one generic cloud native platform. This is not what's happening and I don't know that the roots of that is it in the practices or is it in the, you know, different type of understanding what cloud native is, but it always goes in a very, very opinionated directions. And then you can have a cloud native platform per network function, probably or per network function vendor in order to make it work. So that's what I wanted to try to throw as a business problem as a business requirement. We want to have a one platform that is, you know, cloud native enough, flexible enough to cover multiple network functions running on the same. So, but I think that's because you're getting exactly what you ask for, but you're not asking for what you want. Cloud native, we're using it to mean a lot of different things. But applications are cloud native platforms are not cloud native. These applications are, you know, designed to be run on a cloud in that sense, they're cloud native, and you're asking them to, you know, apply or align with a bunch of rules like, for instance, immutability, which they absolutely do, which is what your vendors are telling you. But what you actually want is something that's consumable in your DevOps environment, that aspect of cloud native, the thing that you see from the outside of the CNF, not the, are these containers designed and run by, you know, orchestrated in a way that would suggest they're cloud native, because ultimately that doesn't matter to you so much. And that says that you can consume the result that it aligns with continuous testing and then automatic deployment. At no point will you find a cloud native definition that says must deploy with one API call or one click, although it's a perfectly reasonable thing to want and ask for. You know, strongly aligned with cloud native principles, but I think that is what you want, if I understand what you're saying and that's why I keep saying I want to bring this back to audiences because we want to assign why we're doing something to a group that cares. And a lot of cloud native principles are designed so that the group that cares is the developer of an application because kubernetes itself is very application developer centric it's trying to make applications easy to develop, because a lot of people use kubernetes develop applications that they then run. That's not the model we're on here. We're on a model here where we've got service providers in particular are most focused I'm not saying that exclusively focused but then most focused on operating an environment including CNF and on making sure those CNFs can be architected to within their network. The development side of things is more on the vendor side of things, not exclusively again, but vendors are more interested in making sure that cloud native development principles which typically apply to application developers are helping them, and that they can police their development teams to ensure that where a cloud native development principle is significant enough they want to ensure it's present. So, the thing about audiences I think is that it's not just one sided, we have actually about three maybe four audiences if you consider what the platform must provide to allow a CNF to get its job done. And if we have those four audiences are we representing all of them properly. And, or alternatively if we're saying this is done in the tug, or if we're saying this has been done in the CNCF do either of the sets of requirements there have a justification that says, this is the audience that cares and this is why they care. You know, one other, one other point of context as well is that we have to realize that by running on top of Kubernetes and part of the reason for the best practices here is also to determine what gaps are there in running in this space and we have to see the ecosystem at large so Kubernetes does not run in a vacuum it's certainly not a telecom only thing so the majority of these cases of Kubernetes is relatively small clusters, the small to medium size clusters in the enterprise space. So any, any gaps that we find any changes we have to be thoughtful of those communities because if we're not then any proposals we make are going to be squashed. And so, in the process of navigating that we also have this larger ecosystem we need to make sure that we that we navigate so not every audience that we talk about here is going to be the sole audience that we need to to think and care about. I think we're starting to now potentially overuse the word audience. But I don't know what should be there instead or an additional one. Well, if you are talking agile the term we're looking for here is actor. Okay, so Frederick you you had some slides about that uses actor to so the actors that sounds fine. And then whether the other part is within the actors or the roles, those type of people the personas whatever you're going to then have people that have maybe different preferences so you can have someone that's on an ops team, but they don't care anything at all about cloud native maybe they're doing embedded software, or I don't know whatever it is you're doing an ops team on a submarine and not following Agile or DevOps they don't care. So there's the persona or actor, and then what's important to narrow down is, what is the CNF working group it's not, or the tag or what is it in CNCF, or elephant or any of those, it's going to be a subset of those so the within the that, at least within CNCF telecom, both the platform and applications running on it and there is a there is a blur, as you've said Ian because kubernetes is application centric, but the, the philosophies behind what's cloud native are going all the way to the stack. So, within, within the greater telecom CNCF community. There's, we care from, you could say from hardware all the way up. It doesn't mean it's always covered at all. There can be gaps all over, but you care about how they could be layered for sure from the what we the kubernetes infra and each layer up above as they integrate within the CNF working group that the comments earlier were about, how do we have something. And Frederick you were talking a little bit about this, how do we move something forward that we do agree to for that subset of actors that say we want something we've we've decided we do want to utilize kubernetes we're not trying to bit bought in. Those discussions are happening in the tiger somewhere else. We are now at a point where we're trying to see how do we best utilize these for our telco concerns, as a ops team as a developer as whatever that you know you you have four different audiences and and I think are actors. And Frederick you have a few as well, whatever you are. What we're talking about is those actors that actually want to try to utilize kubernetes, you could say kubernetes native as an implementation of methodologies and principles that are more general. That's what we're currently looking at is a focus point. And it could, I think it will expand beyond application and probably get into infrastructure within the CNF work group, but wanting a starting point so that we can focus. It doesn't mean we don't need the drivers doesn't mean that we don't want the general purpose. What are those things behind it. It's those can happen concurrently. It's, it would be, what do you want to focus on. And right now we're saying, let's, within those CNF working group let's focus on a more narrow specific. Yeah, so I think. No, so I think Frederick has a presentation that'll, as Jeffrey said, I think we're like spiraling a little bit that'll help us like focus the discussion so Frederick are you on the on the call and we'll be willing to share the slides that you prepped. Sure. So, I'll keep it short. Sure, I will keep it short as well. So, my, the thing I wanted to focus on specifically is if we have the Charter. What is a, what is a model that can that we can build underneath of that Charter. And what can we carve out we want to start off with something that's that's relatively small. I mean, it's the only thing we focus on but it's the first small thing that I propose that we, that we try to focus on. And so back on to the problem scope we spoken a lot about this I won't spend too much time. I, but I will say this earlier models focus primarily on what is a cloud native what does it mean to be a cloud native network function. Maybe these are very important questions to answer and this is likely the wrong forum. This is something that we want to bring into the telecom user group and other forums. We do want to take into consideration on whether we are following cloud native to the best of our understanding that there's no single definition that's that's really ever settled. In time, we don't want to spiral down the philosophical example of or the philosophical question of what it what it's called native. Instead, I think we should look at it's at a few questions what are we really trying to do with a focus on on value on value there. And also the question is value value for who and these are things that we can explore as we move forward. A couple straw man things to consider and that is, there's there's a push for automation. The automation means that you're able to do things like auto healing you're able to to auto provision auto replace things. That means that you can potentially ties into other things like composability and reducing vendor lock in, where you could have something like maybe you're running a firewall from a certain vendor it could be like Cisco or Apollo or you want to you want to change to the other. What what is this, what are we thinking about scalability in fact the scalability even an issue is that's what we want to focus focus on and try to tie these down to values now the assumption that I think we're making here. What we think about scalability is that most of these costs are driven by optics. This is something very important to consider as well because if the cost or optics, then we're going to take a specific approach but if most of the costs we're trying to reduce our we have a very different set of conversations that we need to have. And so one of the things to ask yourself is, is, are we focusing on the right things from a financial perspective. And how do we reduce complexity in the running infrastructure and value for who because in the best case, the value chain benefits everyone. It should not be a push and pull against like operator versus vendor versus company that comes in who's contracted to manage. It needs to be something that is that is that the value add for for all in for the best chance for these efforts to succeed and if we're not seeing value for everyone. Then we really should ask, what can we do to to bring that in. But again, many of these questions are not for here but they're things to consider because they can derail such such efforts. So let's separate out. How do I consume from the operational details. And so a few actors that we can look at and these these may be too many or too little things. So these are more, some of the things I have to look at but we have the group is going to consume it. So the CFNF vendor, the CFNF operator again repeat those same things on the CFNF infra side, who provides the infra who operates the infra. And what what other actors are there as well and there's certainly some like there'll be some in terms of perhaps storage or others that we can eventually consider but but I think if we focus on on these ones as an initial set, then that may help us form some of our some of our questions. And the, the thing that I think we should focus as a community these are all important questions but I think the one we should focus on the community primarily is around what is, what does it mean to be a CFNF in Kubernetes. How do I, how do I build and deploy something what are best practices and the reason I'm not saying the others are not important questions but very specifically. So we start, we start here with informed by how do I, how do I operate this particular system. And this gives us the gives us something small that we can, that we can produce in a relatively short amount of time to help us gain that momentum because that this is this is what I tell my, my kid who is around as a young teenager and one of the things that she that's that I tell her is that the reason that you're doing all of your things here for school even though it's easy is to develop good work habits to develop good. And what we need to develop now as good community habits so that when we get into the harder problems. We're in this process of collaboration and with a very pragmatic view on how do we solve the problem. We're all going to have different opinions so we need to find a framework that allows us to deviate in those particular opinions let the market work things out, and, and then converge. In terms. So, so what I propose is that we follow a different, we try solving a different problems where designing a CNF is about designing principles, and that's a very important problem, but what I propose is that we focus on, what does it mean to be cube native Kubernetes native, and what does it mean to build network function on top of Kubernetes with a very strong focus on best practices and focusing on something concrete that we can look and test and something that in the best case scenario we're able to attest properties about it with the with the idea of servicing gaps and what and what can we improve providing this information as if you want to run a, if you want to run a CNF on Kubernetes, or a network function on Kubernetes to be more exact. These are the, these are the type of things that you may run into, you may need to expose certain pieces of hardware into it in this specific way. There's gaps around new alignment that are still being resolved. What can you do about it today. What do you, what do we expect for it to be able to do about it tomorrow, and to focus on best practices where, if you do a lift and shift these are the problems you're going to run into, if you, if you redesign your architecture to be horizontally scalable and to run in that container, then, and to provide information to Kubernetes so that they can orchestrate you. Then what, what benefits do you do you get from there and that does not mean the other approaches are invalid it just says this is how we do it in in Kubernetes. If you were to follow best practices, you can deviate at your, at your own risk, but at least, at least understand what the best practices are, and you can make an informed decision so that so you're not deviating out of, out of, out of not knowing and the purpose of this is to accelerate the, is to accelerate the space. And then in time we can expand this out like one of the big question is where do we draw the line between application orchestration versus infrastructure orchestration and I'll use an example enterprise example that if you install the test the test will run run the underlying pods for your system, but the test itself will actually run the orchestration of my SQL itself. So there's, there's an infrastructure versus application there's certain things that only the only the application can know how to do because we're application specific, and we have to define where that particular line is, and make it make it very clear, rather than saying Kubernetes orchestrate everything for you because it clearly won't. There's also questions in terms of what do we want to do about about multi multiple vendors on on the same infrastructure or type of infrastructure. So how do we, how do we set this thing up so they have a more uniform, sort of they're composable and that they're, they're consumable. Again, from a best practices perspective and it's not clear that there's a best practice it's that's fully surfaced yet so we may end up having to publish multiple things on the space, but and identify that that is a gap and and future things that we can work towards it. How do I ensure that they're compatible with each other, the witness test could be swap out one vendor for another with a vision towards zero touch automation. So, in many of these things we can push into the CNF test bed which already exists today. And that could be an initial focus to help codify and test some of the best practices. And so ensure that those are some of my some of the thoughts that I that I have I don't have anything else in these previous documents. But I want to put this as an as an initial framework. I have actually one comment. I think I agree with the conclusion few slides now the one thing that I wonder about since we are trying to define the actors, which is we have a slide who says number five I think, who are the actors. The problem I see here that we're trying to find you find the questions in their behalf. So maybe one approach we can do is once we define the actor. This ask them this ask them what is the main point that you would like us to solve. It might be worth doing a survey targeting only those actors that we're trying to target and ask them really what are the three points you find that we can help you solve. And this way actually we can create a roadmap for this group, but trying to really do it in a way that's serving the customer themselves, the audience for this work. I completely agree with that as well and I put, I wanted to have some continuity in the slides. But if, if you look at this like nobody really wants. It's like something like a sorry I'm sorry I'll be like you you want to from an implementation detail, but what the, what the customer really wants is a faster system or connection into a very specific system, or additional properties are being added in by their top of the switch. They don't really care about the actual mechanism itself. And so, so I think, like, how do I consume this particular thing versus some of the operational details that we, there's, there's things that we can that will need to to to work out on that. And I think when we start asking some of these types of questions like some of these type of differences or challenges to our assumptions will will pop out. And I think doing some type of a survey of each of these types of groups like if you're a CNF vendor, what, what, what are your, what are you trying to do like what is your value proposition why are you doing this. And what are your pain points that we can come up with a variety of different questions to, to ask to help us inform these type of these type of things. And as we, and these ones we should like the these some of these particular questions. There's different forms of this question depending on where you come from as well like if you're a CNF vendor and you're saying how do I consume the network versus you're a customer interesting how do I consume a network service. The two very, very different things even though it's the same question, even though it's the same words in this in the question. So I think, you know, the question that this slide provokes my mind is, is, does it make sense to perhaps have either different subgroups or have even different work groups. I think I think I keep thinking that we're, we've got to the point of audiences and actors we have different people who want different things out of this work group and that's why we keep getting stymied on the charter. And to me this slide really crystallizes that and I'm wondering if it might make more sense to to reformulate what exactly we're trying to do in these terms. Yeah, it may make sense. One of the things that, and this is one of the challenges that we have as well is in the past and I'll put it very bluntly because the risk, and please do not know no and be offended by this specific thing I want to be very clear because this is a very complex problem. When you look at the ratio of different groups that are here like we still don't have very many CNF vendors are still very small number very small number of them because that the, the infrastructure has not been ready for them to really build and deploy on there's been an increasing amount of doing things internally. And once to the service provider and operators there's only a very small number of them, but there's a very large number of vendors that are within the community and one of the problems that we that we run into is by throwing everyone into a single pot and saying okay have fun. And when you have an operator say something, and that the vendors don't necessarily agree with there's 20 vendors ready to rebut at that particular at that particular path and what ends up happening is that we scare away the operators in the process and it's a function of any particular group trying to, to be mean to them. It's just that everyone wants to be heard which is fully understood. And simultaneously, it's a function of the process. And so, rather than trying to blame people and say okay what can we do to fix the process to make sure that every of the major actor that's here gets a voice gets there. That's their opinions heard but at the same time we don't establish in a way that that overwhelms any any of the single actors, especially if those actors are, are smaller in number. And so that's something that we have to be very, very careful with in how we, how we organize the these particular these particular path and different, a different working set of subgroups could help with that, but there's also the risk that they become isolated if we take that approach we need to make sure that that we have somewhere that the work groups meet together on a regular basis to to describe the high level things are doing to make sure that that all parties are heard. I think you really did a good job at underlying the issue here because in the end we we list all these actors, but we're going to be dictating or guiding the CNF vendors and particularly in particular so they're a little bit cornered in the way we're, building things right now and if, if I joined the brainstorming maybe I have one suggestion of a way out of this is instead of thinking about the individual actors, the, maybe the scope of this work group can be specifically on integration. That is, not to tell anybody how to build a CNF, but rather to integrate all these various actors together and make sure that they have ways that the operator the vendor the platform provider that everybody can work together in the best possible way. Yeah, I was getting at when it came to, you know, you know we've sort of danced around the idea with best practices which is unfortunately not terribly concrete and hard to action. You know we you talked earlier about vendor lock in and as I, as I mentioned earlier in the in the chat you may not have seen it Fred because you were, you were presenting. The fun that what what what vendor lock in is really a proxy for is the challenge of integrating new things and the general challenge of interoperability. I think that's what what tall was just pointing at as well and also what the slide really gets that. And so I think that that tall is is right and and again I really think this slide crystallizes, you know what we're all really struggling with their their separate but related things that build on each other and fundamentally what it comes back to is, how do we integrate and how do we ensure interoperability. So we can, if we can focus on I think from that lens as opposed to, you know, how do you, you know, the specifics of how something is built or something like that, I think that that that gets to what everybody really needs here. So, we're so overt is there's something actionable you want to do. Yeah, yeah, so I want to make sure we close here and then we can. We'll, for sure, next week planning on having a call. I think the week after we may have to gap weeks, and then in January, we may go to twice a month type of call. The, I think the focus right now is going to be what you've presented the Frederick, and, and that's where the charter and everything else is kind of gone to. It's not that we may not expand later we can always adjust, but looking towards something more actual, I think is going to be easier if we have a narrower focus so this is going to be in a cube native or Kubernetes native is implementations of the cloud native. And I think as far as the test ability, that's going to be part of the proposals. So there's a, if, if anyone's interested in trying to help with this that would probably be one of the first areas trying to take an idea, like I posted one in zoom. About containers dropping root privileges which is actually part of the open shift guidelines. If you look at those guidelines. So, coming to something and then giving references on why this is a practice, how it can be testable, that's part of it. That's valuable to telcos that's where we want to center the discussions and then come back and go. Okay, is this actually something that is going to solve the telcos problem is this something that's going to benefit a vendor because they can get something to market faster whatever what what are the drivers all around that. That's where we want to start centering on putting forward those, whether it's a simple idea or something existing that you go and, and that's where we want to start at the docs. And, but I think otherwise we need to continue with this conversation maybe some new actually view some of the proposed best practices for next week. I'm going to maybe finish with one words that someone on the call early in this call said it was about and is that the best practice or the requirement or whatever you're looking at however when I call this. Does it is it worse or better. That's what we're talking about in this. Most of them. I don't think will be requirements. For, if you look at Jeffrey said the service providers are going to have different stacks. So they will come up with the requirements and work with each vendor. But that's going to be a selection hopefully if we have best practices are useful, they can select what they want all a car. What we're going to allow help is, are you doing something that's worse or better. Interoperability between the applications and interoperability for a certified Kubernetes platform or not. And I think that'll go with what you were saying Lisa and everyone else interoperability is is definitely a key point for Kubernetes. Thanks everyone. And we'll see you next week. Thanks. Excited. Thanks.