EIPIP Meeting 81

Transcript

uh welcome to eipip meeting 81 I have shared agenda in chat uh today we have a few items to be discussed from issues and pull requests those are new and one from the past discussion meeting we will go ahead with eaps Insight update and EIP editing office hours update starting with the first item which is to discuss open issues and pull requests here we have um proposal 6953 which has recently been added as a informational EIP to the repository I suppose the question that was being asked in this PR is which direction we would like to move in

should we move ahead in the direction of making this proposal as living or we should move in the direction of making this proposal to final Tim unfortunately could not join the meeting but he has left his comment uh suggesting that he may not have very strong opinion in either direction but a weak preference going towards final I'll be curious to hear what EIP editors think and what is the recommendation for author here I think living proposals are very very rare I think we only have two um so I'd prefer if we went in the direction of like this is a list of all the um transition specifiers up to today and then that can go to final and then when

there's a new one introduced it can require the previous one and introduce the new one and I think that would probably be the the most eipip or EIP friendly way of doing it I agreed I think it's in team's intention that only he will create a new EIP if that mechanism changes therefore final seems to be what he intended to uh the the good characterization of his intended status all right I can see a plus one from

gajender Singh on the chat as well so um just for record purposes we would be moving ahead in the direction of finals so I believe that the pull request open to move this proposal to the review status uh there's just one thing can I also bring to the attention uh of the other EIP editors that this is categorized as informational uh I wonder is it more of a meta or informational one if it talk about mechanisms that's binding um so if it if so my rule for meta is if it affects the EIP process itself I think that's probably the only way we can have a a

clear difference between the two but so core core EIP uh so activating for half what used to be one of the main use case for MATA and here this one talk about uh activation mechanisms and if it's binding seems to fall into the same category so in the context using that as using category I was I think it seems to or more on the matter um side but I'll also be open to other approach information is totally fine but it just made this not as

strong as it actually are yeah so it it if a new proposal were to come along with a different activation mechanism um I don't think we would stop them from using it like if um so I I don't think it's um strictly a meta proposal um but it also could be a core proposal since technically core proposals are anything relevant to core Dev discussions and I think we can argue about this in circles forever I don't care uh if we just want to put our thoughts on the pr I'm okay with that it's okay I don't have a strong opinion so I can suggest this it could be a matter if they want if not then I'm

totally okay for keeping it informational and we can defer it to the team's decision that is that a good consensus yeah I think that's fine yeah I I would like to be sure like Sam did I get you right you are also suggesting to move it in the direction of being final because going through the proposal it looks like we are trying to record the activation timestamp for all the upgrades and my assumption is it could have future upgrades timestamp added to the proposal as well yeah I think I think we'd have to recommend that you remove that part okay so we might have to remove the

table that has been added here yeah exactly okay and it seems to be I mean in my mind like the way I am reading the proposal right now it seems to me more informational than meta because this has already happened in the past and it is just a documentation of uh something that has happened in the past but not that is something to come up to suggest any change either to the ethereum protocol or to the EIP process so I Believe by the definition of meta EIP it is probably not qualifying to be added as meta but it's going more

towards information it's a piece of information but yeah open to what editors decide here yeah I think we can remove the table of the hard folks of the mainnet because I mean that's what not PR title anyway says it says what are the types of hard folks that are there in ethereum so anyway this information is stored somewhere else in ethereum Gate repositories Maybe uh a reference to that git repository could be made over here okay all right um so probably

what we can get from this call is like people are in agreement for moving it to the review status and probably moving in the direction of final there could be some changes required in the proposal and that if someone can leave in the comment so author can follow and do the needful any more comment on this particular item thank you all right very well moving on to the next one is an issue which suggests that unlicensed code should not be allowed to be

included in any proposal I believe this discussion is again stamped with the discussion of copyright like what kind of information we can add to the documentation of proposal and the proposal here is suggesting that um copyright uh sentences should not be added element should not be added to the EIP and we should be including a license fee like cc0 should be there so we should not have uh things like that I wonder do we have any kind of documentation anywhere in eip1 or anywhere which suggests this and we can share this with authors so

they can not do this mistake if this is a mistake or I suppose there is another question that is coming up from this issue is can we have a bot check is that possible yeah so there's a PR for this uh for license Checker I'm just trying to find it now um there is a yeah there it is um there is a bit of a disagreement between myself and Panda I think we should allow any um open source license that doesn't impose restrictions on on Downstream implementation so we could allow Apache MIT and a few other ones but not GPL uh and panda is of the mind that we should

only allow cc0 um but regardless we definitely should turn on the license checker for to prevent unlicensed um bits of source there's the poorer question chat five three seven nine that's good to know that we already have a pull request for that license Checker but uh again uh is it covering all sort of licenses or only cc0 uh so I think as written it only allows cc0 all right yeah I left a comment in September 2022 my position is that I'm okay of requiring

any assets to be put in EIP repository as cc0 um coming from a author and implementer background myself I also want to give authors other authors and implementers the options to not doing so by allowing linking from asset page from assets to file because it's very hard for people to put an Assets in this very strict license um requirement while also allowing them to reference to it so we could either relax our link policy to allow linking to implementation that is less that that is less open or we can uh we

can not require the cc0 for assets but not likely if we do both it basically damages the ability for authors to be open more open to share the and share those work with us it's not just uh whether we can distribute it uh question right like I we could distribute for example GPL code and it would be not a problem for the eip's repository but a reference implementation that's GPL as an example there are other kinds of licenses that would also be a problem but a reference implementation that's GPL um in facts the downstream projects that they also have to be GPL so if we allow

reference implementations that are like non-free so you can see the source code but you can't use the source code I think I think um Maria DB has an example of that license um or maybe I don't remember what are the database projects has an example of that where you can look at the source but you can't use it um like those kind of licenses are not useful in a reference implementation because like they're basically a copyright trap for for implementers and I don't think we want to encourage that so I'd be against allowing any license that is that that imposes restrictions on Downstream implementations so I'm I'm totally with you on those since is could potentially be a

copyright trap and if we include them in our distribution that could be that that that could cause those problems we could be affiliate facilitating uh these kind of trap my argument is that however um we should be allowed not Distributing them but reference to them like create a reference link to them for example in our current uh policy if we only restrict to cc0 people would not even be able to link to go ethereum as a reference implementation would not be able to put go into ethereum code to the repository as a reference implementation now I'm totally with you that we should not put go ethereum code into

into the EIP Repository and redistribute it because it's on GPL license but I think we should give author the freedom instead to point to other code that already exists that has massive adoptions as reference invitation to say hey by the way there exists other implementations and if you want you can check it out but you totally are up to yourself to make your own because we don't want to distribute those so our link policy restricted us from being able to let people show other type of information implementation and also I think there is this

implied difference that I and you you seem to hold with me can I verify that with you that when you say reference imputation you assume that people is gonna copy and use that that's the main use case for reference implementation where I think reference reference implementation is only to show how it's done and then majority of the people will decide whether they want they want to go down the same route or re-implement it in a different way is that a difference that I implied to is that a good is that a right implement assumptions of how we see it differently um it's close so I see

um Anyone who reads the reference implementation and writes a new program as creating a derivative work of the reference implementation which is an incredibly old-school legal view of software development but um a lot of companies you know don't let their employees look at GPL code for exactly that reason so there there is an argument to be made that looking at a for example GPL reference implementation will force all uh like derivative implementations so anything that uses a similar kind of you know programmer algorithm is in the reference implementation might be like subject to the license of the reference implementation um I think that's

none of us are legal uh legal expert and I think you make your point uh it's um I I I do know that that's one school of thoughts um there's also another school of thoughts that says hey this doesn't seem like a copyright infringement and this doesn't seem like a patent protected in under patent so it's okay to look so but yeah I don't know maybe we should consult someone who has their expertise my point here is that if we hold difference in this way uh wouldn't it be okay to revisit the link policy to say you eat otherwise you wouldn't be able to let people put reference implementation so my strong position is that we should let

people share reference with implementation as much as possible because otherwise it doesn't matter it doesn't make sense and doesn't help we advance the open organ open standardization so that's what my my strong position is this and then you we can choose either ask them to even relax the copyright requirement or we can relax the link policy but if we restrict both then it's very hard for people to provide versus the representation so yeah so I'm that's why I think we should not relax the link policy and allow more licenses than just cc0 but not going so far as to allow GPL yeah

um I think that's a good direction to go I seems to be agreed by and I also want to saw that the gay and Greg based hand so um do we have an sorry to not know but do we have an actual case right now of a GPL software that somebody wants to link to no we have so let's let's bring this back to the actual discussion at hand uh somebody accidentally committed code with the unlicensed spdx identifier which means that you know technically we can't even be sharing it right so it's just about adding a bot to catch some of those problems okay is there's

I think we should have a general policy that we prefer um we prefer proposals that have actually been implemented um and those actual implementations May well be GPL to proprietary you know otherwise not something we would want to publish but preventing someone from linking to a working implementation does not help the quality of The Proposal but I'm quite happy to take things one case at a time rather than try to make up a rule in advance but my general attitude on each case is if there's an existing

implementation the author should link to it it just makes for a better proposal um if somebody feels that looking at a proprietary implementation is legally dangerous they shouldn't follow the link Victor please I see your hand rings as well uh yes so um one example that I can think of I I should probably follow find links because we don't let link um is there were authors who attempt to

link to go ethereum which is currently the most adopted executive I don't need to explain to you but maybe audience who are watching the recording um and it was rejected on the ground that we don't allow link to we don't allow links to Outsider VIP and other approved sources but let's assume instead they want to put those files into our EIP app repository under a slash assets it's not allowed because go ethereum is under lgpl and therefore even one of the most adopted clients would not be able to uh be and also supported by ethereum

foundation with grants it would not be able to be put in the EIP repository and that is one of the example of what this two rules together will prevent from I'm done speaking can't go in the repository but a link a link to a um you know to a link to the relevant commit hash and that should be acceptable for Tammy if you want you can speak

all right so let's um I think the license discussion is a much bigger topic perhaps we should open a discussion thread on which licenses we want to allow but I think we can all agree that we don't want to allow unlicensed code in the EPS repository is that correct trap we don't want authors accidentally sending code that they they shouldn't be sending um so I'm going to uh make a recommendation that we um turn on license Checker and but we make it very Broad and we allow

everything except unlicensed um I would like to share something here I recently was in a conversation with the author of 5773 I think he suggested a very good uh idea in which we can probably share reference implementation if even if we are not including that in the part of proposal so what they did is like they came up with this an npm package for their code having reference implementation and shared it with one of the hacket and I think there was some ZK uh related hackathon going on so they shared with the participants and they were using it so when they are using the package they may have to pay the license but if they do if they don't want to pay

the license they can definitely go to the the specs that is specified in the EIP and make use of that and implement the proposal so I am assuming here that there is a way out that we will be able to share multiple reference implementation by not making them a part of uh the standard the repository in standard we just mentioned the specs which should be generic and be available for everyone can I also share something on that direction yeah please go ahead um if I may shamelessly promote this effort that I'm promoting which is an open source effort to allow authors to

contribute their reference implementation of erc's uh and and it will be in a npm package which we currently packaged in so if anyone is watching this and think it's a good idea to share your reference invitation please do and also we want to know how to us get how to license this as well currently allow CC by zero but we are on defense of whether we want to be due license or triple license so that it can maximize the chance to be accepted in any repository because cc0 by cc0 is meant to be close as close as possible to public domain if I understand it

correctly but now that it's given a name is no longer considered as fully compatible with Pablo domain it seems to me in some of the cases so we don't know how to be as even broad as possible than cc0 so in that ground I'll ask what eipi to think but also just to bring awareness to this effort as well ERC ref um search for it yeah I'm done all right um I think we can take us at Sam's suggestion here that for this particular issue that is there there

should be a bot and the pull request is already there so we can go ahead and do that activate the bot and we should open a thread on Fellowship of ethereum Edition to discuss which kind of licenses should be allowed um with this bot Checker like the license checker and we can probably have elaborated discussion when we get some more feedback because in this closed group I think we have repeated on this discussion multiple times sounds fair anyone would like to add anything maybe to yeah wrap up this conversation okay

um so yeah I I think we should have that as a summary for this issue 7027 and um let's move on to the next one so there are oh please go ahead correct I'm sorry Greg do you want to add anything okay um so the next items that we have here are edits to final EIP so there are two proposals um

eip4955 and 4804 both are in final status and we have received a pull request to make a small edits to it so uh taking the first one which is PR 6937 I wonder what editors think should we go ahead and merge that PR or we can let the proposal know that we cannot make any changes because this proposal is already in final status it's it's a pretty clear typo for four nine five five so I'm okay with that anyone here objecting okay

so is it waiting for anyone's approval like yeah it needs one more so I think the way it's set up right now is to edit a final EIP it requires author and two editors so if one other editor for I think it's ERC uh yeah ERC so that'll be Greg Matt myself or uh Panda what if you could approve um it'll go through I think Victor as well right Victor uh yeah I added I do it uh I don't know if it approved it and then it's definitely gonna be EIP validator blogs but yeah I I I'll merge it I just need um I want to follow the process yeah

yeah we can get one more approval if we have plenty of editors here so if one uh first can add uh profile then that can be much perfect so the next one is PR number 6860 which is with respect to proposal 4804 any thoughts here I'll take a look yeah it's a that's a no-off that's a no for me that's a significant update to a final proposal and it's changing specification

I think you can't change specification in a in a bino which is a No-No you are allowed to add clarifications if I remember my uh Eep one correctly so theoretically this could be allowed but I tend to knife I think they are adding must condition in line 64-65. which is not clarification yeah so this is um so resolve mode always um had two modes it just didn't say what

the return values were um yeah probably needs to be an additional EIP yeah yeah maybe that would be better I really like the idea of being able to have new EIP superseding the old one like ietf yeah I feel like you should be able to transition from final to withdrawn if you're the author no they probably want to keep the number because they trying to ask people to implement the with the number yeah but we do have withdrawal reasons so you can put like you know goes from final to withdrawn with a withdrawn reason of superseded by whatever whatever so maybe we do something like

that isn't isn't this just a smaller matter at all yeah so this is so the return values from the function resolve mode were never specified in the original version that's an error yeah yeah um the specification was incomplete that's that's an error well yeah yeah I guess um you could implement it you just could return whatever you wanted so like this is I don't know I don't know how I feel about this I I won't really go one way or the other on it

right I think we have other little things stacked up for lack of an erratic process um like broken links and erc20 and Sam you you are on the author list right uh that's a historical Remnant but yes so I guess it would be better for someone else to make I think hardcoding their values must be done in a superseding EIP rather than this one because obviously it changes the specification of it we're the were these restrictions in fact uh there

and followed is is this a specification of what in fact was being done or is this a new restriction that would break existing implementations so I'm only aware of one implementation of it um and it it would have only returned one of these two values but it would break a theoretical implementation but I don't know if that's you know important or not I'll not worry about Theory I'm worrying about fact existing code for myself if it breaks nothing and the existing implementation behaves this way

then there was a failure to fully specify in the EIP that's an error and it's easily fixed um if there's actually ambiguity between implementations um that it looks more like you need to supersede to accurately describe the existing practice um this just seems like a small error to me um so I guess I think I think the safer option for everybody would be to make a new EIP so

maybe we ask the author if they're willing to um and if they're not then we revisit this discussion again yeah I'd want to know if the author considers it a small error or if they think a new EIP makes sense also I don't I don't see from the point of view of our policy that it makes a huge difference as far as precedent or anything like that but it's certainly an opportunity to introduce an Errata section um the two things that we can take out from

this conversation here is like probably we need some policy around Errata and one suggestion that Sam mentioned about an option for author to move from final to withdrawn because as of the current process that is not possible withdrawn and final both are the terminating statuses and we do not have any connection over there so if it's okay we can go with like more discussion on either of these policies and maybe we can bring it in future meeting but for this particular pull request if my understanding is correct not many people are in favor of

approving it that means this pull request cannot be merged is that a correct understanding and in that case maybe we would like to inform author yes please go ahead I'd like to hear from the author I'm basically in favor but we need to introduce a section Colorado so we can simply say in the rata that you know that there is a change um that that would be my preference if that is agreeable to the author because I think producing whole new eips gets confusing

people remember the numbers associate them with the EIP and this isn't like such a big change and it's not a breaking change especially it just isn't going to break anything um well so it would break an implementation that you know obviously didn't follow these new requirements so I I think that that is something to consider here but yeah but there is no such implementation true but like who are we to judge whether an implementation exists or not right like we might not know and you do your best to find out and uh you make the change at which point if anybody

follows the older version they're making a mistake [Music] um I'm not hard over on this it just a whole new EIP uh for a few words um and the few words are only there to document how it actually does work um seems overboard yeah at the other end a change that actually would break existing code requires a new new EIP so that people can continue to follow the old EIP and not break their code

um it's just just like you continue you can continue to conform to an older version of a language standard um the old standards still there and still a standard it's just no longer the current standard I suppose the equivalent here would be just a new EIP number and then the Old One's still there the new one exists yeah it's it's a judgment call which is why I really would want to hear the author's judgment you know sir off we're asking the author to

submit a new new EIP and they may say no I'm done with this you know I suppose if someone can drop a note in the pr that way we will get to hear what author thank you what author has to say in this direction very well um I think that's about it we concluded item number one we can move on to the number two which is discussion continued from past meetings um I do not see panda on the call and I'm not sure if anyone else has any

information about the EIP number brought do we have any progress I remember in the last meeting we discussed that we started but has to be stopped foreign so we will leave it as if and we'll try to check with panda where we are on the EAP number but very well moving the head to the next item here which is eips inside

I believe in this month we have received four eips in the final status and there are eight eips proposed as draft out of four I guess three are still open as last call for last call proposals um I suppose this is the last chance to add any kind of addition if they have any suggestion for the author proposals are erc5570 um the last call deadline has passed it was yesterday and other proposals are ERC 5169 client script URI but uh obviously

the deadline has crossed so if author did not receive any kind of suggestion they can go ahead and create a pull request to make it into the final status and there is this recent added proposal which is the ERC 5008 which I've entered into last call recently and the last call deadline here is June 1st so people listening to this call if you have any thoughts about any of the proposals listed here in this MD for the changes of suggestion this is the last call for you as well please go ahead and suggest that to author because we would try not to make any changes to final uh proposal as you may have heard in our earlier

conversation and yeah that's all from the eits insight we did have EAP editing office hour yesterday um it was really great we saw a lot of new Authors joining our call trying to understand the process many thanks to Sam Wilson for organizing this like for leading this and explaining answering questions I can understand sometimes it can be overwhelming coming so many authors but we didn't get chance to look into all I believe there are four or five open uh items that were not covered in the past meeting any of the editors on the call if you get a chance please

take a look at that so we should be able to close it before the next meeting but for new Authors who are trying to draft a proposal and have any kind of question with respect to other process documentation and they are trying to understand because it is their first time please join us on the EIP editing office hour we hopefully be able to help you out and you can propose your proposal as a standard that's all about item number four and I'm just quickly taking a look from this summary of the past meeting in the past meeting I thank God yeah so EIP part numbering

we already discussed panda is not on the call today so we can let it be the bug with 5507 was response so it's covered and a reviewer working group of Williams sorry Victor shared something yeah some um sorry I suppose I know yeah um so one feedback item I received from the core devs is that um we aren't giving them enough opportunity to provide feedbacks and some changes um one of them is the suggestion to not number EIP drafts and only assign them a number when they move to review

um so they're asking if we can provide um uh meeting summaries Somewhere In The Ether D Discord um but not in the all core devs Channel um yeah so uh just so you know I'm going to be posting an update there after this call awesome I mean we do have EAP channel here on ether India Discord we can make use of that right yeah exactly that's where I'm going to put it okay perfect so I'm sorry I think I missed this part so is the suggestion that we should not put EIP number while the proposal is in draft status it should be only allocated in the when it moves to review yeah that's something that Panda's been pushing for

but that could be like very difficult because um there are so many proposal I can actually name erc4337 which is still in the draft status I mean I understand that is one of the most advanced proposal but that is still in the draft status just imagine that proposal not getting a number so so I think it could work if we it like yeah like I'm kind of torn on this like being able to have a number as soon as there's something merged is really nice and you can refer to it right away but on the flip side um it would probably encourage people to move to review faster um which is kind of the point of the

review um like you really shouldn't be implementing a draft EIP because like it hasn't it might not even be fully written yet so if we make it so that drafts are unnumbered authors might be encouraged to move to review sooner which might be a good thing I don't know I haven't made up my mind on this yet myself but I think this is gonna have like you know another kind of discussion what would be the uh the EIP number should it be the pr plus some wordings and uh and obviously in this uh either bot has to do or like again yeah so the bot would definitely do it and it would just be that the highest number the highest existing EIP number plus one this could just push the problem to

things moving to review before they're ready to review oh agreed yeah just to get them a number because if they don't have a number you can't talk about them there's there's no no unambiguous way to refer to a proposal that has no number you know um yeah so maybe we keep the number I don't know but it's it's definitely something we need to talk to Panda since he's the one making the bot is there real is there really an overload of core proposals no definitely not is anybody forced the core devs to pay any attention to a

proposal that's not under review ah did you did you get brought up on all core devs uh yeah but then you know if they get brought up it's not our problem they don't need a number to be brought up they don't need to be an EIP at all to be brought up I if I remember correctly according to the process the network upgrade process that they follow if a proposal isn't draft or review that can be proposed for consider for inclusion like whether accepted or not so that is a separate

discussion but that can be proposed even if the status is draft and I somehow agree like a Greg what Greg mentioned uh if we enforce having uh EIP number at the review status then the draft status would be as good as the idea was earlier so now people do not think of idea they just make a draft now eventually they will just come up with idea and that would not be an idea that would be a draft and the draft would be the review it just it seems the core devs are making their problem into our problem then it's we're just a publisher and our

system works best if we give things a number as soon as they enter our system and then they keep the same number quarters want the number all the way through that's my understanding then they just shouldn't waste their time on drafts um they don't wait so sorry are you saying that you want a number all the way through or that you don't want to know very much want a number all the way and if the core devs don't want to deal with drafts they shouldn't deal with drafts oh no the courthouse don't care at all what status EIP is in as far as I can tell yeah no they they just want a number to talk about it it's it's Panda uh Micah from back in the day and myself a little bit who is toying with the idea

of not having a number at a draft but um if the the view is overwhelmingly that we want numbers I'm totally okay with that too yeah I'm more I prefer looser standards for draft and I'm not worried about running out of numbers you know yeah yeah I don't there's only there's only what six or seven hundred Eeps so yeah it's it's just what it is it's how we operate um but we purposely have low standards for drafts um because we don't ever again want to get dragged into political and legal issues about whether we should or should not have published a draft

um nobody else is here who went through that but I was so it was very unpleasant we literally had an editor who left because he believed it would be illegal for him to publish a protect their VIP really that's a story yeah so he was he was Japanese yeah I I remember the storyline there that was I

think somewhere in 2019 if I remember it correctly this was part of why we have a bot to get to get ourselves out of the loop for that arrest the original yeah originally getting a draft into this system was a purely editorial function and partly automated so it it wasn't a big legal issue up front um so there's a reason not to impose too much uh on getting things into draft stage as far as that goes there's a reason to give things a number uh and keep it okay I think we have good context

probably that's a discussion Point whenever panda is around we will try to bring it up on the eipip meeting how we would like to design the EIP number and aggregate status it should be provided when Bart would start allocating um yeah I think that is also we can make it optional that's another good suggestion yeah okay so if I get it correct Sam you're gonna post a summary to the Eid r d Discord Channel at EIP sorry yeah EIP editor Channel whatever it is yeah all right awesome cool thank you and I think that is all

from the items listed here anyone has any final comment to add yeah if I may mention that uh the um thanks uh poja and thanks uh many uh e editors who helped we had a first ERC Dev call uh yesterday it was um quite good um I think the pier we start to sense the few some Sentiments of peer review we get people suggesting each other um that's a great start um and just want to say a big thank you but uh and and also um look forward to have you join next time I think uh poja will present uh when she is ready and then also Sam I

already put you on the on sharing the WTF uh for next time as featured topics so yeah if any other suggestions for how it could be run or who should who can come to talk that would be great and also feel free to point authors of eic's to this venue if they want to seek peer reviews the recording of the last meeting is added to cat headers YouTube and yeah I will also share the link on the meeting update Channel this work Channel right I shared it on Discord I shared on Twitter and uh uh the the repository meeting notes as well

so thanks so much for also helping out with the recordings you're welcome very well thank you so much um we have two minutes if anyone has any final comments to add all right and yeah I just want to mention that I do presented a proposed a status change the criteria for erc's it's uh it's on ethereum magician a post um I want to talk about it next time sign up and but for editors I love to get your attention and maybe comment on it before next time so I can present it

to you and walk to you too and get feedback thank you if that is planned for next eipip meeting it would be really great if you can add it to the agenda which I will create it right after this meeting so yeah that would be good we can bring it to the next meeting if you would like thank you all right thank you everyone for joining today hope to see you in two weeks have a good one everyone see you