 Hello, hello. Can you hear me? Test, test, test. Oh, yes. I can hear you. Good, good. Um, do you want to put an update on the agenda for, uh, for the meeting? I see you didn't. Both was fine. Yeah. So, uh, I'm assuming the due diligence for open telemetry has ended. Um, we had, I'm going to make an announcement once, once people have settled down. We had the call last week. We found consensus on, um, within the TOC call that basically, um, everyone had good intentions and everything. I don't know if you saw that email. The intention of what is called is to just walk through the document as we have been trying. Um, and once we're done with the document, just hand it over to, uh, to TOC, uh, in its entirety for them to actually decide on, on what we come up with. Also Bartek put me like 20 minutes ago that he can't make the call right now. Of course he has some family thing going on, which is somewhat unfortunate, but it is what it is. So I also poked Ted Young, cause he told me he would be coming, but he didn't reply to my poke. Um, does anyone know if he's coming or should we start without him? Cause I thought he wanted to own this from hotel side, but I, I don't care. I just, you know what I mean. Um, yeah. Okay. No one knows. But we have Morgan, we have Steve, uh, which should be good enough, I guess. Oh, okay. That sounded worse than I meant it. So as people are still arriving, let's give everyone one more minute to get going. Uh, Steve, if you want, you can already, I am at the right. Everyone write yourself into the attendee. Uh, if you want to, I'll also link the document in a second. I'm just going to make a few more lines down below. Morgan, you still owe me a salad. Just remember this way back from 17 or 18, you still owe me one of your salads. Okay. The attendee list seems to be settled down and settling down. So let's get started. Uh, for information of everyone, we had a closed to sequel last week as announced. Um, it went well. Um, I do hope that we will be able to simply walk through the document at pace. This time. And we hand over to TLC speaking of TLC. We have Alina here in her role as a sponsor for the due diligence and also Cornelia as the TLC. Welcome and thank you for joining. And let's get started. Steve, do you want to share your screening? All right. So we starting from number three. So the consensus from the last call while we just put both of the statements by, by open telemetry and by Bartek as a link or as a direct thing in on top. Ted wanted to write a statement from open telemetry set, but I cannot see it. I don't particularly care how it is linked if it's in the document or if it's a separate document. Um, I suggested for the intensive purposes of this call, we just acknowledge that this exists. And if there is anything which is in the consensus down below speaking being blocked by the above, we just point to it and move forward at speed. And again, sick does not make any decisions anyway, it is the TLC. So we should optimize towards consensus finding. So that being said, with number three, we can either try to continue with this highly specific consensus building on specific parts of, of where we have consensus, or as an alternative, we just refer to both extra statements and move through I. What does everyone think. I'm good either way. I love the thoughts. Yeah, that works. Which of the two. Are you both work. Sorry, just finishing my shredded wheat. I think what Richie's present proposing is either we can keep what we have currently which is we had consensus on the first two and then we have the orange warning, which TLC can take a look at, or we can attempt to resolve three and four. Do we want to try to resolve three and four or do we want to move on to number four I think that is the question. Yeah, yes, Steve thanks for clarifying I think I thought that probably going through three and four would be useful. But again Richard deferred to you. Steve can you zoom in a little bit on the dog. Oh yeah sure. Absolutely. Request to zoom in. Yeah, I think we should move on to number three. I think we should move on to number four. I deliberately do not hold an opinion here I make suggestions and it is for open telemetry as the project which is currently within due diligence to decide what they would prefer. Same as with with the other calls. I'm totally fine either way. If we move on to number three again then maybe we'll ask everyone again whether or not we should continue rabbit holing or just moving on from number three. Sure. Yeah, yeah, that's good. Okay. So number three, yes, consensus sick observability takes note that the logging signal is currently experimental and plan to be stable into 2022. All agreed anyone disagreeing. There's theoretically a chance it could become stable earlier than that but let's not count on it. Yeah. So, so what approximate, you know, you know kind of chances this have of slipping out of 2022 like can I hang my hat on that business wise. You can hang your head on 2022. I would not hang it on 2021, though it's possible it could be 2021. Yeah, I think from my perspective it's just looking for a commitment like this is something that's going to be done like the timeline isn't super important but it's just like this is something we we care about right. It'll be there 2022 like we had splunk of a big dependency on it I happen to know Google has a big dependency on it this that's brewing. Yeah, there's a lot of blocks already there right like the data model exists there was just a new OTAP for the instrumentation libraries that was recently approved there's initial PUC and Java done and of course the collector has some logging support so given that the foundational pieces are there. I mean I'll let Morgan and Eloy to confirm but I'm pretty sure we're confident in 2022 for stability. Very confident 2022. Yeah, I mean, you know, I mean I'd outlined the timeline that we're working with and some of the moving parts and in the additional doc and and again definitely we're targeting in RC this year for sure. Again, would clearly say that 2022 Q1 is what we're targeting right now for stable. I mean unless we add more engineers, you know specialized in the areas we have a priority on it also from AWS, but likely we will pick up steam in Q2. Any other questions for number three. Any other questions, what should we put in officially this is open telemetry stating within their doc what their timeline is. We can put Q4 21 we can put 2022. Let's just put the year I think I think the way it's written is fine. Yeah, I think also like putting putting the link to the roadmap so we don't have to modify the doc if anything changes would be it would be useful. Yeah, can you help with that? Or Morgan. Yes. Yeah, yeah, let me find the link. Sure. Sorry I'm late my last meeting I was running ran over. Okay. Okay, let's start. Okay. Stick observability takes note that the login signal is currently experimental and plan to be stable in 2022. All agreed anyone disagreeing. Very good. Next one stick observability has consensus that there is wide and organic adoption of open telemetry components, which are the instrument. Can we go into just to make a question while you're making that update I have a contextual question here for somebody who hasn't been a part of the earlier conversations. These statements that you're making here these are annotations against the due diligence document or are they to be considered to be part of the due diligence document. Let me try to answer slightly differently. What we the intention behind what we're doing is we took everything which we could find from to see in ways of of due diligence documentation, which is which you'll also see in the end of the document where it starts to repeat a little bit but that's what we're going to do. We're going to look at some of the things which we could find. And we are walking through this to find consensus for each specific section and then we submit all of this to to see for to see to be able to to walk through it more quickly. It's basically the sick saying that we have consensus on this and that part of any due diligence which is how we did the three due diligence is before and which is also how we agreed to do it like last summer with with to see. As a kind of experiment if that actually reduces workload on to see or if this is more or less. Work which which which is wasted. So that's the intention behind does that answer your question or not. Not entirely it's very helpful thank you that context is helpful especially that you've been experimenting with this. What, what I, and I, I, this is my first due diligence so bear with me a moment and I've looked through the templates for prior due diligence and looked at some prior due diligence, and a lot of the questions are about the project, not about the opinions of a special interest group that that's what I'm getting at with my question is that, does this become part of the due diligence document because the due diligence is about the project, not about others opinions on the project. There are included opinion from the city and to see and recommendations are included like at the end of the dark as a summary. And every section is just read as a story about the project. The details and stuff, and all the opinions come to the end. So when the user goes over the dog, they can form their opinions and then they read the opinions of the sick and of the to see. We've taken it like more granular approach where every section has comments, but we can all think of how it will be structured in the end is definitely helpful for us as to see to see the sick recommendations on each and every item. But in the end, the dog will still be modified. So to make it like more user digestible and we can all agree on the format but whatever is going to be easier for end user and for other to see is who are not that familiar with the project details to read and understand and from their unbiased opinion about the project. And Cornelia to answer your question directly or like this is what we saw from the the to see is the question that's asked to get to incubation. This is open telemetry is response everything right here, and everything that's green or orange this is from sick observability. So right now, sick observability is commenting on each section, determining whether there's consensus that these aren't I mean there are open telemetry people here so they disagreed, they would state that, but the official open telemetry responses captured directly above. Okay, thank you that's helpful. And the other thing this document for the intense from the perspective of sick is fully owned by the project, which is why only the project is allowed to make any, any, any edits to this document, everything else is only done in suggestion mode. And the response and color coding and resolving of discussions in document is done during the call to to make sure that we all are on the same page on the specifics. So this is how it's structured which is largely copied from from how Prometheus does it internally for for the various discussions. Okay. Cool. Thank you. So, Steve, if you can move. I know you see, I just restructured the sentence likely to make it a little bit more clear and, as you saw, I just clicked accepting on those two. So sick observability is consensus there is widened organic adoption of open telemetry components which are the instrumentation libraries and the collector. All agreed anyone disagreeing. Very good. Okay. Does link to the to the roadmap on number three directly above. Yes. Okay. Yeah Richard I added it sorry. Instead of the date. We do it explicitly. Can we do it like so. That we put it. Yeah. And then we can remove it from from. From the text because it's kind of hidden. Yeah. Yeah. Thanks. Thank you. So, do we agree on all libraries or just the base single ones. So we're we're not quantifying based on signal or which one specifically we're saying that there is broad adoption for instrumentation libraries and the collector that's the number four reads as. And again that the part of doing this is to try to get the consensus because that's where we kind of rabbit hole the last few conversations was trying to make it more specific. That seems to cause some amount of friction. So the idea here is to show a sequence of what is and so above we talk about more like the metric signal, the tracing signal open metrics so we get more granular at the top and at the bottom we just say there is adoption of the instrumentation libraries and the collector. That being very specific. I'm sorry to jump in and I apologize if I missed the boat on questions but I would feel a lot more comfortable as an end user if there was a fifth statement here, expressing that all three sub projects will reach a maturity level as part of the check flag box for getting past the initial incubation because my primary concern is making any form of business decision on the second point looks very vague to me. I'm really happy you've confirmed the third point is 2022 that's great news. I would like something similar for the second point so I know that logs traces and metrics are all going to be in a similar shape by the end of 2022. Does that sound unreasonable is that saying we could reach consensus on the question specifically for number two for metrics you're looking for a date is that because because fundamentally we can get a date on the second one and we have the third one well that means that sure I can understand you want to push tracing through first now that's okay, but then we know that at least in 2022 the project will ensure that as a maturity level across all three sub projects that we're happy to use. Got it. So, from a, from a metrics perspective, our goal is to have something stable this year, 2021, whether that includes every instrumentation library I mean I defer to Ted Eloita Morgan others. But we are definitely planning to have something stable here the data model should be stable in the next month. I think it's reasonable to say stable in 2022 if you want to hedge your bets. We're aiming end of year for that to be released in multiple languages but I think end of year 2021 for metrics. No, yeah metrics is 20 end of 2021. In fact, you three. Yeah. And if you're all in agreement, I mean I'll leave you to decide the language but as an end user I just reinforce this would be really really reassuring just to have a statement saying like we do intend to do all these three things. This is the kind of target date. And if you could perhaps put that down that would make me feel really comfortable. I want to say, say end of year 2021 that's metrics. Yeah, I think it's totally reasonable and achievable. Yeah. Yes. Would you prefer that we do this as we take note of this or would you prefer that we just write it or that open telemetry writes this as part of the statement above the consensus block. You directed that question to me, rich. I to to the group. One thing is we, we have consensus on this the other is open telemetry states this and, or let's let me give you my perspective. I will just make, I will just make it so Richard, you can add the link to the metrics roadmap I'm just sharing the link in chat. It's really helpful and for logging as well like clearly stating it above above the seek observability comments just to plan. Yeah, the link to the roadmap and approximate days 2022 or 21 is fine. Yeah, Q1. Sorry, 2021 Q through Q4 is what we are. We have already published and committed to. We have a clear signal that we can broadcast that by 2022 all sub projects will be a stable maturity level. Yes. And that's what I want to see codified personally because I feel like that's something you can, I can convey outwardly. Yep. Richard, should I add that to the doc or did you get it. Yes, as Alina said, it makes sense if you link to this above and also for completely just, we can just have the number five consensus that we take note or we can just remove it I'm fine either way. I just wanted to move the discussion alone. I'll add it as a comment. And Richard even added in. So let's try this one. Call for consensus, sick observability take notes that the metric signal is currently planned to be stable in 2021 Q4. All agreed anyone disagreeing. Okay. For you. Alina and Cornelia. This one is a remnant of the discussion if if open telemetry tracing should be incubate as a sub project or the project as a whole, which was another attempt at trying to unblock all of this discussion we can also remove it. I'm fine either way. So to use up to you Richard, you can you can leave it and we can address it up to your hand off the DD. Okay. So, this is just formatting. This. So I'm just copying in this thing from a leader and I'm also self accepting this URL. Okay. This is now part of the thing about. Okay. This is a to do and we can close it. So as a project committed to achieving CNCF principles and do they have a committed roadmap to address any areas of concern raised by the community. I think that this is where we got got blocked in call one, where Bartek wanted to, to have his concern noted down so I would suggest that we just tried in. That the statement which Ted reminder you wanted to write and Bartek and just refer to this and defer any decision to to see, because then we don't have to discuss it. Sorry, what was the concern just for our knowledge, can you remind us. Basically what what Bartek wrote, which is currently at the top of this document as an as a suggestion. Can you scroll up for a second. Steve, please. I'm going to put this document at the very top. And instead of walking through this complete document is complete discussion yet again. I would suggest that we simply take note of this and defer the decision to to see and move on. Okay, sounds good. Alelita Ted, Steve Morgan. I mean, sounds good. I think the second from is that statement on the top final or is it something that you Bartek and and other sig members are going to are going to revise and republish. It's Bartek's statement. I hope he doesn't do any more revisions but I don't think he has revised it recently. Okay, I'll check with him if you want to or you can do it. The recommendation on for this due diligence document the ask was to move that into a separate doc that gets linked in because it's not technically part of the due diligence question and answer. So I think that's still an option open action item is does it stay at the top of the dock or does it move somewhere else. Yeah, I mean, be sure to go ahead. I don't really care. The document that can be part of that document. I honestly don't care. We can we can discuss that that offline as Bartek is not here to to comment right so we can we can take it offline. Okay. Oh, call for consensus sick observability differs to to see given Bartek plot us and Ted young statement. Ted, are you going to write this reply document or should I remove you from here. I thought we were going to do it as a the GC will do that as a group. Okay. Oh, tells GC statements. Sick observability differs to do to see given Bartek plot us and hotel GC statements. All agreed anyone disagreeing. I think we can close the comment by Bogdan. So we are also clean of any comments ideally at the end. Yeah, this one has this been done we were more components are stable in the initial phase and GA has this been done the last part. Components are stable in the initial phase and GA. What does he mean. Could you scroll down a bit Richie. Right. I mean, are you referring to Bogdan's comment. Yes. The, the point I think he's making is that, you know, each signal is reaching a stable state on the project. So one dot Oh, for example, is tracing stability and then metrics and then logging so we are not using a general term of GA we are using version numbers instead for stability. I also think is, I also think his point is that the first bullet will be when we mark the data model stable, the stable notion for the data model does not mean GA of open telemetry. I think what he means is only when this one is done, will the projects have traces and metrics be GA is that you're reading a little bit. Yes and no because there is two parts to metrics completion right one is of course the data model stability and then the implementation stability and that implementation stability is what we are guaranteeing by the end of this year. Like you for move the model. Yeah. So again, what is the best way to word that. I think we just follow up with a Betty please clarify is what he meant and we just move on and do not close it right now. Yeah, that sounds good sounds good. I'll take an action item to follow up. Document that the project has a fundamentally sound design with an obvious critical compromises that will inhibit potential widespread adoption. One of those where we got bogged down in call one, I would suggest that we simply copy copy and paste the consensus from section number four, and try and find consensus on that statement. Does that sound okay. Yep. Okay. Sorry. Stick observability deserves a stick observability the first two to see given Bartek blockers and hotel GC statements. All agreed anyone disagreeing. Yes, that is done. Perfect. Did you mention the semantics. Would you like to wordsmith something to Alelita as per Yana's comment. Yeah, I think that Yana has a fair comment. I add that in. Do you want me to add it in. Yes. Yes, please. While you do this, I'm going to, to resolve the revert comments. Sorry, who's modified the dog. Is it. I was adding to be to reflect Yana's additional comment. Yeah. Okay. So I'm going to resolve your comment as it's copied over and also accept. I think we can try the big one here. And go for this one. Stick observability is happy with the section above. All agreed anyone disagreeing. Okay. Good. Document that the project has an affinity for how CNCF operates and understand the expectations of being a CNCF project. I think that is more or less a given. Sorry. That side comment should not be made by a chair. If anyone disagrees, feel free to speak up. I don't think so, but yeah. Don't feel impeded. Okay. Okay. So stick observability is happy with the section above. All agreed anyone disagreeing. That link. If I remember correctly, there was this circular discussion about if signals should be split out into this adopter overview or not. I don't have a strong opinion here. What do you think Alina and Cornelia course you will need to do in the future? I don't know. Sorry. Split up like the end user adopters or. Yes. There was a circular discussion within the due diligence. If the split up by components is enough. Or if it should also be split up by which signals are being used. Traces, metrics and logs. I feel like from, from, from my, I have me as an end user as a separate field. Alarita Ted, Morgan, Steve. You okay with this? I mean, we can, Alina, we can modify this table to be more specific on the signal. So I mean, is the, are you asking for another column here? Yeah. Yeah. Having a separate and having a signal as a second column would help. But again, like it can be done. It can be done offline. It doesn't have to be done right now on the call. Yeah. I mean, one comment that the signals are component specific. So you'd have to map each technically because like it's possible that I've adopted metrics for the collector, but only traces for Java. Okay. I guess if you can table that, I want to understand it more. And how easy it would be to split. Do we have this knowledge about the end user adoption of a certain component? Yeah. So Richard can be like as a, as a point. For that I don't mean. We can definitely provide that detail. It's just that Steve is just noting that. You know, it's a two way. It's a multi-dimensional matrix. Yeah, I understand. Maybe if you have more than one table. That might help. Maybe a bit too much. What end users are really looking for. We TLC are really looking for other send users. Our adopters of metrics, logging or, or tracing. We don't like, we don't look at on per component specific. Like is it a part of collector? Is it a part of something else? Okay. So you want to have the table with a focus on signals, not components. Correct. Not necessarily a table can be a field, but again, it's okay. Sorry. I'm a quick question on that note. Is it generally except expected that the signals. And the collectors can be decoupled. Or is it like, is it possible to actually use a tracing without the collector? Yes. Oh, yeah. Okay. So it's not expected that you would use the collector. Like you can, you can use whatever collector you want as. Like if it's, if it supports the signals. You don't even need a collector. Like the instrumentation could send direct to a back end. So there's flexibility and choice. Like if there's a reference architecture where you could like, we would typically recommend it because you probably want to like, have infrastructure correlation with its limitry data being emitted from your application, but it really comes down to business requirements. So if you didn't want to, you could just take a dependency on an instrumentation library and send direct to a back end if you wanted to. Gotcha. Yeah, so maybe the signals could be a column and the collector could be another column. Yeah. Basically I want to plus one on Alina's comment around having a more details around what, which adopter is adopting what. So I added and sick to that, to that information line. And basically now we have that you do in here. Let's maybe even make it like so. Of course, then it's super clear. And then we can have a call for consensus. Take off. So ability is happy with the section above. All agreed. Anyone disagreeing. Very good. Or number seven. Do you want to make it green? You didn't highlight it green. Like you did with other sections. Oh, yeah. I absolutely do want to cause this is. Yeah. Yeah. Thank you. I marked it green. I know we had consensus cover this and it was positive. Thank you. This is else my system breaks down. So yeah, here we revisit stuff, which we had already resolved and call one. And I suggest we do not revisit any of those. Now we come into the. Into partial. Repetitions of what we have above. Okay. Please make a list. Okay. Steve and all. Is there any update on this discussion? Yeah. So we, I think we landed with Bartuck's message of major ones are fine. So major ones are listed. So I believe this is resolved per Bartuck's ask. Unless someone thinks more information is needed. Let me, let me look at the. It was done in the other document. Yeah, they didn't go into major, but. Yeah. So the reason why we didn't list everything is because the collector alone has like 2000 dependencies. Like it's not going to fit in a doc. And I don't think it's useful for anyone. So requested to do it by major components. Those are listed. Yeah. I mean, I don't know if you have any questions if people want to see this in a different format or way. Yeah. And so the requirement is that, you know, they're a battery compatible, right? I mean, we do have to do license checks. We do do that. So. We can definitely list out of full list. Required. Um, there is one missing for open JDK. I just Google it seems that GPL to should we just add this to this file? Yeah, that's fine. So I'm adding it. So someone from open telemetry needs to click the accept button. Just a moment. It also has a linking exception. So that's good. At least according to Wikipedia. If someone from open telemetry could click accept on this. Thank you. And I will also resolve the discussion above. Anything else that is done. Perfect. So we are going to go through the, the larger blocks. So we are walking through the larger block. To. So to clarify here. Signals are not considered a major part of the spec. Is this correct? Or another major component. So they're not a component. The signals are a separate thing. So the components are the specification itself, the instrumentation libraries and the collector. In those components, there are signals. They are not components. Okay. Okay. Yeah. Okay. Fine by me. Anyone else with comments. Yeah, just to clarify that they are part of the specification very much. So this, the signals are very much part of the specification, but they're not if it's components. That was the only clarification. So to ask this differently, should this in the opinion of open telemetry be part of an architectural design and feature overview? If not, we can. If yes, then we just write it in. I don't care. Both is fine. Yes. Both. Software components as well as the signals are part of the specification. Okay. Do you want to write something in or should I. I mean, we can link to each of the signal. Section in the. So the link is to the specification directly like the specification lists a lot of stuff, resources, cemented conventions, what have you, I don't, I didn't list all the sub things. I mean, the same applies to the collector. The collector has a bunch of receivers, exporters, extensions. Like I just listed it by major component. So we can make it more specific if that's what people would like. Or we could just link out and say these are the three major blocks and there are of course sub blocks within these blocks. Would be useful to have the sub blocks. Again, it doesn't have to be a part of this doc. It can be, it can be somewhere else, but having some sort of architectural diagram for user to understand what each component consists of would be super useful. Alelita, we broke this out in a, I think another doc for this review. Do you know what I'm talking about? Yeah, yeah, we did. So we can Richard, you, can you assign me an action item? I'll make sure that the links I added. Okay. So I will close lists and texts comment. Yeah. I will close my own comment from February. And we just put something here to what document to link to. I don't recall what the purpose of that doc was. I thought it was related to incubation though. Yeah, it was, it was to clarify the more details on the, on this section, the architecture and the feature overview. So Richard, you could just say link to the architecture doc. I led a link. Okay, like so. Yeah, sounds good. Thank you. Okay. Then let's do a sub consensus here. Well, we say sick. And this now includes everything up to where we walked. Sick of some abilities happy with the section above provided it to do is close by Alelita. All agreed. Anyone disagreeing? Oh, wow. We've now reached the place where we were in February. Okay. We're making progress. That's actually good. Okay. So just to make sure you're still aiming also for an IDF release for what specifically within open telemetry. You're a little bit too low. I want you to close the other sec. We can also make bigger jumps again and find it either. That's the only thing which stood out to me. Of course, having just done the dance of it. They will want you to be super specific about every single thing. And it might be that you need to split up into several RSEs. So do you want to put in here what specifically you want to release under it or just as a general statement of intent. I deferred Ted, I believe Morgan was talking about OTP, but I don't remember. Do any of you know. Yeah, I think Steve, that was the, that was the comment Morgan had made. Yeah. It was specifically related to OTP. That's the only piece that would, I think realistically follow up and do their purview. Yeah. Okay. Okay, so I'm adding OTP. And someone from. Thank you. Okay. I'm also removing that marker from February 2nd. Okay. This is a new comment. Can you provide a reference to that documentation? Referring to this one. Yes. Yes. Okay. So a link to what in this case, this would be the collector scaling up and scaling out as well as availability. Is that the specific ass? More specifics. Okay, so we have a question. I have a question about the failure node documentation. Is that the software parts of the project or like the testing? Is that the awesome. So basically here you're saying those known are tested or documented. Is it about like the failure node documentation? If, if you have a reference to this failure node documentation. Attaching the link with help. Okay. Yep. We can add it. Should we assign someone specifically to close this course. Then we can just, or we can also just do it like so. I'm happy to take it. Okay. Okay. Provided. Provided the documentation. What specifically, Alina, everything which is. The one that the team is referring to is those are known are tested or documented. Okay. Also integration performance testing or just failure modes. Any kind of the documentation that kind of like shows the details of our performance. Or failure nodes exceptions would help. We can put this. Steve, we are at time as per usual, but I think we will run over the 10 minutes as per usual. I'm sorry, but I'll have to drop around 10 a.m. for, for another call. And maybe we can skip through my comments. Like my comments are directly to open telemetry team. And I wonder like if there is anything that is unresolved from the SIG that might need. My input. I think we have this one. Oops. This is for the ones to do. So the security is yours. Four minutes. But. So there's one comment by Peter Bergen and the rest. We haven't walked through yet. So we don't know if there will be disagreements. I hope not. But for your points, Alina. Also, I was just saying that at 50, we are at time. So we are currently at time for this call, but we will run until the full hour. And then we'll have to go through this document and finish it. If you need to drop off in eight minutes, we can just all, I also have a hard cut for a different cause. Okay. So make sure that we are, we are clear on the, on the action items. I don't know if you're going to have time to resolve all the comments by the end of the call. So maybe five minutes to 10. We can decide on what to do. Okay. Okay. Okay. Next one. Let's just say. Provided that Alina's comments are addressed because that makes it easier. I would be fine with this. As written. And as Alina's TOC, she will catch this anyway. So for the intents and purposes of single observability, we can just hand this off. Okay. Okay. Okay. Next one. Let's just say provided that Alina's comments are addressed because that makes it easier. I would be fine with this. But if we can't do this. So. We can just hand this off in my opinion. So the parties section. Richard, I had a question. Again, there, I'm looking through Alina's comments and. Alina, you've asked for, you know, several areas where you would like to see more links. Should we add that. To this document or. Yeah. If you have them. Yeah. Okay. Thank you. My intention here is to move through the document at speed, just referring to Alina's comments, which allows us to not wait until they're fully addressed before we find consensus. So we can. So. Single observability is happy with the section above provided the comments by Alina are addressed. All agreed. Anyone disagreeing. Good. Okay. All right. Are you calling that one green? It's not. I'm. I'm lost. Where is this? There's a huge discussion here. Richie, the one above. Do you want that to be green? Yes. Thank you. It is green. I just didn't accept the marking as green. Yeah. There we go. Perfect. Thank you. Okay. So here's a huge discussion. Okay. That's a distro. Okay. We can just refer to his comments and. And. I guess. Of course he, I think he even walked back on the distro concern to some extent. Oh, there's a second comment. So the collector is not stateful. It's completely stateless today. It's completely stateless. Okay. Is this true? If you support open metrics where you need to have, where you need to have cumulative. So today it doesn't support that. So as of right now, it is completely stateless. Yes. But as you want to support it by May. End of May. It's. Like that. That's a cyclic discussion. Of course, if you currently are not stateful, you're not a stateful state. You're not a stateful state. You're not a stateful state. You're not a stateful state. You're not a stateful state. You're not a stateful state. You're not a stateful state. So can you write something about how you plan to address. State. Scalability and complexity. Assuming we'll do that as part of actually implementing it's like, I think projecting when we don't even have the design of the data model finalized yet, it's kind of challenging. We can make a note that's clearly ensuring that the data model finalized is not a stateful state. And that would need to be addressed as part of implementation. Which as far as part of comments is concerned is, is, is what whole he is. Or potential or what have you. Is what he's pointing to it. Well, I'm. I read it as its current state. Currently, there is no state whatsoever. Like right now there definitely isn't. In the future, there might be. I gave a different example, which is like a dispatch queue. It might be the state that would be required for say the login use case and then clearly cumulative counter, like metric type stuff. You might also need states. Neither one of those exists today. Fair, but as we just put. That you are planning to support permitted in open metrics. That will mandate state in the future. Morgan keep me honest, but. This is something which, which from the open census site has been clear since 2017 that Yeah. Yeah. I think the margin has dropped off. Oh yeah. Okay. Is persistence being listed here sufficient or what would you like to see specifically? So one of the most important holes, possibly persistence. Is there, do you want like specifics of beyond tail based sampling? You want to see like logs added, cumulative counters for metrics or open metrics support added. Would that make it more concrete? I mean, Richard. As you, as you highlighted, you know, the current work that is ongoing in the. Prometheus work group for open telemetry is going to address that we're working on the design right now. So would you like to see more detail there once, you know, we can link to the existing design docs that are in flight. And that could address. You know, specifically the open metrics dependencies. As well as. Pulling off my chairhead for a second and putting on my open telemetry member. Head on for a second. How about we, and now I say we as an open telemetry simply state that this will be implemented and as such needs proper design and performance testing and done. Yes, that's absolutely. As far as I, let's, let's just. Okay, how about so. Sounds good. Thank you. It's already 10 am. I just want to, I just want to follow up on what the next step should be like the document will be handed to to see are there any results, big unresolved comments from the city or you think we are mostly good. The honest answers I don't know course we never talked about this section. We are in territory which we haven't talked about before. I see one comment by Peter Burden, but I don't know what he means precisely. If you Cornelia and Alina as members of to see. Tell the sick that we can simply stop doing your diligence. I'm happy with the document as such. We can stop doing this. This intelligence work. If you want to, if you want to seek to finish. It will be the next call, but after the next call, we should be done. I don't have an opinion if you want to just pull it into to see right now, say so and done easy. If you want to seek to, to, to find consensus on all the points. I don't care. We're never reviewed. Is that correct? It's never been live reviewed. I know discussion about any of those happened part of why we caught close many of those before where, of course, we did look at them in the past. So what you up to where we are, this has been found consensus on by sick observability. The rest not yet. Okay. One of the questions that I. Go ahead. Yeah. One of the questions that I would have is. First of all, I think that if we hand things over the TOC now, which is where I'm kind of leaning. I would hope that. Sick observability would continue to partner with the TOC to provide feedback. Should we have questions? Either synchronously or asynchronously. Yeah. So what I'm thinking is I would like to put this to the open telemetry team. And say, would you find it helpful to continue to do these things? Or how do you feel about handing this over to the TOC now? And again, going into the motive. Elena and I will begin our work. This context is super helpful, but where we're missing context, because we weren't able to go through the entire document all the time. So I think we're going to go back to both the open telemetry team and the sick observability. So I guess I'm asking both teams. The sick observability and the. The open telemetry folks. To let us know, you know, I assume, but I don't want to assume that you're okay if we take this and then circle back with you with additional questions and maybe pull the team together to discuss something. Yeah. And the next call is in two weeks. Or is it next week? No, it's in two weeks. Um, okay. I wonder if, yeah, that circle back to sick can be, can be down offline as well. So we have, um, we have some answers this week or next week. If me and Cornelius are doing the DD. Right away. Yep. Sounds good. And Elena, for all your questions again, there are links on the testing on the security reviews and others. So we can definitely add those in. Okay. And I believe Cornelius also, um, gonna post more comments to, to the dog. Sounds good. Yep. Yep. So the dog is not finally yet. Yeah. That's what I wanted to say. Okay. So just to also reply from the sick point of view. Yes, of course. Um, that's part of what the city is there is there for. Um, so just to close at where we are, um, we will take one more minute and then we're done. I'm, I wrote this with my open telemetry head on, which is in, which I'm now pulling off and I'm putting my chair head on and accepting this comment. Um, sick. So call for consensus. Okay. So sick observability is happy with the section above all agreed. Anyone disagreeing? Very good. And now I'm just putting in that sick observability stops doing interactive due diligence here and basically switches into TOC support mode. Okay. I apologize. I have to drop now for another call. We'll sync up with all of you in Slack. Okay. Thank you. Bye. Go to TOC. Okay. I'm marking this as orange as it's informational. Sick observability stops DD at this point and hence over to TOC standing by with further assistance. Oh, telegries with this. Sounds good. Very good. Okay. Let's make this a little bit bigger. Yay. We're done. Um, cool. Thanks. And thanks for not going in endless discussions this time. I think this was pretty good. See you in two weeks. Thanks, Richard. Appreciate it. Thank you again. Thanks everyone. Bye.