 Good morning Oliver. What's that? Air conditioning or is an energy company raising your temperature? Today we have it. We'll see about this afternoon and tomorrow. Right now we do. All right, cross the fingers. Yeah, if the AC was out but she had fans it might be all right. If you can't have electricity it's no good. Howdy all. Good morning. Are we talking about the weather? Yeah, weather and I guess it's Texas electrical stuff. We had tornadoes here in Chicago last night at the suburbs so yeah some people are out of electricity too. Wow. The suburbs in Chicago are pretty well with high density of people. Yeah, it's still in the Midwest so we're surrounded by planes but the the lake has a mediating effect so the city doesn't get it too bad but the weather is crazy all over. Here in Colorado we have had 99 weather continuously and today's right now at 60 degrees. Well that's why the best advice is never to leave your house and just continue working all the time. That is not the best advice. Maybe not. Be prepared for anything. So in Colorado we carry multiple layers of clothing even in the summer because you could have snowfall on July 4th. Yeah, we have a saying in Chicago about if you don't like the weather just wait. It's going to change a lot. Howdy folks. We'll get started in about two minutes at five after. Add any agenda items to the meeting notes and your name please. All right. The meeting notes have been posted in the Zoom chat. They're also in Slack and the calendar if you have it. It's listed on the CNCF public calendars of events and this call is recorded. If you didn't get the Zoom message I think everybody gets them now when you join these so it is recorded. We'll be posted to the CNCF YouTube channel. What do we have here? I guess one thing to note the July 5th meeting. So not next Monday but the Monday after is going to be canceled. It's a public holiday in the U.S. Upcoming events, KubeCon NA October, ONES and the CFP submissions closed yesterday, the 20th. If there's some interesting ones, I guess if you've had acceptance, I don't know if it's if those have come through for KubeCon then let people know we could post them on here ahead of time so that folks can be aware of this. And if there's some interesting stuff for ONES then keep those in mind for when they get, if you get accepted, let everybody know in the group. So right now it looks like all we have is some items from the pull request. I'm going to refresh that page. I don't see anything new there. No new discussion items. Does anyone have anything they want to add agenda today? Simon, are you here? Yes, I am. Cool. I think you had some changes on the stateful CNFPR that came through. Yeah and I made those over the weekend so I don't think there's any open issues left. I've made a change. Is it pancutch? Put a comment. Yeah which I updated which was the introduction of the basically the statement that he made about the glossary state being I just took the text as written and then changed the existing one to be types of states because that's basically what it was. Right. So I don't think there's any reason why. Sorry Simon but should the state still be defined? Well the whole point about the use case is talking about state and managing state. So if we don't introduce what state is then it makes it confusing if you don't agree. So the question is if you only make it types of state and not define state so we should define state right? Yeah and I have. Sorry I should have brought it up a little different. So I actually just expanded this, Pankai. This has been resolved. So we'll go and take a look at the changes. Would that be in the? Yeah it's at the top. Top of the glossary. You can see it. Okay. There's a statement that there's a state and that's the date that's the text that you wrote and I then changed the existing one to be types of state which and I added in a terminal state as a type of state. What type of states but yeah those are the ones I took from. Does that address what you were talking about Pankai? Yep yep thank you. Okay I don't think there's any other comments left over. So I guess we either need more people to review it or we accept it as it is and then iterate like we've done a lot of things. I don't know if we got reset. I feel like you had some plus ones in the past. I looked at your newest ones. I'm going to give it an approve for myself. Thanks Peter. Yeah there was yeah I did a couple of minor adjustments previous to the last meeting just to verify something. So yeah that's all good. Okay we just need a couple more I think. Can you go over is that the only change that you made over the weekend? Yeah that was the only change. All of the changes were prior to the previous meeting. Okay let me see. Let's see it was off May 17th seven days ago and then all right. Okay so this is we're trying to get more use cases in here with the purpose of having context for taking these are looking at them and using them as reference for best practices. So there's stuff that we've started talking about for best practices on state like probably from databases and stuff. The point is to get these in so that we can reference and discuss them we can it doesn't have to be perfect. So is there can we get some I guess some plus ones and get this merged? Are you right now during call or if you have any problems some please raise it right now. I approved it but I suggested a minor change. Let's see. So it's a minor change and it's for consistency also. What is it? Examples of ephemeral state objects are it's not a ephemeral state but ephemeral state objects are temporary files etc. Are you good with that? I'll just click commit if you're good with that. I'll click commit. And I approved it by the way. Thanks Sarani. Any others? I just had a refresh. Nikolai, Tal, Victor, Watson. Get a plus one for me. Or a no. One plus one for me. Yeah I would give it a plus one too. Thanks guys. Looks good thank you. It seems like there's only one checker which is failing. It might be a URL checker and I think it checked the whole repo I think. Let me have it up. Yeah but uh or maybe the status is not considered as a healthier status like because it's returning like 400, 29, 80p code so probably I don't know we have to modify the checker to also consider that because the the URL is fine I double check it and it is there. Did you you're saying this? This wrestling RFCs a dead link? If you click on that it is it is working it's opening the the repo but maybe the status code that is is getting that 429. Yeah consider like I don't know if we have to modify or something to expand the number. These are interesting. Status 429. What is 429? Hmm good question. Too many requests. Throttling. They're very related. That's interesting. So that's all those are all github. That's complaining. These are github links and so there's probably like this link to the definitions. CNCF definition is probably linked from a lot of places. We should probably use relative links because then they become uh tied to the uh commit branch as well rather than linking. I think we tried that. These are for external. These are not. Oh okay I see. Yeah the the only problems that we're having are external links. Thanks imagine Taylor. No problem. All right let's move on to the next one. Um do we have anybody on the call to talk about this? I think a she's came on like for a couple of calls but I've been out for a bit and I don't see them on the call. So this is actually two different use cases and I think we have an open discussion for one of them so that the synchronization timing and multi communication interface which I don't think we have a discussion for and there is hasn't been a towel you put something from ACM on here but we want to either get stuff merged or close them out. Let's see what is the latest way back. Victor this looks like a at least this part of it is a just removing spaces so you're formatting. Yeah yeah but I'm gonna commit that one just formatting. There's a lot about a single line. Okay so Ian was essentially saying we need to have some definitions and limits around all this because it's vague to just say the timing needs to be synchronized but to what level um nothing is actually real time. There's some type of difference between reality and what you're okay with but this is a suggestion I guess um so that's one thing to keep in mind just pointing this out and I'm not looking at the rest of the context for the use case but in a use case we're not trying to communicate a best practice but this is kind of suggesting what people should do. It should maintain. It should do this certain thing and our best practices are where we're trying to suggest what people should do and the use cases are trying to define what needs are and for the applications and the end user services so that may need to be adjusted. I don't know if anyone wants to take this over because I haven't heard from Ashish in a while. Has anyone else heard from Ashish? No. Okay so if if we don't have someone like take over and say this this is a good use set of it's really a set of use cases so if someone doesn't want to take this over and try to move it forward then at some point we'll need to close it out because it's not it's just going to hang around. So if you're interested in these take a look and we can reach out to Ashish but if they don't respond then we'll need to go through and and look if we want to take this over. I think on the timing was the one that had the most interest and that's why we ended up with a discussion and if I if we go back and look at the net service some comments there. All right I can check with them and see if they're willing to go through some of the comments on that. Thanks Bill. I don't know how I skipped over the onboarding but we don't have Vook on the call so I guess we can skip this one today. Okay so this glossary this one's been open for a while too. Tal have you gone through and looked at some of the stuff for being able to commit, merge, and the changes suggest the changes and request? Well I look mostly at my contributions. We're talking about mine specifically. Well yeah this this PR there's a bunch of I guess part of the thing is because it's such a large set of changes then they've had a lot of requests for changes to that or I won't say changes. You mainly had additions but then because of there's a whole lot of different ones you're covering a lot and there's been a lot of comments across that. If you can go through and look and we can get to some type of agreement then we can get those merged. So I really thought we it's the comments are a discussion right? I don't feel like we reached a final decision on anything really. I think it's worth discussing here. This is why we're doing this. Yeah I don't know if we reached a complete alignment. There were a few good ideas but I don't think we as a group as a whole agree on some of the core terms. The big one is still what we mean by CNF. There's still excuse me there's still some of us I think who would like CNF to mean containerized network function and look for a different term for a cloud native network function. I suggested CN-NF CNNF with the dash being an emphasis that this is well we're talking about an operational perspective on a network function rather than a technological perspective which is things like VNF and CNF which refer to how the network function is deployed. With the point being that a containerized network function is not necessarily a cloud native function and a cloud native function could be a virtualized network function. I don't know if that's the suggestion I'm throwing out and I know it's a big one and it really changes even the name of this group work group and what it means. Yeah so essentially this this is probably a topic that I personally want to end sooner rather than later because it feels like it's taking away back to what you've said again in the past how the focus on adding more use cases in best practice versus going around and around on this so the CNF working group is this group and the CNF CNCF telecom activities are only about cloud native they're not about other things so if we did decide and part of this is not this group so part of like the decision on what CNF is is already outside of this working group and would be like a CNCF and I don't know how much Billy you have view into that might need to pull like Chris and Azniak and some other people but the group the working group is cloud native network functions we're focused on that right I understand what you're saying Cal with regards to the confusion on containerized and other stuff I don't think within CNCF in the Kubernetes community there is confusion that's it is about cloud native so it would be presenting itself outside but from the group standpoint whatever the acronym is we're talking about cloud native networking applications that's correct I don't think there's any confusion about that I think and if we would make a suggestion to the CNCF we are trying to align with the industry right and provide best practices for the industry and the glossary is an important contribution to right these are terms that we can all agree with the fact is right now that the industry as a whole is not using CNF in the way that we are if we mean CNF to mean cloud native network function and we've been using it that way so far I think it creates confusion in the industry at large so I mean we can do whatever we want that's true but I think I want us to be helpful and not add to the confusion so like it or not CNF in many parts of the industry and many documents and many presentations that are given refers to cloud native network sorry refers to containerized network function sometimes specifically on Kubernetes but not always and yeah it's an unfortunate aspect to this confusion so I'm trying to make a suggestion for the for the unfortunate one second Fredrick tell one thing that's been suggested and I'm going to bring it up now is break this PR update into smaller chunks so that we can get some of them that are agreed to merged so just on your glossary update the PR in general and then around cloud native I think that needs to be put for probably not in a PR but a discussion so create a discussion I think there might actually yeah there is one that Jeffrey put in here so you could put it in here or put it in a discussion and what I would recommend is creating like a spreadsheet or a link show a big list of here's all of the there's when we do Google searches or whatever you have 80% of the people say containerized and here's 20% that are using that so do this is like a discussion for itself and we can deal with that separately but it shouldn't block all the other glossary items where we're talking about functional stuff of for a use case the main point on this is how do we get to best practices for running cloud native network applications so I think your jump I think there's a confusion here the issues were discussion right I don't know if I would treat them as comments necessarily Ian raised a few points and we discuss things my original PR is not related to that issue I mean I am treating cloud native I am treating cnf as cloud native network function so the discussion might be separate but I think the PR as itself yeah I'm not sure if any of the comments would affect it so I I think the PR could be merged as is and that discussion I agree is separate and we're having it in separate places and there could be a future PR to fix to fix that but right now it absolutely adheres to our original definitions that is cnf means cloud net cloud native network function I did not change that okay let's well Frederick I don't know if if you had a comment or we just move forward to try to close this out without talking more about cnf but go ahead Frederick it was just a little bit of context just from the history of cnf so the actual term was actually created through collaboration with the cncf itself so there's an individual who doesn't want to be named who came up with the term cnf it was said Dr. Dan and and Arpid who then ran with it and popularized the the term cnf it's very unfortunate that the term containerized network function is the way that most people interpret it the acronym despite the the efforts that went on to to define what what a cnf is so it's it's definitely very very acute issue that would be good to get some form of resolution on but I don't see I don't see an easy path towards towards saying that I do agree though that the community of large within the cncf does does agree that it's cloud native network function and we've done a good job in that environment at the community of large is definitely taking their own interpretation so I think they're going to do this even if even if the term containerized network function did not exist a lot of people think that cloud native is explicitly equal to containerization so I think even if we change the terms around it we'll still run into this issue of people saying well we're running a a cloud native thing despite the fact it's just a containerized workload one last thing as well of aligning the cncf to the industry is definitely an important thing but simultaneously the opposite is true as well aligning the industry to cloud native I would argue is is equally as important in the sense that we are trying to have an effect on the industry so we should not forget the goal of it is not to say we're aligning but also to have a positive influence on on the rest of the community but yeah anyways I just want to toss that out not to try to cause any significant discussion but just to put some some thoughts into people's minds on on how we got here yeah that that's absolutely I agree with all that I but and I agree with Taylor that it's a separate discussion so I wonder if if we can go over this PR and if we can do it now and if there's no objections yeah let's just see where we can get with it Tal and and then there's so there's there are suggestions to update in here that I guess any this is for everybody if you if you put a PR in here everyone can help of course but it is coming from your branch or you know probably your own repo so please go through and look at things and try to either merge or respond and so one of them would be not not just the discussion items Tal which may need to be actually you could go this is a good discussion why don't we pull this out of a PR so it's not lost and I've done that myself but some of these would be like this it looks like it may be a style thing Bill that you're noting and this would be something Tal that we could go through and go okay I see that you're just making a suggestion that I can accept I'm not sure if you have to pull it back into your branch or whatever but these would be items that you could resolve and that would help clear out the queue so that we can get it merged faster okay well well this is an example that I did not resolve because I do not agree with the stylistic suggestion oh all right so I guess some background on this one that well that's fine so respond to it Tal at least so that we know that you've looked at it and this would be everybody not I'm just saying Tal but please respond to the comments so that everyone knows if if this is an issue that we're going to resolve or move forward on or just ignore I'd say no we don't want this and we can focus on other items so this particular one I think Bill you're you put this in because it's based on the CNCF style guide for what how to say cloud native I'm supposing but this is your yeah that's correct I just dropped a link to it in the chat if anybody's um oh thanks yeah I'll bring that up there we go all right that's how it is it seems like wrong English to me but I'll accept it yeah this is like the debate this is what was chosen at like the beginning I mean this is quite an old document so um that's just I guess how CNCF chose to do it before I showed up so all right no problem if yeah if that's how it is then that's how it is they definitely had some British English speakers on it so I'm sure it got debated across the board for people but okay so is this something you can commit I don't know or I can just do a plus one for me tell now um I'll commit it actually uh Bill there are other places that I use cloud native with a hyphen so I'll change those as well you'll commit them sure Taylor if you if you're ready to commit it and fix it right now sure thanks the the heuristic that I that I tend to use which may not align with the CNCF is if it's a noun I do not put the hyphen if it's a adjective I do uh which which is the common English approach but uh they they are using cloud native as a as a brand so it's possible that they they don't include the hyphen that's supposed to be for for that reason but yeah the other conversation is way above my head in terms of how how they want to represent their brand yeah well I'll just be consistent because Bill you noticed you made a change that um you forgot one hyphen to remove that's basically it thanks by the way other people have pointed this out but network functions are not called applications uh well I yes but but um we are saying that a network function is a cloud native application right cloud native design principles I think refer to applications so yes in our world we don't call them applications but um if you want to talk about design principles then it is an application in my opinion where does it is that something is this this area about the application no no it was inside your cloud native if you go back to the cloud native within the parenthesis it's a cloud native application so oh um and the other other places other people have pointed it out so Heather the one right below it I think had an example of it yeah could we change application into cloud native software um sure I guess um software yeah I mean if that makes you more comfortable I it makes me a bit less comfortable the software is a very very I know it's very generic but I what so what is the um reasoning for not using application it could be workload right workload is a good word yeah I think it comes down to a specific question though it is a pnf physical network function ever going to be a cnf and if the answer is no there's a high likeliness that every cnf is an application yeah I I would prefer to go with the common and then if we have a real world example where it it's off and we need to change it we're at an exception then we do that versus theoretical so I'm I've been using applications because we're talking about um well primarily we've been talking about on kubernetes platforms and it aligns with that but even on non kubernetes if we're just saying networking software that's running and from an in-user perspective so that could be like a service provider running this they're thinking of the the application running yeah and and I think workload in I know in the kubernetes documentation they specifically scope it down uh in general a workload can be either physical or or virtual but an application itself is is clearly or I guess in my in my mind is clearly software although others may have a different definition for it but yeah I think it really comes down to we want to how do we want to scope it do we want to talk about uh do we want to talk about hardware as part of the cnf or do we want to say the application itself as a cnf um while at the same time even if we take the software approach we still acknowledge that there may be hardware integrations that we may want to do so I think it's primarily about how do we want to how do we want to scope it ourselves to how do we approach this I personally am uncomfortable with with applications looking at to to software but uh this but it depends on where we as a community want to scope it so applications are typically typically have end users that utilize the network functions on the other hand um are components that go into and they may be form part of or or provide traffic through which applications interface so I think that is where the distinction really comes about I hear that um a lot and then whenever it comes back to stuff like the a vcp use case um you have a lot of components in there that people first refer to as network functions but they could very well be oh these are applications so um what is the vdhcp well it's that's uh most of the world would say a dhcp server is an application you happen to be using it as a you may say it's like underlying um or making this larger network that everything else then runs on so it's what are your your end users and because we run this dhcp application as part of our infrastructure networking but then stuff like oh your um your netflix caching server and stuff but even say this vb and g so we're broadband network gateway what's special about this it's it's pushing packets between this side and this side but you have this you have the same functionality from um layer four layer seven type of packet routing things but we're calling this something different because it's it may be underlying you may have an application on top that does layer seven routing that goes on top so to speak to the b and g yeah so you know layer four to layer seven network stuff is usually network services so you know this would may mainly be layer two layer three would be network functions anyway we don't have to debate this if everybody is okay with the application let's just leave it that's fine it was only a suggestion in there i think it's it's a good suggestion um and and i think part of it comes down to again how how we want to scope it down and how we want to interpret it uh this is probably something that should absolutely go into the glossary though to specifically say that if we use the term application we should make sure that we state that it's that it's not just end user but we're talking about it as software just so that we can be clear about it because there there is some there are some differences between how a significant portion of the industry uses the term application versus when you're when you're in enterprise versus it's it's very common for for people to mix the both of us now i have an application that which i mean i have a d in the run or they have a server running or some software running but then when you're in the telecom space the definition may be much more precise i have an application which means i have something explicitly which is interacting with or doing something on behalf of the user that the user is uh is affected by in a way that they see so there could be some confusion there that we do need to be careful with by the way for network function i suggested we use a very standard c terminology right um let's try to move the pr forward so tell um it looks like this one is not changing anything i don't know if if the suggestion um was to not even have this line that says tbd just remove it or or it's okay to be tbd it could be that could be a separate pr you know i didn't remove things that were already there um i tend to agree i think there's a new pr um from a look that uh that adds a whole bunch of other things including uh filling that out so we can maybe deal with that separately um or i'm not seeing that but okay maybe he didn't do it as uh as a pr maybe it got merged did it already get merged that's a good question um i'm not seeing it so i'm not seeing it or a discussion anyways okay so can i just resolve this is there anything to do right now we're leaving it alone we're not adding a definition for kube native right that wasn't part of what i was trying to do um okay so resolve it i'm gonna resolve it okay by the way i just pushed a fixes for the cloud native hyphen so there are no more hyphens great thank you okay i'm working my way up so kubernetes network function a cladified network function deployed on kubernetes note that the knf is not necessarily a container as network function there are ways to employ virtualization and containers and kubernetes date to run full virtual machines all right that's a lot of extra you're not wrong is it useful to us um i think it's useful it's uh all right as i pointed out the last time we discussed this i said that my my opinion here is that it's good to have more terms because we do fall in the weeds of you know the classifying exactly specific aspects of this so this term could help us sometimes when we you know we we can talk about c containerized network functions generally but then kubernetes network function specifically so we can clarify what we mean in this case and and i have seen this term thrown or for example it relates a little bit to the kube native term that we left tbd um it could just help us in discussions i think so um but we're being specific on that the network and application that someone is talking about so if you're giving an example and a best practice or use case that it's explicitly running on kubernetes without saying it's in a container but you're saying this network application is running on kubernetes correct and without without literally saying it that way so then the only question i i think that sounds fine to me if we want a term versus if you wanted to say any use case this is a cnf running on kubernetes that would be the this is short hand for that so um then i agree with out the only thing that out of this that i don't care for is cladified that seems to be like a i don't know if we have a definition for that but i just called that a buzzword cladified sure yeah i wonder if it could be you know i think i meant to say actually a cloud native network function and i wrote cladified by mistake um all right how does cloud native look to you here to everybody how about like is that good like that cloud native network function could it run on another container platform other than kubernetes what oh this is a kubernetes sorry sorry this is a kubernetes network function i'm sorry sorry actually we can just write cnf because cnf means a cloud native network function like this yeah oh did you do it um i did not but i pushed something else so you know what let me just do it on my end all right all right pushed i should have done the single line comment let's see what that looks like i wonder if you need to refresh the page maybe to see my um it'll probably show as soon as i this shows outdated right but i wonder if you just press the wrong view it might show it correctly oh i've i've already um refreshed but i'm in the wrong view if i do the file view so it's basically saying the comment and the other view is off right yeah see there we go and then it's already shown resolved okay okay um okay and then this one is exploit this is kind of a similar one where we're trying to at least um call out that we recognize that if something is only in a container that we could say that because like i said in this one you could have a cloud native vm running on kubernetes and you could have a container as network function that doesn't follow um any cloud native standards i guess right so you know i did define a cloudified network function here so i don't know i do see that now yeah yeah this one's interesting that okay kubernetes network function well because here's the thing you know a knf maybe i'm still sticking to my original definition because a knf you know you can have something running on kubernetes but if you haven't used cloud native design principles we shouldn't call it a cnf we shouldn't call it a cnf cloud issue sorry the issue with cloudified network function the last sentence there um to be classified now cloudified network function is must not it's not necessarily adhering to cloud native principles yeah it's the sentence before that that captures what tal is saying so you it's not necessarily a cnf if it doesn't follow those principles but the last sentence contradicts that again it's saying to be classified as a cnf it's just the the way the phrasing is makes it a little bit then we should change us to cnf okay if it's if it's not clear or change the period to a semicolon or something you know because i'll fix it to be classified as a cnf sure it must be here as much better all right and to i think frijek made this point earlier maybe it was in a comment but does this help us um why are we putting a term in like the term should help with something that we're discussing versus theoretical discussion so is this something that we're already referring to classified i think i think this may relate that the term itself is new to me but uh but i think the intention may have come from conversations that uh that uh ian was also involved with uh some of the conversations we had was what what does it really mean for something to be uh to be cloud native and for to be like how are we using the term and how are we describing things and one of the areas that we found that there was some contention around was if i if i was in a if i was in a cloud and i created an api within within a cloud that allows you to let's say create a firewall on the map or create a vpn on the map is that being considered to be cloud native because it only runs in the cloud and so i think the term very likely came out as a result of of those discussions though i'm not sure where the actual point itself was was termed but that that's my guess is that is is it has to do with how do we mean cloud native which is very specific versus this is something that can run in the cloud or even is provided as infrastructure that that's part of a cloud uh or designed to to run in a cloud which uh may not be a cloud cloud native in the way that we describe it as being something even horizontally scale etc etc so just that's exactly it yeah i the problem is that in some conversations with people who are not on board with don't know everything that the cncf is about and think that it's you know it just means running things on kubernetes we need to distinguish these things and say okay you brought your cnf you brought your network functions to kubernetes but that's not enough if you want to be classified as a cnf that means following our best practices and the design principles for cloud native so all of these terms are to help us make these distinctions right okay so if we are if you are if you are creating a term cloudified network function which covers both vnf cnf etc and i think the vnf definition needs to be changed um well we can scroll to the vnf definition definition too yeah we had some discussion about that as well the reason is the vnf definition right now overlaps mostly with what the queue your cloudified network function is so well you can make vnf purely a virtual machine based network function in this well the the way i defined it um it talks about the technology and it actually doesn't mention the word cloud at all you can have virtual machines that are not it mentions it mentions containers also um well i'm mentioning that virtualization technologies so virtualization does not have to be specifically with a virtual machine i agree i agree but since we're defining so many terms maybe vnf could be restricted for network functions deployed on vms only that's a suggestion given that now you have a cloudified network function which can cover basically both scenarios and i think we'll run into the same issue as cnf though in that the vnf is this is when they talk about a container they actually use the the term well virtualize to cover any any form of isolation system that's there which includes a container and um i i i've had i've had significant discussions with people through set through cntq back when it was still before it was part of etiquette and similar about this exact phrasing this exact term and so i think this is one that we need to be really really careful with is you know in terms of redefining vnf because like redefining cnf like we came up with the term but the term vnf originates from etsy and has a very specific meaning within etsy that that will end up fighting uh so we want to be careful that we don't conflict with that definition um we we could say if we want to restrict our usage i think it would be okay to say that when we describe vnf's we're explicitly talking about uh virtual vm based systems um but also make it clear that we're that we're not aiming to to uh derail the etsy term i i think we i think we should be very careful on on how we approach that right i i try to be careful we're at the top of the hour um and tal if you can go back through and try to respond to as many of these as possible um and then i think the one that i can see that may not be in here is what is the definition of cloudify and that that would expand on this so cloudified network function but that's the only one i'm saying but if you can just go through and then we'll i think i did i think i think maybe next week we could continue this i think we're not done quite with the discussion there there's some of them that i'm saying when i just scrolled through that look like they could be resolved like i don't see a debate on them so if you can go through and either say those are good and then click resolve and that way we only have a subset next week all right thanks everyone thanks so much see you next week cheers