 Hello. Hey, Matt. Yes. Hi. Thank you. Hello. And hey, John. Good morning. Hey, Hong. Is that how you pronounce it? Are you there? Hey, yeah, this is Hong Chi. Well, hello. So what's with myself? Yeah, what's company are you with? If you want to be associated with the company? I'm with Alibaba Cloud. Okay. Got it. Thank you. Hi, guys. Hey, Remy, how's it going? I'm tired. COVID-19 in my daughter's teacher's school. I think everybody's tired these days. Hey, Tommy. Yo. Yo. And Daniel. Hello. Is this your first time in? I don't remember for sure. I've sat in on the SDK part of the meeting before, but. Okay. What company are you with? If you want to be associated with the company? Sure. I'm with Google. Okay. I can spell that. Thank you. Morning. Morning. Hey, Colin. Let's see who else do we have here. Ray, are you there? Yes, I am. Hello. And Miss Ginger. Howdy. Howdy. Hello, Eric. Good morning. Hey, Lance. How's it going? Good. How are you doing? Pretty good. I don't know if you noticed in Lance, but Slinky opened up a PR for the roles for approving new maintainers for the SDK stuff. We're not going to prove that today, but just want to make sure you saw it the way you take a look at it. Yeah, I did see it and I started to look at it before this meeting, but I thought I should really not try to rush through it. Yep. Okay. Cool. And Klaus. Hello. Hello. Just give another couple of minutes. I don't think we have a very long call today, although we don't have anything on the SDK agenda. So if anybody has anything, please go ahead and add it. Otherwise, we're probably going to just skip that call today. Hello, Brian. Hello, Doug. Good morning. I guess, but close. Yeah, almost. Hey, Mark. How's it going? It's an awesome day again. I don't have to commute to the office. I was going to say, you know, it sounds like ever since you moved to the new house, you've been chipier. You know, being able to not have to commute. Wonderful thing. I can imagine. Yeah. A couple more seconds. Let's start at three after. All right. Let's go ahead and get started. It's three after. You got one more person. Hi, Hamid. Are you there? Hello. Yes, I'm here. Excellent. Welcome. All right. Let's get started here. Community time. Okay. Anything from the community that people like to bring up that's not on the agenda. Okay. I'm not hearing anybody. SDK calls. We have one scheduled after this week. I'm sorry after this call. Nothing on the agenda as of right now. So if you have anything, please add it to the agenda doc. Otherwise, we'll be a very short call. One thing we probably should talk about though is we originally scheduled that to happen every week because for a while there we had a whole flurry of activity going on and lots of things to talk about. I think if I remember correctly, the last two or three weeks, we really haven't had a whole lot to talk about. And I'm kind of wondering whether we should switch back to every other week. We don't need to discuss that right here, but think about that. And maybe as the only topic for the SDK call later on. Let's see. Timmer is not there. Anybody else from the SDK? I'm sorry from the workflow. I don't see anybody. So nothing. Nothing is anything update there other than I will say that every now and then he pings me to tell me some good news about some other company getting involved and wanting to collaborate with them. So it does seem like there is more and more attention popping up around the workflow spec. So if you've had any interest in the past, you may want to pop that back on your radar to take a look at it because it does seem like it's getting more traction, which is kind of cool. And okay, so before we jump into the PRs, is there anything on the agenda people need to add that I forgot to add. All right, in that case, let's jump right into it. Bring data def gem. Welcome you just joined so I'll let you talk to this one. Yeah, sure. So this was something that I can't remember who raised an issue for because the Jason schema definition was not entirely aligned with the specification document. So, in the spec it basically allows the data construct to be any Jason object, whereas the our original schema just had objects and strings. So, all I did was add all the other sort of potential Jason types that could be present. Cool. Any questions for Jim, any concerns. All right, any objection to approving done. Thank you everybody approved. Okay, typo. I think Remy this one might be yours if I remember correctly. Yeah, it's mine. Okay let me scroll down to the non typo things just refresh everybody's memory about the big change. Yeah, I think there was just a mistake in the spec on the type of return because obviously it's a map and it was written as an array. So I just did that. Yep, more of a syntactical error type of thing so. Okay, any questions or comments. A question sorry. Yeah, that example is no right isn't it. The, it used to be a map. Oh wait, it used to be an array. Yeah, I basically it's a map because like you have the name like it's invalid syntax. Previously it was an invalid syntax as an example. Yeah, I think when I wrote that up my original intent in my mind was a map I just for some reason wrote everything as an array I have no idea why I think it's just a brain part. All right, any other questions or comments. Any objection to approving. All right, done. Thank you everybody. Next. See what this one is. This is Grant. Grant is not on the call and neither is Christoph so. Okay, I'll try to summarize this one as best I can. Let's see. So Grant was bothered that the specification talks about two different types of modes structured and binary. And then he noticed that in the ACP spec we then talk about batched. And he was looking at that as another mode so he was bothered that there seemed to be an inconsistency where we're totally talk about two valid modes but then we introduce a third one someplace else. So we thought we really should add some text in here that says, Oh, by the way, transports can define other modes. Well, Christoph pointed out that there's that batch isn't really another mode. It's just a different flavor of structured. So what he added recently, and we will help with the wording yesterday on this is to make it clear that the transports themselves may modify. So technically either one of these message structures right maybe add some sort of wrapper is necessary for the transport, or in the batch case it can actually add more than one event into the message itself. So it's a different flavor of sort of massaging of the events themselves for a particular transport so but either way, you still have the basic structure of, it's either binary basically just the raw data versus it's a structured mode where the cod event attributes themselves appear inside the message body as opposed to like ACP headers and stuff like that. Okay, so hopefully this text in here makes it clear that transports can define theirs, which they do today in ACP so it's technically down to the changing a break and change the spec or anything. And he just adds clarification that this can happen by adding this may right here. Any questions about that Jim your answer. And so just a quick question, you know when these transports add these extra representations to be compliant do I have to implement all of those as a transport provider. So, for instance when you we add, you know the request to add batching or streaming. Is it then a requirement all trans all ACP transport implementation support those other modes, or do they become optional that that was the only. It's not really related to this spec but it's related to all these sort of quirky transport things that have been popping up recently. That's a good question and I believe that's what I want to double check. I believe that the specification will say when it's required, I just want to see if that's true, because I'm pretty sure batching is not required. I just want to see. So I'm trying to see if it actually says whether must support it. And I guess that also then plays into your discovery stuff because now all these different modes need to be advertised through that discovery mechanism as well. Yeah, so I'm not seeing it jump out at me but let's take that one offline because I think that might be a good clarification in general for some specifications someplace. Maybe it's the main spec to make it clear that this that it is optional and the fact that it's what the nets made for the spec can define it but it's not clear where you have to support it. So yeah, you might have to take that offline and deal it as a separate issue. No, absolutely. Do you want me to open it as an issue just in the program. Yeah, that'd be wonderful. You can open that up remind us to go back and double check that because I believe the intention was something like batch is not required. But I have this vague recollection that we do require them to support the in general binary and structure that you know the simple version of those. I don't know for sure. Yeah. Okay. Okay. Okay. Doug, hold on. I'll make a comment here. Okay. Thank you Doug. Oh, sorry, Brian. I missed that. Okay. Either way, he'll get noticed and update it. Daniel, your hands up. Yeah. So I'm, I think grant open this partly because of my confusion as I was doing some related implementation. So, I think, I think my confusion was still that there's, there's this There's this question of, okay, so if we're going to call it different forms of structured mode that that's great. Then can we make that consistent across the so the protocol binding specs still called it a mode as still treats it or listed as a separate mode, you know, separate from structured and call it a mode. And so forth. And so, and so there's still this idea that and even there's a separate section 3.3 bash content or mode that's in parallel with structured and binary. And so if can can we be maybe be a little bit more consistent as to kind of what the what the the taxonomy of these things is across the different specs. Yeah, no, I that's that's an excellent point because you're right if it's not a separate, it's not a third mode then we probably should use a different term for it. Yes. And I think that might clarify some of the questions about or what's required and even by Yeah, just because we're using the same terminology. Can you do me a favor. Can you add a comment to this PR to that effect that way Grant knows he has a little more editing to do. Let me see what what number is that PR is 660. Okay, yeah, yeah, I'll paste the link to it in the zoom chat for you there you go. Hopefully that's a very minor change, but he's, but we should probably make it as part of the same PR. Any other questions on this one. I mean, aside from that, hopefully syntactical change, do people agree with the general direction this is going and are and are okay with it. Okay, not hearing objections and then we'll just see if we can get grant to make those final edits, and then review it again next week. Okay, anything else before we move on. Perfect. All right. Thank you everybody. Okay, this one. I think this one's mine. Let's see if I remember what I did here. Okay, so this one was mainly cleanup. Basically I decided to move the governance stock which was all by it's the SDK governance doc which was in a director all by itself into our community directory to live with all the other governance related documentation. For example, our main doc our main governance doc is in here now as well. So I put this one in there and just call the SDK governance. Really, I didn't do any textual changes in here it's renamed the PR and maintainer guidelines because these are actually for the SDKs. So just rename those to put SDK in front of it to make it really clear it's about those. And then the main read me. I just added more information to actually point to these documentation to these new documents that are in there. Obviously change any of the specs just moving things around in the repo more than anything else. Any questions or concerns about those any objections to approving. All right. Thank you. All right. Okay, next one is mine as well. So this one I mentioned last week as a as a warning I might be opening up. So last week I talked about how there really wasn't a good mechanism to make it so that when a client queries that discovery spec, a second time to know whether the metadata about a particular service, if it's been changed is a brand new service, or it's replacing an existing service and they just tweak some of the metadata, because there really wasn't any field in here identified as having to be immutable across these queries. And I was originally thinking, well, maybe we should make the name immutable, but then a camera who was somebody pointed out that maybe that's not so great either because what if there's a typo in there or for whatever reason they need to change that. But it is still technically the exact same service. So that's when I defaulted after thinking about it and said, okay, let's just introduce an ID. That's globally unique. And it's a UID. And it's basically just uniquely identifies the service. The value must not change has to be a UID per RC 4122 relatively simple thing conceptually the only real question I think for the group is, do we want to add this as a field there that's immutable to allow people to do this identification for when things change. Any comments questions. I think everything else in here is just modifying the samples and stuff like that. Oh, I did change this. Other places I was using curly braces around variables and I missed one here. So that was it. Klaus, you're going to say something. Yeah. So the name is also still unique. I think it's, I think it's the requirement says that is. Yes, I'm sorry you're a must be unique but not it doesn't say it has to be immutable. That's the key part today. Okay, so I'm just wondering because I think in Kubernetes we have similar concept that you have a name and your ID for objects and it means a different thing. Slightly. So, even if you recreate something with the same name it will then have a different UID so is that intended to be something similar here or the same intention by this was yes if if somebody does something like they they first have a service called foo, and then they changed its name so it's now called bar, and then someone else comes along and creates another service called foo, even though it shares the same name as the original service, it is a completely different one because it will have a different UID. So I think in conceptually I think it is similar to Kubernetes but I definitely did not model it after Kubernetes. It's just what it reminded me of but yeah of course you see those concepts all over. Yeah, it's just Kubernetes is a slightly different right because in Kubernetes you actually can't rename an object. Yeah, that's true, which is actually really annoying but that's different topic. Why have both right why have a unique ID and a new ID but you can delete it and create it again and then it still has the same name but although it might be something different. Yeah, I know we're going to rat hole in this but sure why not and it drives me nuts because you can actually get into a weird state where things are referenced by other things by by just name sometimes and you can get a bad reference to a new object that you didn't mean to actually reference it gets really really ugly sometimes. But anyway, back to this one. Any other questions comments by anybody. I have a question. Didn't we talk about this at some point of having it in the spec and then we got removed. I mean, it might be worthwhile going back in. Get history and just see whether there had been one, because we, we had, we added a whole bunch of these, and then we went back to more minimalist. Are you talking about the discovery spec or the C spec. Oh good point. I was talking more about the, the C spec sorry. Yeah, that may be true I can't remember for sure but I don't recall one in the discovery spec. I'll go back in history. Okay. And obviously if for some reason we decide this is a bad idea, assuming we prove it today, you can always rip it back out again later as long as, as long as I said the use case I'm going after is to make sure that if the metadata changes, I want to know as a server, which is now to change versus not, and this, as of right now makes it so that you can change anything, except for ID. And then as a client I want to be able to know how to uniquely, how to uniquely identify an object to know whether it's a new thing versus just updated metadata. And if you want to solve that a different way I'm okay with that I just, I just couldn't think of another way to do it. Okay, any other questions comments. Any objection to approving, or any reason we should hold off and give people more time to think about it. I would like to think about it a bit more. Okay, that's fine. No hurry. Okay. In that case, there's any discussions otherwise we'll move on. Okay. In that case, this one, this one was just opened today so we can't approve it, but I just want to draw it to people's attention. Thanks for coming up. Thanks for coming up. We were missing some documentation in the SDK governance doc about how new maintainers get added, you know, what kind of voting process there is how to get nominated stuff like that. So this is his first initial pass at it. Obviously this matters most to the SDK folks so at least those people please review it when you get a chance but obviously anybody in their wider group. You can go ahead and review it. It seems fairly straightforward. We want to tweak some of the wording just because English is not his first language. But aside from that it seems like it's fairly consistent with what I see in most communities. Anyway, take a look at that when you get a chance. You also add a little section here about how to update this document itself. I think that was missing as well. And I think the rules he defined here consistent with how he updated the main governance doc itself. Any comments on that. Okay, please review that when you get a chance. And I believe, Jim, we're not ready to talk about protobuf yet, are we? No. No, thanks. Okay. And I believe Francisco still wants to hold off on these two. Okay, so I think two weeks ago or so. We talked about possibly reviewing where we were relative to the implementations of the discovery spec. I'll raise my hand first. I have started. That's how I identified some of these issues that have been opening up. I'm not ready to share it or discuss it or do any interrupt testing with it yet, but I have at least started the process. Anybody else want to raise your hand to give an indication as whether they're starting on that any feedback they have. On my side, I did an implementation in JavaScript. That's how I found out about the spec issue. I didn't work on the last seven days to be honest. I kind of stopped, but it was a kind of walking version. I could probably do a demo, like not today. But from the next call, I might be able to do something. Okay. Yeah, if we have time by demo, we really kind of cool to see something in action. Like, like, like, like you in the last week, I didn't get a chance to actually work on mine. So I'm hoping maybe this weekend to be able to work on it. And then maybe we can, you know, show each of our clients talking to each other's servers or something like that. That'd be kind of cool. All right. Any other topics or any other discussion around the interop or implementation side of things here? Anybody else want to raise their hand in terms of thinking about working on it? Okay. In that case, we're technically at the end of the agenda. Are there any other topics people would like to bring up? All right. In that case, we'll find, we'll do final roll call and then we'll jump over to the SDK call as short as that may be. So Doug, are you there? Doug, you looking off mute? Okay. What about Lucas? Hello. Hello. And Manuel? Hi. Hello. And Vinay. Whoops, spelled you wrong. Vinay, are you there? Yes. Excellent. Good. Okay. And I got you, Doug. Thank you. Did I miss anybody else for the roll call? All right. In that case, non SDK folks, you're free to leave. Thank you for joining. And we'll start the SDK call in just about a minute or so. Thank you, everybody. Oh, fudge. What was the topic I said we should talk about? Oh yeah, meeting times. Oh, we're getting an agenda. Excellent. Thank you, folks. Lance was this yours? The proposal to vote. Yeah. Yeah. Okay. Cool. Don't make sure I put the right name in front of it. Okay. We'll wait till 26 after the hour that we'll get started. And just for fun, we're waiting. Brian. Doug, Daniel. Not that it matters. All right. 26. Why don't we go in and get started. Lance, you're up first. So there was a proposal to rename the SDK from cloud events SDK to just pure cloud events and kind of following some of the guidelines that slinky did put together for, you know, voting on other issues within an SDK. So this might be a good issue to vote on, because it's been, you know, there are disagreements about it. So if anyone has an opinion on this, I would appreciate an up or down vote. That's it. I'll raise my hand. I've got a question for you. Do other SDKs have a similar concept to like a module where they have the same kind of naming question in front of them? Are you asking me that? Yeah, you or anybody else. I was just curious. I'm just wondering whether it's a, whether it's a JavaScript specific issue or whether all SDKs are going to run into the same problem. Well, I mean, I guess, you know, for each one of the SDKs, they all have their own unique names. But the specific concern here is that that, you know, there have already been a couple of releases. And, you know, this will just break existing usage. But, you know, there are ways around that I suppose by emitting, you know, deprecation notices and stuff like that when you do an installation of the SDK. Probably not really an answer to your question. No, that's fine. That's okay. So I guess my other question is something that you mentioned. Obviously breaking backwards, breaking existing people are using it is obviously a question. Is, what is the consistent or what is the pattern that you see in the JavaScript community around stuff like this? Do they normally append SDK type things to their modules or do they usually not do that kind of stuff? I don't think that that would be very common really. I mean, typically a module name should just say what it is. And in Grant's point is that this isn't really an SDK. You know, I can kind of see it both ways, especially if we start to do things like add the discovery stuff to it, it sort of creeps a little further along that continuum towards something larger than just a little module. I mean, if I may, it happened also, like when NPM just basically released their organization principle. So with the at something. Usually what people were doing is like they moved to organization and then they were doing like a code mode to automatically update your imports and change your code base. So we could maybe provide a code mode to do that. But basically go for the import and update them automatically. I'm sorry, I didn't, I didn't quite follow that. I hate to ask you to repeat yourself, but Sorry. Like basically it happened with the organization. So sometimes it happens like react. But you have a code mode. I don't know if you ever use that one. It allows you to define, like to basically introspect the JavaScript and TypeScript and like modify it with the introspection. So you can automatically update all imports into a source code. So some people provide that and then in one command line, you just update the whole naming. Right. So I'm, I kind of agree with Grant to give my opinion. So I just press one. So Lance I noticed that you voted no on it was your biggest concern just the, the idea of breaking existing people. Yeah, pretty much. Okay. You know, and I, and I recognize that it's not a huge community of users at this point, but there are people using it. So, yeah. Okay. Anybody else want to chime in or vote. Okay. Was there a specific action Lance you're looking for here or was it just to raise it to people's attention so they should vote if they, if they have an opinion. The ladder. Okay, cool. Thank you. Yep. All right. Thank you for bringing it up. It's an annoying question, but something it's not unexpected. All right, Daniel. Yeah, this came from a discussion brief discussion on the slack on. So it looks like for a bunch of languages, maybe most languages. We're releasing libraries to our package managers under our kind of our personal accounts on the package manager. And I wanted to ask about what people think about having potentially kind of a cloud events account that maybe multiple people would have access to for, for the package manager releases. So that, you know, for example, someone drops off the maintainer list and now we can't release the package because it's under their personal account and things like that. This is a practice that we've been doing for most of, like, Google's library releases where we have group accounts that belong to a team. And so anyone within that team can can release libraries. This came up for me because I was doing the first releases of Ruby SDK and trying to figure out, okay, well, how should I do that? Should I use my personal account in RubyGems or Ruby package manager? Is there a kind of a common practice for group accounts? So I guess I wanted to see what people thought about. Is this an issue that people are concerned about? Is it language specific? What are the thoughts? So my hands up, I'll go first. I think it's a good idea. I honestly don't know how the SDKs are handless right now. I think most of them are probably using their personal account for things. At least that's been my experience from what I've, what I've interacted with folks. I'm like, they're using their personal accounts for like, I don't want to say Travis CI, but it's one thing I think of that kind of stuff. Even though I don't think it actually is Travis CI, right? And that's not good. And so like my real question for you though is, in your experience when you've done this, is it just a matter of the maintainers just through back channels? Share the password and user ID or whatever for these systems? Or is there something a little more formal and where this information is stored? Yeah, that's a good question. When obviously when we do it in Google, we have mechanisms within Google to share secrets like passwords within within groups for a group like this. I'm not sure what the best approach for that is. I'm, I definitely open suggestions and we could just back channel passwords. But maybe I'm actually not sure what tools might be available to do that effectively. So let me pick on Lance for a sec, because Lance, I know nothing about JavaScript or MPM, but I'm assuming in order to upload stuff to forgive me, use the wrong term probably MPM repository, whatever it's called. It has to be an ID password protected, right? Who owns that today? So it was Fabio had it, and then just added me as someone with the rights to upload to it. So, you know, it's not a single person that can push the MPM package, but it's a select group of people that are determined by, you know, I guess the maintainers. Okay, so it was slightly different scenario. Does anybody know if there is an SDK out there that has the similar situation where it has to be a single password or identity? Just to clarify for for Ruby, at least it doesn't have to be a single identity. You can have multiple owners. I guess that is another potential approach for package managers that support it, just to have several people, all like all the maintainers own the package onto their personal accounts. I'm just thinking about the group idea as a formalization of that, but if that's not feasible, then maybe just having multiple owners would be also a way to play forward. So are you concerned pretty much just about the Ruby SDK? It's, it was, yeah, it's a Ruby SDK because I wasn't sure what our practices, because I wanted to release and how should I do that. And so it's kind of a question for the group, you know, how are we doing this as, you know, as all languages for cloud events? Is there a common practice? Are we just kind of all doing our own thing? Should there be a common practice? Anybody want to voice an opinion? So I put a thing in chat. We should ensure the cloud events project owns the repo namespaces that we publish into. So in other words, it shouldn't be an individual, although we can delegate access to it. Lance, your answer. In general, I like the idea of having something that's common and owned by, you know, an organization as opposed to individuals. I guess it like, where do you stop? We've got Travis CI, Circle CI, Kodasi, Coveralls, you know, lots and lots of tooling that requires, you know, access to somebody has to own that and manage that. So where do you stop the common thing? Is it just when you publish to like a repository or something like that? Or is it all the little bits and pieces that go into actually having a, you know, CI? Well, it seems to me that if anybody on the, if anybody on these teams who sort of manages one aspect of the tooling decides to walk away for whatever reason. We don't want to be an alert, right? And so I mean, I agree with what Mark is saying. I just, I'm just trying to figure out the mechanics of it, right? Because unlike what Daniel was saying, where they have a central place inside Google where they can do things like share passwords and stuff, we don't have that. I'm just trying to figure out how we actually get to where I think we want to be without a shared data store. Is it private repository or not? Oh, there you go. Sure. Take the easy answer Lance. Geez. What do people think about that? Setting up a private repo that only certain people have access to and we just stick passwords and information like that in there. I mean, I guess that that is one way to go. Is that secure enough for people? I mean, I know you're not ticking. It was a check stuff into GitHub, but as long as it's a private repo, is that okay? I mean, I guess you can also use just GitHub secrets to couldn't you? I've never done that. No, if. How does that work? My understanding of GitHub secrets is that they're basically right only. You can. You won't be able to read them after. Right. Interesting. I don't know. You guys want to go off and think about this or what I'm not. It's really up to you guys to decide. Because we, I feel like we just been kind of winging it up till now. And it's, and it's worked sort of, but it's probably not the best approach. Yeah, I mean, I'll say that I was actually really concerned when I started to get more heavily involved in the JavaScript SDK and Fabio was not around much and I didn't know how I would be able to get access to things like the code coverage reports and stuff like that. Fortunately, we managed to connect on that and he added my, you know, added me as someone who could do that, but it didn't seem like there was any clear, you know, common way to handle this sort of stuff and that was disconcerting when I first started working on it. Yeah, I'm thinking I'm trying to I'm wondering whether the CNCF has anything in this space to help us and kind of tooling or something and I can't think of anything offhand, but I guess I could reach out to Chris Anna check or Amy and see if if they have something that we're just not aware of. And then, you know, revisit this next week. See if they have any recommendations. I don't know anybody else have any other ideas. You guys are too quiet. So what do you want to do so many to speak. I'm not I'm not a maintainer in SDKs I have no stake in this. I think it's, you know, if you can find out if there are any tools available. If not, if it turns out that that there isn't, then maybe someone I'm happy to do it could just kind of think about a little bit right up right up a proposal for something maybe simple and straightforward to start off with and you can vote on it or something. Okay, cool. Yeah, okay, I'll take the AI to reach out to Chris and or Amy and see. Okay. Anything else on that particular topic then I guess in the meantime you'll just add other people as necessary right for now I'm just publishing using my personal account so yeah. Okay. Okay Lance is that hand newer old. Oh sorry. Yeah that's old. Okay, I was sure. Okay. Okay, anything else on this topic then. Okay. My topic. Do you guys still want to meet on a weekly basis, or should we switch back to every other week. And obviously we can still keep weekly and just cancel. If there's nothing on the agenda but it's up to you guys. I'm personally I'm fine going every other week because it does seem like there hasn't been a whole lot of material in the last little bit. Okay, anybody else want to voice an opinion. I'll tell you what I'll let me paste them that let me paste the topic and the proposal to go back to every other week in the SDK select channel. And if I don't hear any objections will will do I guess lazy consensus is the phrase. Otherwise, if someone objects then we'll find out why, because obviously they're not on the call so they probably won't object. So, okay, I'll do that. Okay, any other topics to want to bring up. All right, in that case we are done. Thank you everybody. And we'll talk again next week on the main call. Okay, bye. Thanks.