 We'll give it a few minutes for folks to join before we get started. Hi, Dan Kahn here, and 26 participants is pretty good. So I think we'll go ahead and kick things off. I wanted to introduce the group to Alex Salkever, who's a marketing expert who works with CNCF, and he has generously volunteered, perhaps not knowing what's ahead of him, to focus in on the first release of the white paper or what we might come to think of as the first chapter of the white paper. And we're aiming to get a draft of that out in the next few weeks and get it reviewed by a bunch of folks and to be released at KubeCon November 18th in San Diego or 19th in San Diego. And so the opportunity, I guess I would emphasize our interest in having telecom operators as co-authors of the talk. We're also very interested in feedback from vendors about the content and to essentially ensure that we don't get anything wrong. But we want to, I think, probably start with just some high levels about what CNFs are and how people are going about them. And then in areas where there's less agreement to try and list the different ways of doing things, as opposed to being particularly prescriptive, especially upfront. And so we would love to, in fact, we are planning to highlight a few telecom operators and the approaches that they're taking and would like those folks if they can get permission to be co-authors of the paper. We're then also very interested from hearing from vendors and other members of the community of, oh, you should also consider this alternative or this option or keep track of some of the positives and negatives of different approaches. So Alex is going to be reaching out to you. But I would encourage you, particularly the operators on the call, to please ping me. Our hope is that it's going to be Rakutan, Verizon, and Vodafone. But we're also chatting with Charter and Belkanda and a couple of folks, other folks in there. So with that, I think I would hand it off to Lucina and Taylor to give a little bit of an update and maybe present those slides about exactly how the CNF testbed has changed over the last three months and then what the plans are for the next three months. But then I would also open it up to other folks who wanted to add things to the agenda that we should have time for other material as well. Sound great, Daniel. Yeah. And sorry, the last thing I'll just mention is that we are, yeah, I would appreciate if you and maybe some other people who were there could also give some, one of a summary of the CNTT discussions that we had in or that we're had in Antwerp. And I am hard at work on finding two rooms for two hours each or a room for two, two hour blocks that the CNTT can meet and Tug can meet in during KubeCon in San Diego. So I hope most of the folks on the call will be able to participate in that. Very good news. Thanks. I can say some words about CNTT and that. Yeah, please go ahead. So what was happened week before last week is the second meeting of the CNTT, which was face-to-face and public to both deco vendors and operators. And we agreed on to start working on the Kubernetes-based reference architecture, which means that we will describe an infrastructure which is based on Kubernetes and which can support one or more profiles from the reference model previously defined in CNTT. The initial content has been already pushed as a poor request I think last week and now heavily discussed. There are different views on how much should we consider Kubernetes as a full-blown NFEI slash infrastructure as a service and which parts of Kubernetes covers from the SNF mono architecture to overcome these mostly philosophical debates. We agreed on the meeting that we will focus on the interface what the Kubernetes-based infrastructure provides to the VNFs and we will not spend too much time on like if Kubernetes is running on virtual machines or on bare metal and or if Kubernetes can manage hardware or not. Because opening up this discussion would like defocus the group from the original aim of CNTT. Other thing what we discussed shortly and what relates to what we are doing here is that we should like separate the work in a way that we put most of the infrastructure-related parts to CNTT and direct the application-related discussion let's say describing the ideal CNF to the divide paper but of course that's up to this group to discuss also. Other thing which is related to this group is that CNTT would like to establish a working connection between these two groups in a sense that this group would let's say verify or review the Kubernetes-based reference architecture which is created by CNTT and of course CNTT invites all members of this group to provide contributions and comments to the content generated there. I'll just go ahead and say that on behalf of CNTF we're happy to collaborate and so I was assuming that these meetings in San Diego that I'm trying to arrange would just be joint CNTT Tug meetings. Yes, me too. Yeah, all the docs that we produce will be open for public review and so we would love to get. It's a little bit of a metaphysical question on whether the review is from you as a telecoms engineer or you as an official representative of CNTT but we're very interested in your review and feedback. Yes, thank you. So my plan is that I will send from time to time this or divide paper to the CNTT mailing lists and I will send from time to time the content what CNTT generates to or Slack or mailing lists so you know just to initiate some kind of cross-convocation between the two groups. Yeah, I really appreciate that and so I would heartily endorse that. Now this is a Watson like to add then in the CNTT a multi-tenancy was brought up multiple times and it seems like that would be a good if we had created user story or some requirements on how Kubernetes can address multi-tenancy issues for CNS for the telcos. It seems like that would be a good place to try to collaborate. Yeah, great. Yeah, I mean I might just respond to that by saying that that probably is its own whole chapter of the white paper or whatever we wound up calling different sections but it definitely could both specify some requirements and then say what's feasible today with things like our back and then what things are coming down the pike and our alpha level features or we're not even shipping yet. Yeah, and to follow with that I agree with that sentiment. Part of what we need to be careful with as well is like multi-tenancy itself is a implementation detail and so we should try to work out what are the real drivers what are the real things that they're looking for as opposed to saying okay we need multi-tenancy. It's like well you need isolation but multi-tenancy is a way of doing that. So it would be good to get those conversations going to work out like what are the real drivers of the requirements as well. Great, I know one of the big drivers they kept bringing up was just regulations. So having their users and their data separated GDPR and other things like that. I think in general it's GDPR, it's any sort of regulation. Also operators typically classify their applications into security groups and they would like to have separation between those. There are VNFs which sort of live in a so-called demuterized zone which of course needs much higher security than others but of course also separation between individual vendors can be of an interesting point. So there are all sorts of reasons why operators would want to have separation and therefore since the separation capabilities of Kubernetes as of today is not viewed as something good enough we are talking about multi-tenancy all the time. That makes sense, I think we'll have lots of conversations on this. I just want to make sure that we have it on the table to understand the requirements. No, I think it's very relevant to talk about isolation and not just multi-tenancy first so I think that's a very relevant thing and also Kubernetes in itself using the capabilities it has today has some multi-tenancy capabilities. So in some cases that's sufficient. Then of course when is it sufficient and when is it not sufficient it's really down to the exact country we are in, the exact operator, the exact rules and rules that are applicable or the corporate level guidelines and again hard rules. So it's like hard to give out a clear recommendation is the requirements change country per country, operator by operator. Good discussions, helping that we can continue. Excuse me, I got a cough. CubeCon with the two hour blocks that we're trying to get the room for so appreciate your help on that Dan. There's a link to the reference model, thanks for adding that. That's here in the notes for anyone who wants to look at the current discussion on the CNTT side. Yeah, I think in this poll request the discussion is currently more interesting than the content itself because it's just the skeleton of the chapter so far but it initiated lots of thoughts from lots of people. I'm going to try to make it through my update on that. Is there anything else before we move on in the agenda? Hello, I had a question. Do you already know on which day will the CNTT and the CNCF talk submit during the San Diego QCon? We don't have the dates set specifically probably one of the dates so it will be the Monday where there's all the co-located and date and then we'll figure out the others and then we'll post in the token user and the mailing list as well as on Slack and notify all the different groups. So it shouldn't be one of the three days? You said it's Monday, the day before. We're thinking that the first one, so we're probably going to do it a couple of days, two of these meetings and the first one we're thinking Monday. There's a lot of co-located events happening Monday and so I think a lot of folks are going to be there for those and then look at one of the other days to continue. Okay, so there should be different subjects discussed during the first and second meeting. The first and second meeting, yeah, or a continuation. It seemed like a lot of the conversations during O&S and CNTT had follow-ups and a lot to cover. Okay, thank you. Yeah, all right. So on the CNF test bed, we've been moving forward on the roadmap and I can actually bring that up and probably share my screen. So for the folks who haven't seen this, the CNF test bed, we've been working to make it more usable for other parties to recreate. A lot of work has gone into update documentation, making it reproducible, specifically on packet right now. A lot of the use cases that were in there that were primarily based on Ansible and other custom scripts have been re-implemented with either Helm or YAML that you can use with Coupill Apply. And along with that, we've added several Network Service Smash use cases, including one that uses a physical gateway, a network card gateway. So we actually have the capability to do acceleration in that network function and connect other service chains. And we actually use that during O&S as part of a tutorial, which there's links on the Telcom user group document as well as this roadmap. All of these are clickable links to go through. And so a lot of it has been getting those building blocks in place with the new structure for other to make it easier to add new ones and get contributions and then testing that out. This is our roadmap going forward. There's probably some stuff that's going to be shifting, but this is covering quite a bit of it. So some of these are built on some existing. We do have an IPsec use case, but what we don't have is a multi-node setup with Network Service Smash looking at putting those in place. We've had a existing benchmarking test case that uses simple IP routers, either IPv4, IPv6, and then use NFE Bench to benchmark that. What we want to set up is the same one and run benchmarks with Network Service Smash and the new structure that's easy to play on Kubernetes and then be able to benchmark that. What I don't have on here, but listening to a lot of feedback was understanding the results when we are doing benchmark examples. Some of these are functional tests and you're looking at end-to-end tests for results. Some of them are benchmarking, but the end feedback was what are the results we're looking at and what do we expect whenever we run the test. We'll be updating the documentation and structure to make sure when you go in to a specific use case and you have a set of tests that you can run with that, what you should expect to get out of it, as well as working with different folks, including the FDIC folks that have been helping to update some ongoing tests that we're going to be showing those metrics on. In addition to that, we're working to add DanM and some other different technology like Maltis and other pieces that we'll be adding in there and hopefully a GSM 5G use case, like using the packet facilities that are connected to Sprint's network towards the end of the year. We have a call for help on the OpenStack side. We do support deploying OpenStack. Right now, it's using Chef OpenStack. We'd like to move towards a COLA or OpenStack Helm and make it easier to manage and kind of match up with a lot of the industries moving towards some of maybe the larger side, like Airship, but making it still reusable and easy to work with there. So if Nikolai is available, I'd like to maybe hand it over to you and you could give some updates specific on the network's service mesh and then maybe Michael on some of the other updates. Nikolai, are you there? Yep, I am. Can you please switch back to the roadmap that would help me a little bit? Sure. Thank you. Yes, the last, I don't know, mountain and a half or something, we have been adding these very initial use cases with NSM. We started with a very, very simple one and then we expanded to external connectivity. As a result of this, we had some like feedback that is very useful for our community. This has been like analyzed and worked on and actually I think that the next update from Michael and Matthew, I think also on the code, it's kind of related to what we found out. It is more or less regarding the fact of how you get packets in and out of the network service mesh. So we have one or is it two, probably more examples that are in the queue as the roadmap shows maybe for the next months. And at least from my point of view, and this has been shared actually on the open networking summit during the tutorial and during the session that we did about NSM and rather linking the CNF testbed, we had actually the most complex NSM deployment that I have personally seen, like probably, I don't know, 20 or 15, 20 number of end points connected and chained together. These are always, again, thanks to Michael, so thank you Michael for putting all these together. And I have reached out to a number of people already. I'm really inclined to see this JSM gateway 5G. I don't know if you have to look at what is available. There's an open source software that can be used to implement this. So I would say that at least for me, like personally and also from NSM point of view, I think that probably this is the next big thing that I will be looking for. And if we can get this to some of the big conferences and shows, I think that this will be a win for all our communities. This is more or less for me if there are questions. Okay, I guess Michael. Thanks, Nikolai. Thanks. Michael? Yes. Would you like to share your screen or do you want me to share anything specific? No, I think if anything, you can share the CNF Testbed GitHub, potentially the pull request that we have in there right now. But just to try and start out where Nikolai left off, we did the O1S demo where we're showing this external gateway and it'll also be visible from the documentation we added to that one. There were some limitations that we saw with running VPP inside a container with any external interfaces connected. And what we end up doing is running the container in privileged mode. And that's something we kind of want to try and avoid both because of the security, the problems with this, but also just in general, it would be nice to have something where we have a bit more control over what's visible inside the containers. And similarly, I've been working on adding this SROV network device plugin as an example to the Testbed as well. And this one is kind of similar in terms of external interfaces in VPP running inside a container. So what this plugin allows us to do is it allows us to assign a limited or a subset of the physical resources or interfaces available to a container. But since we're running the container in privileged mode from inside the container, you can still see all the interfaces and you still have the option of using them. So for now we're using a somewhat of a workaround where we use the plugin to assign resources which are listed inside the container and the environment variables. And then we generate a configuration that matches the request. So from a user perspective, you'll still see that you have the resources assigned and those resources will be available inside the container. But if you get a CNF in this case that is acting somewhat on its own, it has the ability to take over additional interfaces. So that's a bit of a limitation. And I think right now we're trying to figure out what we can do and bring in some of the VPP developers to try and see if we can find a way either through a list of device mounts or Kubernetes capabilities to actually to avoid running the container in a fully privileged mode. So this is specific to VPP. If you're creating network functions using VPP, what we're talking about if you want direct physical access and specifically using VPP with the DPD K plugin. Yeah, it is. But again, that's what we've been basing a lot of our use cases on so far. All right. On that note, if folks know about more open source software that would be good for network functions that we should look at adding into the test bed so that we can use them in previous cases, then please let us know. Does anyone have any questions before I hand it off to Gerge? One comment about the privilege mode. So I think we should not say to anything which is running in privilege mode that this production ready. I completely agree. It's definitely only for, I guess, environments where you have full control over everything that's happening. It's not anything production environment, that's for sure. I'd probably say that's in a general case unless you made exceptions. There are ways that you could isolate if we said node affinity or something, and you said these specific nodes are going to not have any other pods running on them. You could get around it. Agreed that that should be the general goal. And then if you were looking at exceptions on that rule, how would we do that? All right. Any other comments or questions? The CNF test bed. I think one of the specific things I didn't mention, which Dan mentioned in the ONS keynote, is we're moving towards having the CNF test bed as a full dev environment anyone could use for working on use cases or writing CNFs and then eventually being able to run any type of fiction test for conformance to in collaboration with other groups. So that's kind of the goal. And if you have any feedback on usability or anything else, then please let us know. I think if we are talking about conformance testing, then perhaps there is a need for a little bit more cooperation with the CNTT activities, which very much look at the different architections for cloud native environment. I think that we could use the test bed for having the different implementation for the cloud native environment. Just an idea. Yeah, absolutely. We're going to be working with and trying to collaborate with the OVP certification. And that's going to be tied in with CNTT. So there's going to be a lot of cross collaboration between all the groups. And what we're looking at is being able to run the test. I won't say right now what does that mean as far as everyone else? But we would like to anything that we implement in the CNTT test bed, we'd like to be able to say whether it passes or not the certification and conformance. One comment? Yes. Is there any plan for this kind of collaboration with the OVP? Because I remember the first meeting some guys said it's not going to be any certification in the near future or something like that. Yes. There will be collaboration. It's definitely... I've had some conversations about working as far as the OVP certification. Nothing has moved forward on that. So this is real early kind of announcement that we're going to be doing that. We're going to definitely be talking and working with all the groups to make sure what we're doing is going to be able to support those plans and that we can run them and implement them and influence them if we have any feedback. Okay. I think... Specifically, the OVP are all focused on VNFs right now. And so the CNF conversation hasn't really we do expect to collaborate with them personally. Very early announcements and it will probably... That could be some conversations that we have at KubeCon. Looking at next year, what do we want and the certification. All right. Anything else before going on to Gurga and the White Paper? All right. So I think we partly covered what I wanted to discuss here. So if you would like to release something by KubeCon, we should do some scoping of the White Paper because currently it's very long in terms of a content list, but it's very slim in terms of content. So we should start discussing on which parts do we want to keep for this first release of it and which parts do we want to release later on. And we should... I think we should start to do some more focused work on the parts which are planned to release by KubeCon because that's very close to now. Yeah, practically we have this month to work with. And I don't know how do we want to handle the review by CNT whether that can be done before KubeCon or after KubeCon. That's an interesting question. But I fully agree. I think we have a very ambitious scope today defined for the White Paper. And we could agree on a scope that we prioritize for the first release. Then we have a better chance of finishing anything. So this relates again to the discussion what we had in the CNT meeting with Damaj that maybe we should focus on the application aspects in the White Paper and describe the infrared things in CNT. That's up to discussion within this group. So at least from my perspective having observed the progress and long progress of the White Paper for some time, it seems that one of the reasons that it's not making progress is that it implicitly has a scope creep. My understanding was that initially the goal was to define how do I mean the goal standard for cloud-native network functions look like and what is necessary from the platform. So basically limiting the scope to say I'm talking about the hypothesis actually telco functions are not special, right? Standard Kubernetes platforms that are supporting sophisticated workloads from the IT industries should be sufficient and then discuss where this hypothesis breaks down and where potentially things need to be added. But what I see is that actually the most progress is being made on adding a discussion of Etsymanl adding arm support etc which are not which I don't see as being the core of the message here. Yeah, I totally agree and this is because we did not specify the core, you know like everybody could add a subchapter and like somebody did an etsymanl and I took the freedom to add content to it. Right. I see this mostly like lack of prioritization Yes. So it seems that we should probably first discuss kind of what we call the gold CNFs and then worry about I mean how to extend that for the bronze or whatever it's called CNS later. Right. I tend to agree, I think there's one more thing that perhaps is missing before defining the gold CNF and that is what is the thing that we want to achieve with this transformation or with having CNFs in the telco context because I think the benefits of cloud made in the telco context I think that's already known but I think it's important to match up the architecture transformation that we look at for the CNFs or from the VNFs going to the CNFs the vice needs to be understood why is it what's the benefit to the operator of having CNFs and not VNFs so I think that's the reason why I suggest that at least in the first white paper we should try to define the wanted position or the goals of this transformation and I think that is the area where we could use the help of operators because the goals shouldn't be set by the landlords so I think that's a very good point and if you consider that at least in the IT space more and more use cases will be natively supported by Kubernetes talking about high frequency trading or media broadcasting or some of the physics applications so eventually we will see features in Kubernetes proper that are also largely useful for telco functions and the question is like one or two years down the road is there still a need to add telco specific extensions I see a convergence between the IT workloads and the telco workloads and it's not because telco workloads are not special but it's because there are other workloads in the IT space which are particularly special than telco workloads So can we start with the hypothesis that telco functions are not special and compare how they are similar workloads in the IT space that have similar requirements I think there is actually text in the current white paper that details the similarities and differences between enterprise and telco which I thought was rather good I also like that text it's maybe overshooting a little bit on the telco side because at least things where the text claims telco functions are special I don't think that's necessarily true but let's look into that I think what we need is first a high level description of let's start from the hypothesis there are without native network functions that we want to operate and design as closely as possible to what the rest of the IT industry does with their special functions not comparing to web but to other high performance functions I really like what you say but I think the purpose of discussion or why I have put up this item on the agenda is of course we could argue on what we should write in the text but I would like to see a proposal emerging in terms of a prioritized table of contents for the white paper so we could get to work and you see my proposal on the screen I'm basically I took all the parts which seemed like relevant and are in good shape and can be related to the topic of the transformation of the CNFs themselves so I took the definition of the CNF the similarities and differences between enterprise and telecom then I sort of suggested we need to talk about the goals what is the goal of the transformation and that as I said should primarily be coming from the operators not just that but that part definitely and of course the idea CNF and the design principles in how to make those happen that's again a chapter that is not yet written then when it comes to the importance of Ed Simano and management support I sort of feel like that's a fringe topic and we might include it or not when it comes to the ARM architecture I think I like the text but then I don't feel like it fits into this white paper that is concentrating on the CNFs because I think the core value and the core notion of being cloud native is to be agnostic to the infrastructure and there I think the most we can say is that the application should work on whatever processor architecture where I can run Kubernetes yes so one comment because I add that chapter myself so I would say since it's CNF and it would be agnostic architecture to the infrastructure architecture to the processor architecture so for the CNF I think it should be able to run on the ARM architecture as well without knowing what's on the release infrastructure so that's the point I would like to propose this such chapter okay so I think that's also a basic principle of the CNF to run on both the X86 or the ARM architecture so we can trade to ARM as equally as the X86 I totally agree on the goal for the ARM support the question is do we need to give so much space to something that is at least as obvious I mean should be obvious that other architectures are supported and we can mention that do we need to create a whole section for it that's a different question I think to me it sounds like if we wanted to do that then we need a whole section on Intel as well and then we are pretty much shifting the focus of the white paper into something that is very hardware specific I'd prefer if we having a line that says to support multiple architectures such as X86, ARM etc etc as opposed to having a section on this and I think we should engage with the industry on a proper white paper on this because this is a really fascinating topic and there's going to be a lot of implications on edge infrastructure as we start to see more data centers pop up on the edge and many of them will be ARM or RISC or other similar platforms but I don't think we can do it justice here without defocusing the white paper I'd back that up but I'd also just point out this concept of chapters that just putting in a paragraph and saying hey we're going to circle back to this in the future Taylor and Denver and Lucina are actually now some of at running multi architecture containers through their work on CNCF.CI and so they would be happy when the time is available to come back and talk about some of the lessons learned there and pitch goals and such Yeah, you know chapters is a fantastic idea as well. I know CNTT does that and so good place to do it too Yeah, so because for the white paper the structure of the white paper not only has the chapter so that I put it there but well if you guys think there's other place that better to state this kind of work for the arm I think we can check that later but yeah it's still in progress I'd like to go with the suggested approach of emphasizing the hardware agnosticity and then you know saying that there is going to be more details on this because then I think if we do something around hardware that should be around node feature discovery and maybe use of smartNICS you know different processor architectures then can get their own chapter but perhaps not in the very first white paper Yeah because I understand that the transformation from the X86 or to ARM or from ARM to X86 are quite time consuming work and there's a lot of stuff involved so I think we should mention it somehow to remind people to understand they need to take that into consideration before they really you know implement some kind of application so that maybe you know to save a lot of time and the money and the human resource that's something I want to say because everybody understands that ARM is important now but maybe they just didn't really think about it during the development or the design time Okay Right So then I just for the sake of differentiation I colored this ARM chapter yellow and the question is does the rest suggested here sounds like a good scope for the white paper for KubeCon because this would practically mean that obviously with some document editing there would be two chapters that we could concentrate on and then maybe if we could get some participation from the operator community and there could be two teams running in parallel one working on the goers and another one on design principles At the very first I think the first five the intro up to the ideal CNF I think would be good I think the importance of Etsy model management support is going to be a very interesting topic and I think there's a lot more there that we're going to have to talk about in terms of like how does it fit in with CNFs and do we need to drive existing Etsy infrastructure into CNFs and my reaction at this point is we probably don't need the majority of what Etsy has but we need to make sure that we can integrate with it and I know others here also share differing opinions on that as well so I think the first everything above that I think we can get some clarity I suspect we have some path that we can drive and deliver on something I would also exclude the Etsy model piece because as Fred said it's still too much discussion on that and I don't think we will converge in time Yes I don't have problems with leaving the town for now I actually have problems leaving I included that with the purpose my purpose with including that was that no matter what we do to the CNFs we somehow need to show continuity in the technical space about management I think there has been a large amount of money spent towards at CNFV in the past and I think if we introduce a drastically change to the CNF itself we need to do that without a drastically and very costly change to the operational model of the operator and so that's why I thought it makes sense to have it here it's good content as far as I am concerned and it's relevant but of course if everybody says it should be out I'm going to be the one who will insist I agree with you completely actually the effort has been on the Etsy side and shouldn't be dropped especially like there are many operators in the market that want to keep the Etsy model architecture so like this I'm an operator so don't shoot me now but I totally agree with the fact that we should not include it for now we have tried to implement this everybody knows the challenge we have right now with those kind of architectures and see why CNTT is still there so the first five bullets are the key that are going to justify the glue of how we make that cloud native transformation how to make our network workloads look more like IT knowing that the major differences might be the service impact afterwards like me a telco application moving into the cloud native you still have a critical application they're supporting a critical function in our network that might be more around that angle we should angle after that more or less the technology but they're day to service that needs to be relying on this and MANO afterwards should be coming afterwards same for the hardware architecture like ARM while we talk about something like this there's some new technology just being invented so the underlying infrastructure was completely continuing evolve the first five bullets are the more critical ones right now in my mind the way that I see it is the first five bullets are the descriptive way of saying here's what cloud native is here are all the benefits that you're going to get from it and then if someone says I like those I would like to use it then you have this follow-up and you say how do I integrate it well we need we follow at six standards we need to integrate it there we have ARM in different parts of our network we want to integrate it there the first white paper would be here are the benefits here's what you're going to get here's our goals and then you can decide whether or not that even fits if it fits then you can go further in look at the next papers everybody disagrees I will not insist so I will stop insisting good so I think that's the content for now and and obviously time is running very short both for this meeting and both until cubecon so I'd like to see if we could gather a very operative team that could start laying down some text now then you have mentioned that you will end this someone who will do coordination on this work right yeah Alex is actually going to do more than that he's a very good writer and editor and this is his primary focus for the next few weeks so he's going to be diving in and looking to do phone calls and then you know engage in big Google Docs with many of them so shall we contact him explicitly will he contact us having this work it would be best if you can just ping him and me on Slack it's Alex Salkever and Taylor can put his name in the yeah that would be great okay yeah I'll do that Tomas I look forward to talking with you thank you for offering so quick request as well as can we create a new Google Doc for each of these sections because the current Google Doc is getting unwieldy and we can find through comments and the second one is can we set up some times to discuss as a community like once we have some pros written to sit down and talk through these things to make sure that we get efficient because like we have about a month left and we only have two meetings one of which is inconvenient time zone for many of the United States authors so those would be the two requests do we want to set up a meeting to focus on the white paper it would not would not be bad like I think we should write something first but I think we should have we should come together and have some meeting that we join in on to discuss and make sure that we that we get as many ideas percolate through as possible I think a meeting is not a better idea to have some kind of a same position point that I would rather like do the majority of the work via Slack let's not wait for meetings to do stuff it should really agree and I actually think we shouldn't even schedule anything until we've written something substantial as well that gives an impetus to actually write something I agree with all of you I think it's good to have a meeting where we agree who does what because time is limited and our resources are limited so I think if we can agree on who does what then we can you know use our own resources to the best effect that's why I think at least some meeting would be good to coordinate and then we could go away and then just do the work I think we got some there thank you very much for your input I have contacted Alex and then of course you are very much encouraged to do the same and then I think I'm done with my agenda point I got to drop to another meeting but thank you all we'll I guess push the rest of them I think that the last one was updates from Muhammad on Etsy we can push that to the next meeting if that's alright and then we'll follow up on Slack with regard to any new documents for the for the whitepaper and to work on those chapters as well as follow-up meetings check on the CNCF TAG channel for those thanks everyone next meeting is on October 21st that's 11am UTC or 7pm China standard time thank you very much goodbye thank you