Hey Matt. Hi Doug. That was a good one. I didn't realize that was a funny question. I just had like multiple emergency things from Dan mainly around going to index suddenly so. Nice. I assume you are going right? Now I am. Oh I didn't realize you weren't going before. Interesting. Are you doing a presentation there or just going to help out? Apparently I'm going to help out. I don't know what capacity other than be present in relevant sessions and workshops. Yeah last week it was kind of like I'll let you know if Alex wants to go and we send somebody from my team to help out at a workshop and then suddenly it's not good.  All right. Hello Chris. I apologize for not remembering but what company are you from? Oh I'm actually this is the first from the Linux foundation. Ah okay. Do you want me to add you to the regular roster? Right. And I am the ED of the JS foundation. I've been a chat with Chris and he uh this called me. Okay you're cutting out really really badly unless it's my in it. But I think I heard most of it. Do you think you'll be joining us in a regular basis Chris? Chris can you hear me? Matt are you able to hear me? Yeah I can hear you. I'm so mute. Okay. I think the problem with Chris is and then I see two. I see two Chris's now. I can now yes. Oh sorry about that. I'm driving to a meeting. I just got my car so I lost the Wi-Fi so I lost the connection. Okay I'm not at all. I'm just curious. Do you think you'll be attending on a regular basis? Uh I think so or at least until um I get a feeling I may have some others jumping in my place but um yeah I mean we're we're starting to get pretty involved in a few different aspects of serverless from like the application developer side so we're just chatting with Chris and he suggested I jump in the meeting so I'll mostly be listening for now but we'll see if I can add anything. Okay that's cool. Just wanted to check. I'll add you to the regular roster then. Hey Stevo and I apologize for the typo. I gotta get the names wrong one way or another. If I mispronounce it and mistype it I'll do something to mess it up every time. Hey Sarah. Ben um are you new to the call? Yes good morning. Hi my name is Ben Hartzorn. I am calling in from Honeycomb.  Sure that's H-A-R-T-S-H-O-R-N-E. Okay I'm probably sure I missed it up. And how do you spell Honeycomb? That's right uh with a B on the end everything else is right. Thank you. Uh no E. Oh no E should have known sorry. There we go thank you uh and or we're at honeycomb.io. Okay just out of curiosity you can attend on a regular basis? Uh I have gotten an invitation uh and it was like hey you know you should check it out and I think you can contribute um but I don't know if I actually can so uh if if this is uh if it turns out that yes I can I would love to. Excellent welcome to the group. Thank you. The answer to Ben's question is yes by the way. All right then sweet. And hey there Austin. Hey Doug how you doing? Pretty good. You know I did have a question um I couldn't find a link to these uh meeting minutes docs in the GitHub repo. I'm wondering if that's uh on purpose or if it's an omission. Yeah we like to keep these things secret. No I'm just joking um I'll fix that oversight today thank you very much for mentioning it. Excellent thanks. Yeah so where I'll put that subpoena. Tell you what I'll add it to the AI list for myself. Also if you search for a CNCF serverless uh working group serverless WG you'll find them. You know I I was spending time on the train this morning looking for cloud events working group uh and uh Google was was not my friend in that um but uh I'll I'll try and add that for the search term next time thanks. Yeah thank you it's at the bottom of the um GitHub repo the reading is a link to meeting minutes. Yeah I always forget what that repo name is because it's not the serverless dash working group it's WG dash serverless. Doug what's the asterisks near the name? That confirms that I've actually heard your voice. Okay cool. So thank you and I got Sarah in there so uh Joann from SAP. I get two phase authentication or something. Exactly so Joann Joannis I'm gonna apologize. Joann from SAP are you there? Yes you are. Excellent thank you very much and uh Aaron from SAP from AWS. I'm here to factor authentication. Excellent thank you and I did hear Dan in there so thank you Dan. All right Kathy are you there? We'll get started in about a minute or so we got a fairly big agenda here. Um please add your name to the uh attendee list if you have nothing so already. Here it is again. Mark I got you actually Mark you there. I am. Excellent thank you. Thank you. Okay too many people are joining for me to keep track of this. Maybe someone else can but in about a minute or so we'll do roll call then we'll keep going. What am I typing? It's getting worse these days. All right tell you what let's start doing some roll call. I'll get this out of the way. Kathy are you there? Yes I'm here. Excellent thank you and Dan Rosa Nova. Yeah I'm here. Excellent okay uh Jim Curtis. Yes I'm here. Excellent uh Joe okay. The two Hannas. Oh I'm sorry I gotta do that every time don't I sorry William from Red Hat. Yep I'm here. All right Barum Barum. Yep here sorry. Excellent thank you and David Lyle. Here uh eat it. Yeah I'm here. Excellent uh David Baldwin. David are you there? Okay what about Michael P. I see that. David excellent okay and David P. Okay um Hong Zang. Hong are you there? Okay we'll circle back around later um so let's move this where you guys can see my screen right? Yep. All right cool so uh don't necessarily spend a whole lot of time actually let me back up. Are there any uh changes to the agenda people would like to make? Okay um just a quick reminder of the AIs I think Austin you have two uh oh someone's adding a new one for yours yeah you're adding one for yourself that's nice so just a reminder Austin you got you got two in there and I got one added to myself so we don't need to go over them just a negative reminder. Sorry I was muted I I proposed a something under MISC stuff to review the terms um yeah I think I added that down here. Oh okay okay no problem although if we have new people it might help introduce what we're doing. Okay um okay so let's see next step white paper I have no updates since last week so I assumed the Linux Foundation guys are still doing their reviews and edits and stuff I'll I'll try to remember to ping them later today but I haven't officially heard anything from them uh just a couple of miscellaneous things I wanted to cover um some of the more process oriented than anything else just want to remind people that we do strongly encourage everybody whether you're a formerly part of the working group or just lingering to comment on issues and poor requests and stuff like that that's how we're going to gauge whether a poor request is ready to be merged or not or come up for an essence a review on one of these calls. The more LGTMs it gets the better chance of it gets merged so please comment as best you can. Obviously if you have a change you'd like to see in there try to get in there sooner rather than later just get it in there the sooner you get fixed and then get it merged. If there's an issue that you'd like to actually work on and own go ahead and put some comments in there indicating that I'm partial to this hashtag dibs to me uh hold on just a sec there's a lot of background noise and I start muting some people but I can't meet people so if you can go on mute I'd appreciate it. So just as I said just put some sort of comments inside the issue and I'll mark as assigned so people know that someone is working on it and I will also add an assigned to somewhere in the top comments so people know who's working on it and then I just lost sound in case anybody else did as well. Yeah I think I lost Doug. Yeah I did too. Did Doug come here yourself? I still hear nothing on my end. Can anyone hear anything? I can't hear Doug. I can't hear Doug. It looks like he just dropped. I'm trying to get him on slack. Hey can you guys hear me now? Yes. Okay so I apologize I don't know what happened I got dropped let me go back. Okay so you can still see my screen I assume? Yes. Okay so did I start off or did you lose me during the middle of my git stuff? Or where did you go? Okay. We lost you at dibs. Dibs. Wow that was a long time ago. Okay so if you want to work on an issue and it doesn't look like it's been assigned to anybody else just please go ahead and mark it as dibs or come in there with dibs or some other type of comment just so I know that you want to work on it and I will add your name to the assigned to point that I'll add to the first comment in the issue just so people know who's working on it and then they could join in the fun if they want to. If you want your github id in the attendance tracker so people know who you are and they could poke you through github issues or prs and stuff let me know if you don't want it listed here and I listed it by mistake let me know and I'll remove it. And finally it seemed like people were having issues with git and I'm not a github expert or git expert but I believe this covers some of this to people running into. In particular make sure that in your git client that you have your user.name and user.email set appropriately. I don't think this has to be your full name but we really would appreciate it if it was your full name. Actually the dco might actually require full names and I'm not sure but either way we would really appreciate it put your full name there so we know who's actually signing the the commits and then so if you do a git config global dash l you know make sure it shows up correctly then when you do your git commit if you include the dash s on there it'll automatically sign it and then when you're looking to get logged for your commit you should see the author and the signed off tag match. If they do not match I think the dco chip will fly get as an error and it won't let your pr get merged. So I think that I think those are the problems that people were running into recently with prs and stuff. It's basically not setting these things properly and then not using the dash s on the commit. Doug can we put that in the contributing document? Yes that's a good idea thank you very much. I'll take the ad to do that. Thank you. Okay any questions on any of those points under the miscellaneous stuff? All right not hearing any hopefully that was mildly useful. Okay so let's do pr review here now keep in mind as we go forward here we're not looking for an essay perfection we just want to make sure we're keep moving forward and so hopefully we can go through these relatively quickly. Austin you want to quickly bring us at the speed on this initial use case pr? Sure to better explain what we're doing and why we're doing it we decided to take a lead on drafting out some use cases for the cloud event specification right from the beginning to help guide our efforts and this is a first pass at those use cases you know it's not final by any means but it's it's a start could it be reworded better probably are there a whole bunch of use cases that aren't in here absolutely but this is just to get the ball rolling there's probably five of them in there right now and everyone is welcome to contribute to add use cases I think we should optimize this whole repo so that all types of people from all walks of life can contribute use cases because it gives us a really good signal as to kind of what we need to accommodate with the specification but check it out it's only a paragraph or two for each use case very very simple you know if we agree on these we could start adding in maybe some diagrams and stuff to make it a little bit clear yep okay thank you awesome and the key point there is this is just a starting point it's not meant to be the final thing obviously follow on PRs for everything we do here so are there any comments or questions or concerns with this one going in it seems like it's been there for a while without any comment there's got a bunch of LGTMS yep yeah there's a there's a few of them in there that just have titles so I their proposed use cases people can go ahead and fill in descriptions for them mark already came in and filled in one for policy enforcement which I thought was really great so thanks for that mark yep all right is there any objection to merging this one then all right we shall merge it thank you all right next one I'm gonna jinx it here by saying it's easy but let's see how it goes okay this one was mine I just noticed that this paragraph was going over the 80 columns thing so I fixed a couple spaces just this paragraph and the spot down here and then actually I think this actually maybe a duplicate from another PR this wasn't missing a new line here so this is strictly syntactical fix any comments questions yep any objections to merging that one go for yeah excellent thank you okay next 39 this is this this is mine um oh this is just removing the notes or to dos that were left in the spec from the previous draft the reason it's okay to remove these now oh and the the backlog stuff is because per the ai's that we had on last week's call we now have issues for every one of the two dos and every one of these backlog attributes so that we can discuss those and so since they're out for discussion it makes sense to remove them from the spec for now and then we can add them back in or resolve the issues for for the two dos with the as those as those issues are resolved so any discussions or questions on this okay any objection to approving that one no objections on on my end I think this is this is better she can make the spec smaller more concise and then all those proposed backlog items need to be in a format where they could be discussed so all this makes sense yep all right thank you much all right next one is number 15 this one it takes the first pass at adding the rfc keywords and for those you don't live and die by specifications the rfc keywords are the you know must shoulds maze and those kind of things it just it did not attempt to change the the semantics of anything it was just in a first attempt to start using the keywords and and there were some cases where like here where we had to remove uses so I changed that must with our because must whether it's uppercase or lowercase does matter I'm sorry it doesn't matter it still is gonna be normative so we have to make sure we remove them where it didn't actually mean to use it um this one has been out there for quite some time I don't think I've made any changes so let me ask if there are any questions or comments on this one before I go for approval so yeah I addressed some comments but I think that you've addressed everything that I brought up yes I did all right in that case is there any objection to approval to that one excellent thank you very much and just so you know just just in the interest of full transparency if um if one of these that we're merging today causes a rebase of one of the other ones that we did approve if as long as the rebase is strictly syntactical in nature I'm gonna go ahead and do the rebase and merge it it's only if it changes something that I'm gonna pause on the on the merge and and bring it back up for people to review so you don't have to worry about something slipping in strictly syntactical things will will not go through review if that's okay and Sarah were you gonna say something in there yeah Sarah were you gonna say something I thought I heard you I just said yay okay good yeah that was a big one because that's gonna cut a lot of merged conflicts now if we wait too much longer okay Austin number four is yours you want to bring everybody to speed on this one sure thing um this actually has two things happening in this poor Christ which I don't think was the best approach in retrospective but it's uh first goal was to add a basic description to the read me because right now when you go to the read me of the spec repo there's not much there so this adds a basic description of what we're doing and why we're doing it and kind of how to get involved so the and the other part of this is to take a first pass at a roadmap to kind of help guide our efforts and the roadmap kind of just looks out to may when the cloud native con Europe conferences it's it's it's a pretty bare bone simple road map um you know chatting with Sarah about this the other day and I think we have some optimizations or some some improvements we could make to this roadmap but I think we could possibly merge this in right now and then follow up with another PR to to better improve this roadmap what do you think about that Sarah yeah I'd be up for it I think it it says something it's I'm not a poet it's like sort of it's directionally correct you know and then we can sort of fine tune our process yeah personally I'm fine with it okay yeah yeah Sarah and I were chatting about possibly not doing this by month but instead just kind of doing these by versions like version zero dot one should have you know a basic specification and use cases included you know zero dot two might have some uh like a library or supporting tool something like that so I think that'll be best uh presented to everybody here as a separate yeah I also also thinking that if we could have like sort of named or numbered milestones then we could collect github issues along this you know like we could tag things and it would be easier to kind of aggregate things if we had those kind of milestones yes that's right all right as I said I like the phrase directionally correct that's what we're shooting for I think we can merge this and we'll we'll follow up with some enhancements yep all right any questions or comments for Austin or concerns okay any objections to merging excellent all right hold on my machine is acting up again there we go sorry all right next one I can't remember who owns this one yeah that was me this is Louis three oh hello you want to talk us through this one essentially the change from the term resource uh to source in this deck typographically very straightforward any questions or comments on this is there any objection to merging this one I think when we determined when we settled on resource looking back to those conversations I think I can't remember I think I think Google was a fan of resource I think it was uh Thomas was that was this something that you felt was important so I was pushing for using the type of resource that is common Istio which has a name a server and it's tight as well as labels which we did not include I'm much more concerned about like where possible we should reuse data types than that we should call it just indigates a bias type there's going to be two resources the source and the destination anyways I know in our first discussions also this is Dan that we had a concern about source being is that the initial sender of the event is that some router in between that I mean source can be you know where in the upstream is source a reference to yeah in our private conversations within Google we had worried about that a lot we'd even you know temporarily considered having like a stack of some sorts we decided to for now scope it just to the original sender of the event and actually observe the occurrence and we would possibly add some type of place from middleware later just because the ergonomics of actually using a stack all the time would just be completely unusable yeah so one of the internal systems that we have which is even driven we use the word origin to indicate that the event is coming from well you could use the term producer as well there's a number of different terms that would be useful yeah I'm absolutely fine as the person who suggested resource having something other than source I just will come back later at some point probably and suggest that we have the shape of things that that this is referring to look like other systems especially ones within this means yeah yeah that is also your run I think resource is very ambiguous doesn't tell you anything you know is it the it's the destination the source something in between yeah so this refers to the where the events come from right so either origin or source would make more sense than the resource yeah I think source makes sense you know because this is where the event comes from right the source of the events yeah I think that I do think that there I had forgotten that whole discussion that there's this like like there's a common use case where um the the event is actually from a service that is getting a request from elsewhere um and so it's like this in this context what we're saying is the source is the thing that generates the event but then it it might actually the the the data that is in the event might represent something that happened before that to Thomas's point and so I'm curious Thomas whether you think that like would it be okay like do you think we could use the word source for this and then later we could add origin to mean I don't know who else was speaking before whether you were saying this is okay because we could reserve the word origin to mean the original or place or whether you thought that that was it's your honor I think also Sarah we had to check on that I think there is a distinction between the protocol aspect and the message aspect so a message has an origin or a source protocol may have a source IP or something else you know and the protocol may have multiple legs you know so maybe the message goes through HTTP transverse to Kafka and moves to kinesis in each one of those segments there'll be a different source destination IP address and you know other protocol specific semantics topic names etc but there's only one source to the message yeah and that's actually one of the reasons why I think uh if we were to change the name the suggestion for origin actually seemed fairly clear to me because that would be the thing that we want to forward is that no no this came from that database not from Kafka right but maybe we do need a distinction around the protocol metadata versus the message metadata because the protocol is only the carrier of the message so the Kafka you know sort of a source topic or you know port number or whatever you know is not necessarily part of the message it's part of the transverse that delivered the event message so guys if if it helps where where we use the word origin it's used to indicate to the component that's generating the message like if it's building a PR check out service it's actually the domain name of component that's what we put in the origin so I think what I'm hearing is we don't necessarily have agreement on this yet actually let me ask a more point of question so Thomas would you object to changing it to source right now impact with a potential change later or would you rather have some more offline discussions first I am absolutely not tied to the idea resource I think what I'm hearing is that we're not clear actually how this thing should be used and I think if we figure out exactly which server that this is referring to the name will fall out of it well actually I think that I think the discussion is that we know what this means it means the thing that generated the event and we're not sure what what to call it because something might be generating an event because it observed something that happened elsewhere but we still want to know who generated the event so what piece of software was like I created this bit of data isn't that a very specific case and we can make that a problem of whoever is actually generating the event as in yeah I'll give you an example here let's assume we have an API gateway that have a sort of a URL and drives a function is the source the source IP of the guy that generate the HTTP request or is the source the sort of the path resource you know to thinking about Amazon API gateway which one of those is this source less resource so does that text that I've highlighted on there in line 172 does that help answer that question this describes a software instance that emitted the event at runtime right but it is the software instance the client AngularJS you know thing in the client browser or is that thing is the API gateway that intercepted HTTP message and passed it for it well I think it depends on whether that the Angular thing actually created a cloud event or whether it did something else that the API gateway is then generating an event I mean it's sort of semantics but I mean I do think at some point you're like okay now I'm starting to use cloud events versus I don't think that necessarily cloud events have to report events that were generated in a cloud event protocol because it may serve proxy for traditional events right but then I think if it's basically what you're building is a proxy you can decide that your source is somebody before you right okay yeah I subscribe to that really in this case the API gateway generates the cloud event but says that I'm not the origin of source it's the Angular app with the origin yeah so the question is is it possible you know the fact that it comes from Angular app is there any way of knowing that you know if if some HTTP event arrives at a gateway is there any way of knowing what it sources and then you know translating that into a specific value here in in the source oh in some cases it would be easy but in some cases it would be very difficult to find that out is this an inferred field or is this like a given field so is it like is the source going to like you know fill this field for us or is this going to be an inferred field it's actually a question this is something so my understanding was that the piece of software that is generating like that is building this data would would fill that in based on its identity or its descriptor or like you know however it wants to identify itself scoped by the namespace and let's not talk about the namespace question that and that like if that piece of software believes itself to be a proxy like then it has some interpretation of what the source is but it would fill that in right and then if if this message if this event is then sent along and it goes to a bunch of hops right like that the transport wouldn't touch this field field otherwise it's creating a new event right it's like a different thing which of course it can manufacture like I mean we haven't talked about like secure like if you don't know if you're not over secure transport all bets are off anybody can make up anything right so it's like what how much you trust the other end of a pipe yeah so I can suggest that by default the source will be the guy that serves like the API gateway in that case and he will have another sort of option to convey metadata about its original source like the host name in the case of HTTP or a host cookie or whatever but essentially and then it could potentially be open for interpretation that may you may be creating server like a domain name you know like the prefix will be the API gateway prefix dot something else but that will be sort of open to its implementation so I'm trying to figure out whether we want to limit this PR to just a syntax change or force Louis to go further and say enhance line 172 to make the description a little more crisp I think it needs to be a little more clear so it won't be ambiguous and so let's say we can get that that well actually I do think that this like this resource term ended up confusing a lot of people yeah I agree um so I feel like source is a better stand in for what we're trying to convey and so I would suggest like you know like Thomas indicated that we like let's have it be sourced for now and then add clarification additional things with the openness that we might change the word term source source right I would agree with that and I can take a action item to maybe add some clarity um it doesn't look like examples are very common in here but I can try to glean from our examples and put those in the conversation okay so hold on a minute yeah I think samples are important here because I think without us looking at concrete stuff we're all guessing yeah we're not thinking through those little details yeah I'll I'll give some examples of a conversation about what Google does it doesn't mean it's the right thing or what will eventually be agreed upon by the standard but it can at least uh I can share my side of the story and there's some chime in with their insights from their providers so Thomas can I tag you with an action item to create new wording for the definition of source absolutely um I do you mind if I also uh suggest in there a field that think might be missing I don't have a problem with that you could try to group things whatever you want my only suggestion would be to separate things as much as possible because they may get easier to get they may be easier to get through if they're smaller chunks sure sure but it's up to you how you want to group it so I'm really missing the source identity because I believe that either the proxy or the origin uh you know it has its own responsibility on authentication but they may want to convey what's identity of the person originating yeah I think that would be interesting to see a proposal around that you're on I think we got stuck with the like you know in these in these cloud environments where everything is connected to everything else and it gets hard to sort of figure out what the actual source is but I'd be really interested in if you have a concept that you think would really work yeah you know you think about it in many cases like if there is an API gateway it's already doing authentication using tokens or whatever and then it it sort of can inject the header with what's the identity that I've authenticated so the back end function can do authorization based on identity that they sort of trust the front guy to at least authenticate and it can be very useful that's something we we do but and we we really need it for a bunch of applications to understand who's the identity that's issuing this event assuming that the transport is owns the aspect of authentication of that identity so yeah we do something similar so um we just couldn't come to a like when we had prior conversations before this came to github we like couldn't come to like a crisp definition that everybody could agree to so like if you want to do a draft of something and then people can chime in async I think that'd be that yeah so you're on can if you can take that action to create that issue okay that's fine okay so I think what I'm hearing so far is we have action items for follow on either changes or additional properties related to this but I think I'm hearing more people are okay with the idea of at least changing resource to source for now even though it may change later um is there any objection then with moving in that direction in other words is there any objection to accepting this pr as it stands right now I mean I don't really see the value in a change if we don't have agreement on what we're changing in the details what this is I mean it's okay to say we'll change it later but I just don't see what we gained by and by doing it until we have more detail so my interpretation is that while you're right it still may be ambiguous at least source is more closer to what people are generally thinking than resource because resource is just too generic of a term and it's more consistent now with the current description yeah I think we can you know approve the source change now and then later we can clarify more what does that mean okay so Danny you're okay with that I know it's not perfect but it's I've said twice but I'm not but I don't think it matters well no I well I am shooting for consensus here this is one of those situations where is this something you can live with with these with the assumption that we will fix it later that's I mean my whole point is it if our assumption is we will fix it later why take any action now what are we gaining from the action is it just so we feel like we accomplished something or is it because we're moving closer to something or I just don't understand what we mean so I think the key thing is I saw a lot of questions about resource that were like completely misinterpreting what we were trying to achieve and so that was the you know that was the thing right where if even if source isn't precise it's more in the direction so that people knew to reading the spec would get the gist of it um I mean that said you know like you know I'm not going to die on my sword on this because I think we still have I only think the details that we're missing are we're going to tell us if we are right like we call it we could call it apple for all I care as long as the details were there people would know what apple meant without the details I don't think the name is important so here we can we can call it source I think that even without the details it will stay sourced I think the details are not about is it source or resource anyway resource is a bad name it's about explaining further what kind of source are we referring to like the original or original region well I think that that's why we the examples because if it's so I would like to see hey here's the uri of a of a of a storage object in s3 that that changed and this is the event and this is what it looks like and without the concrete samples an example I don't think we get close to understanding what we're really talking about yeah and it may be that you know the path within s3 is part of the message object which is referring the schema and the thing that is the source is actually s3 generated an event telling you something about about its buckets that would make more sense to me because then there's a lot of metadata which is event origin specific and that will probably be designed into the schema of the of the message like if it's a dynamo db right now then you have a previous value currently you know new value new value different records potentially array of objects that have modified not a single object that have modified to you know coalesce a bunch of events so just in order to make forward progress because I don't want to rattle on this one more than we already have Dan is your concern strong enough to actually to raise a like a formal objection to where the point where you'd you'd ask for like a vote on this or is it something you could just hold your nose on I mean I feel like Dan has enough of a point that like we should just let Thomas elaborate on the description and have some examples and we do it next time like is it like if it if if it's generating this much conversation then like let's just define it better and then name it well that that's just that was my next point was if it does and it's perfectly fine Dan if you do I'm not trying to be stronger you but I just want to make sure because I got at the point now we're going to say okay if someone wants to make a motion to formally make a vote on this that's fine otherwise I'm going to defer it till we have you know either next week's call or we get some other resolution presented to us as long as as long as we're committed to making a vote on it later because I mean the whole world is built about around URLs and URIs and no one's ever been confused by that so the the thought of walking away from something that's been that well established concerns me so if we're committed to voting on this later I'm fine with just doing whatever we want today which is accepting that it's just we have to commit to actually follow it up I mean I mean I agree with the URI approach and I think that I like the nomenclature source and as you saw the model I presented back at our face-to-face in November that's basically have distinguished we're always dealing with multiple resources in terms of events and to me if you adopt the source terminology you should adopt a target terminology so the event always has a source and a target but nothing else okay so does someone want to make a motion to adopt this or do you want to defer it no one makes a motion it's going to be deferred and we adopt it and open an issue that says that we need to address this and then I second that motion yeah I'm happy with that yes okay is there any objection then to adopting this with the I understand that what another issue will be open to to do the follow-on work okay not hear any objection who would like that action item it sounds like if I was already going to be writing the description you can assign the the bug to me okay whoops can't type yeah it actually almost sounds like the exact one you already have doesn't it is it is it materially different than your other ai well I think it's that the name of this attribute is to be discussed after the prior okay okay um oops okay to reconsider the name thank you that's what I was looking for reconsider I knew it was something thank you all right excellent okay thank you guys very much um and thank you guys for your help for getting through those six issues that that's that's really great um Austin this has been lingering I think maybe for two weeks now I want to make sure we talked about it today since you put on the agenda two weeks ago and then get to it sure yes um you know and since then I'm I'm still feeling like we're not we're not quite ready to start talking about this but the the topic was you know at what point do we start approaching some building some kind of tooling to help support the the specifications that people can start using it today and integrating it with other projects within the ecosystem I don't think we're quite quite there yet so I'm I'm fine with kind of deferring this conversation topic for a little bit further okay just let me know when you want to bring it back up I don't have a problem with that at one point if we sort of start moving over the metadata one thing I'm trying to figure out the replaced data in the sort of the first section and then the content type is sort of a backlog if you have data how do you know how to decipher it if you don't know it's a sort of serialization mechanism so so you're on a favorite and open issue or a pull request with that proposed change okay thank you very much okay so by the way regarding the implementation we can take a stab of creating like uh we already have like an emulator for uh for what we've done for our serverless I can take the emulator and and create at least in go like a stub to generate just like those classes and test so you can emulate function calls and all that okay that sounds good yeah I I know our company would be interested in contributing to that so I mean maybe we could just start drafting out or writing out some issues of some of the libraries or supporting tooling that we'd like to build and put those in issues and then figure out who wants to collaborate on them who was talking Austin yes I'll send you the link of the you know our our test hub it's really small code and we can just go and change the interfaces to whatever we define in the spec I'll send you a link cool great okay before I move to the next item just want to remind people if you have not done so already check and make sure your name is in the attendee list the beginning of the gender doc because we we will try to do the roll call again for late comers but if your name isn't there I'm going to forget to call on you now Austin next on the agenda was the future work items would you like to discuss that today or do you want to defer that for another time I think that's up to the group here um you know right it's at the beginning of this year we've um we've decided to focus on cloud events and get the specification off the ground standardization discussion around the serverless architecture so now we're making progress on cloud events everything's everything's looking good at you know at what point should we start talking about some of the standardizing some of the other things like a common function signature or common as API you know we don't have to get into today but if anyone has some strong feelings about you know when we should start considering this stuff please feel free to bring them up yes one I was looking through this or considering this earlier today I realized that it seems like most of the proposals that people are going to suggest for future work items are probably going to either expand the scope of our working group I mean of this specification or potentially kick off a brand new working group um and if that's the case I'm thinking maybe what we should do is aside from maybe people adding things to that work item list if they want but what they really should do is open up a proposal in the WG serverless working group directory because we have a directory there a couple proposals and maybe people should put their proposals in there and hash out you know or work through discussions with other people to formalize the proposal and then when they feel like it's ready enough and solid enough then they can bring it to this group on a weekly call for us to consider it um because I don't think we want to necessarily get into the brainstorming session on this call itself but at least then if you have a doc in the repo someplace then people can hash on that repo there or you know inside there put a pointer to a google doc however you guys want to work it but overall I was wondering whether we should just use the proposals during the original repo as the way to sort of get those conversations going what do you guys think sounds good to me sounds great okay and Austin if prior to a proposal you want to do an issue in the serverless WG then we could like then you know that would raise awareness that you're working on the proposal or something like that yeah that's true and I can definitely obviously we can put something on the agenda here if nothing else as Sarah said to raise awareness to it just so it's not you know missed by people in the flood of github comment yeah and so that Austin doesn't spend a lot of time writing a proposal and somebody's like yeah but I had a slightly different idea you know yes that would never happen though but yes okay and also send them to the meeting list right about that yep I'd be good to yeah well I had to write up a doc someplace to talk about how we want to deal with the future work items and put down all the logistics of making sure people are aware of it I'll put that someplace sounds good all right okay yes Kathy yeah I'm thinking about you know working on the proposing like service application model should I start like on the Google doc or should I start start on this github um Dave I wanted to wait until I get that process to find a little where we that way everybody follows the same pattern and chances are it's going to be kind of similar what I described here which is either open up an issue or open up a poor request to add a document to the proposal durr in our in our original git repo the serverless repo um but let me let me work on the details and hopefully before next week we'll have that in place and then you can just follow those that you can follow that process does that sound okay okay good yeah I'll show you put that in here the future work items here so that you know if other people have similar ideas like Sarah suggested we can work together yeah well that's the whole point of the process right just make sure people can put their ideas someplace and other people can find it so they can all collaborate and not do duplicate effort yes yeah I think we also want to have discussions around security not that I have a proposal for how to secure serverless functions but maybe we'll start the discussions and and create sort of action items around what needs to be done yep all falls into the same category yep okay so moving on I wanted to I figure you might have some time I want to talk about some issues but I want to change the order here slightly uh Sarah I want to talk about yours first um so let me bring up the issue with while you start talking to it great yeah um so basically this comes from like a bunch of questions in the spec that I felt like came from people who may not have clarity on like what we're actually trying to achieve and how the spec fits into a whole lot of things that we haven't defined yet and so we're in the situation where there's a lot of working systems that use these specific kind of events and so I was attempting to explain that and I started to write a more complex system diagram and then I needed some words so I made a very simple presentation that just defines a few simple terms that if we could just agree on what terms we want to use then that would help draw a bigger diagram which I think then we could then that would help us all be like are we talking about the same thing and and get somewhere so the first part of this comes from the spec itself right like that we that the event is commonly used colloquially to mean the data that represents the thing that happened so this was um you know sort of prior to getting this into GitHub we said well there's an occurrence which is the thing that happened and then there's the event which is this specification and um and so um and then sort of like I decided I'd talk about like some of the use cases which are there's a lot of stuff around like you know somebody makes an hb or rpc call and that changes some state on the server which generates one of these events or you know there's also been a lot of conversations about like the iot sensor situation and we also wanted to call out that like it could be a non-event right it could be time passing with something not happening all of these things are in scope and that um and that some of the stuff that the spec discusses is there's like sort of context and data um but the idea is that like every occurrence is uniquely identified by the speed that describes the event so that's really just a preamble that covers what the spec is in but what's in the spec for the new terms um which I pulled the source term from the change that I liked right um that but this is like but then I think like you couldn't talk about it with like what it what happens after the like there's another side of it right which is is outside of the scope of the current spec so the way that the current spec is written is that there's this event that then using things that we have not diagrammed yet can be bound to I use the word action from open whisk um you know amazon calls these handler everybody calls these things different things but I thought action was like sort of a nice generic term um for like what you like there's the events that are emitted or generated and then there's another thing that um the developer who is not the developer of the source and may not even be the developer of the action can you know find together and for the event to trigger an action um so I just wanted to propose like are these words that are good is this a reasonable sort of description of how we're doing things and then on also acknowledging that like the eight we're all agreeing that this specification currently doesn't cover a protocol where the event is transmitted um and there's like a whole bunch of requirements that are currently like sort of outside of the spec um so I wanted to sort of first ask like does everybody agree this is the model this is the fundamental model we're saying and you know can we agree on some terms that we can use consistently to then get to more the sort of more complex diagram that we all want to make yeah I think this speaks to the model I've been asking for I think it does as well Sarah I'm a huge fan of consolidating on terms um I think we should continue to add these into a single kind of glossary section in the specification um because it will greatly improve alignment although action is outside of what like to your own spread or earlier I think it was your own who was saying like oh yeah we want functions it looks like what the action is is outside of the scope of the event spec as currently written like how it's transported I made it I made the distinction between uh the protocol and the message what you have here like E and then the I think the protocol usually is not used by the consumer the consumer doesn't really care about the address of Kafka it cares about the message 10 point and then to expand on that point um the other one that I think Sarah was trying to make is that the source also doesn't care about the action um that one of the power of cloud events is that you can have these loosely coupled systems you can expose the ability to conserve an occurrence without knowing every consumer of your action so Sarah in terms of next steps on this um I want to make sure that as we go forward on something like this which I think is great that we don't necessarily have to worry about keeping two documents in sync or them getting out of sync is more more the worry how do you what do you want us to do in the short term on this is it just to make sure the spec gets the right terminology so you can echo them properly in this doc that you're producing or you know what are you looking for people to do well I actually went ahead and based on the conversation in the issue and made a markdown version of this so that if we so if you could look at the markdown thing so that it's easy that if we change the terms on the spec we can just like it's in text rather than in I mean it's also in I don't I'll have to think about like somebody like this picture I don't know how to do pictures in markdown very effectively um so it has a ping in it right that would have to be changed but the goal would be that like this if we decide we're going to name things differently we could then just like hat this is the sort of bigger context that um like doesn't need to be in the spec I think Sarah so this is like uh almost kind of like a guide that people can read that's not as kind of in depth and technical as a specification that's just kind of explains kind of what we're doing and the concepts involved and exactly so it would it would explain the terms that the spec uses in less precise language right that are consistent but like also address things that are outside of the scope of the spec but not like I don't want this to be exhausted like I think this should be like a few pages max right the goal is just so that if somebody is coming to this fresh right they're like oh cloud events I really want to do something that has nothing to do with what we're doing because they do something that they call with the word event that they could like read an intro doc and be like oh that's not what we're doing okay I'm going to go away or like oh okay I understand the context now I'm going to dive into the spec so Sarah would it be possible to reword this slightly so that it looks a little less speckish and put something at the top that says we're going to use these terms as defined in the spec pointed to the spec and then the rest of it is just pros that talk about those concepts without actually trying to define it because I get a little nervous when I see things like event colon and then a definition of it because that's asking for things to get out of sync and then prs to get them back in sync and it's just going to be a maintenance nightmare but it's talking about things in abstract sense the way you described it I think that makes perfect sense so if you look at the sense of the bigger picture um well how about if I like link to the actual definitions in the spec because I do like if we rename something in the spec we should rename it here agreed and I think our rename probably won't happen that often but it's like wording change that might happen fairly often and those are the things I worry about missing okay so why don't I give an intro that this is really about the ed with a pointer to the spec and then um and then I will link to definitions in the spec and I'll make sure they have like a yeah an anchor yeah and I like that because yeah I don't like repeated words yeah exactly okay is this the read me notice we didn't do that I believe right yeah we were thinking that the other action item I have but I didn't get to is to take um the references out of the spec that are like um the like the things that are the current events like the um uh the the the cloud event like things that amazon and um google and others like started like were feeders into this um and so the idea is I just came up with this directory name about to be like this is where we can like put stuff that is the context for this um I mean this could go in the read me but I think it it would be better to link it from the read me so that we can also link things like I think Rachel last week suggested that we have like a table of contents in the read me so it'd be like a link to the concepts and a link to the how to start you know how to contribute and the working group meetings sure and we could optimize all that stuff as we go along I think the most important thing is just to start getting this down getting our story straight yeah agreed okay I'm gonna have to ask one question about the content here um I'm a new attendee here so I don't have a lot of the context that unfortunately y'all are y'all talking about um and when I think of of eventing uh this this diagram makes me think that I should only make events for things that have specific actions and I'm I'm curious is the definition that we're trying to build up uh of things that are rare and you should only event something that you're like this is going to go and do a thing or is something like I'm just going to store it sufficient description of an action and if it is can we clarify what action means there a little bit and then it's not like necessarily a notification or make a decision based on this information but just handle the event yeah I'll um I think that's a good point um I think the to clarify what I think I mean and Sarah can you do like 10 seconds because we're out of time um yeah so I think that the idea is that you wouldn't the the generator of the event doesn't know what the action is at the time they're generating the event so maybe they just call it consumer and then you're not limiting it to actions okay I'm gonna have to call time here I'll do some rewording based on the feedback okay yes thank you I don't mean to cut this off but I do want to get the roll call back to make sure people are attended or marked down appropriately and we are out of time I'm gonna be respectful people but Ben please if we don't get it covered bring it up next week so let me just quickly go through the roll call again Joe Sherman from Microsoft do you hear yes I am okay uh Garish from SolarWinds yeah hey Klaus from SAP yes I am and Vile you hear Vile what about Michael from JP Morgan yes I'm here okay um Hong Zhang yeah this is me this is Kathy you can remove that it's just the same thing is Hong here or not yeah I'm I'm here this is Kathy it's a same oh that's Kathy I'm sorry do I sorry and what about David P I don't know who David P is but you're I showed you on the participant list okay is there anybody on the call who does not have an asterisk next to their name in the attendee list oh yeah this is Louie can you add my name Louie for me yep got it thank you anybody else all right cool thank you guys very much this is a very productive meeting we'll talk to you guys next week thanks thank you hi guys thanks bud we're using rc keywords we got our roadmap in place everything's coming together really well thanks everyone all right bye bye bye guys


So I was following very closely what happened so far. So I think it's a big opportunity to do some lively discussions after the presentation. So it's really an opportunity for you, I think we should very much focus on interactive discussions after the presentation. To introduce today's event, a presentation for more formally introducing the case study portfolio. Let's speak a little more focused about our case studies. When we set up this course lecture, we had to write a memorandum of understanding so that the mechanism of agreement so someone wants to join this course lecture he has to agree on this memorandum of understanding and we as a group of researchers formulated the memorandum of understanding and what we can find here is we need the case studies also for delivering inputs to our theoretical framework. We need the practical applied situations. We need to utilize our computational tools and we need to demonstrate also the applicability of what we have been thinking about. So in this sense the industry innovation base really support what we have in the memorandum of understanding. This is a great tool to work on this. And yes, so in summary basically our case studies, this working group 4 is the important link to our theoretical working groups on the theoretical framework on the structural health monitoring and performance and the methods and tools working group 1-2-3. And also it is the link to our standardization activities. So we have been working on getting the case studies to work and we have been interacting with the working groups and our framework and we have requested case studies and we have collected quite a few and we have also been studying out the identification of typical challenges or difficulties we have been observing in the previous years of the action. So it is nine case studies which are under development. You will hear eight case studies presentations in case all the case studies presenters are here. So you will hear eight case studies today at this workshop and I think one major step we took here for the case studies and our thinking was that this was already the last two presentations. We need to step it out of all models and also of our conventional integrity management procedures and the specifics of our monitoring systems but to address a decision scenario or a decision situation and we have been primarily looking at the design phase and the operation phase of the infrastructure. I think this is the most important phases. We have monitoring phenomena regarding load processes, damage detection, damage mechanisms, material properties. Actually in our framework we can quite extend this. There is quite some ways to go. If we have a more general perspective for instance on the system states and basically on the complete infrastructure system. Our structures include bridges, building some energy production and storage geotechnical structures and various decision scenarios. We are working on a case study classification so that it becomes easy to overview what we are doing for the case studies and what case studies do we have and what is the result. The first point is that we classify the structure and the type, the life cycle phases or the design and operation phase. What performance we are considering is a deterioration or is it the complete performance of a system including the risks and the extreme loadings. Very important or the most important is our decision scenario who is the decision maker. What is the decision point and type? Here the example is a photo structure integrity management, the structure integrity management consisting of very basic repair inspection monitoring, trumpet plant in the commissioning phase or even before in the design phase. The decision point and type is basically in the design or the commissioning phase of a structure. This is where our models are providing the highest benefit because we can predict the performance. This is all I had in the last presentation. We can predict the performance. We can predict the inspection outcomes. We can predict the way to repair and we can also predict what monitoring data we will obtain. When we associate this to costs with each of the branches we have, then we have a pre-post-surrealization analysis so we do a qualification of the expected benefits before we can optimize with our decision parameters. The best way to visualize our models is pre-post-surrealization before any SHM system installation or any action performance. What is the objective? The objective is to maximize the expected benefits or minimize the risks. We are always working with probabilities and the monetary consequences. Very important is the basics of our decision scenario and then the decision variables. This goes in the decision frame to the rectangles. It's the action and action parameters and it's the information requirements, strategies, inspections, monitoring and what parameters do we have and what different strategies we can utilize. These should all be documented very shortly but distinct here in this classification and then it's the results, what is the value of information like I outlined in the last presentation. What are the decision modes? What do we do in practice if our monitoring system provides one indication, so the structure is safe for instance, then what should be done, then maybe the next inspection or the next pre-pair action can be done later. This is about the classification and the way of summarizing and providing an overview of the case studies we are working on. A few words also to some case studies which are under development and which will not be present here. This is for instance the soil structure and the action effects of exaltation and the response of reinforced concrete ratings in case of earthquakes. So this is very important for Iceland, Jonas who is here, who is working on this case study. He has access to a lot of data and this is a perfect ground for doing such case studies but we are working together on a few challenges like the uncertainty, quantification and maybe how to efficiently do a damage detection after such an event. This is a case study for the value of information for seismic emergency management of the highway bridge. Maria Pina and Simona Mirabilia are working on this case study together with Pierre Francesco Giornal and here we already have a decision tree. That's further development of this generic decision tree we have been seeing at the beginning. And one aspect could be considered here is whether visual inspections are more efficient or monitoring. It's more efficient. Here we have a very well developed, already very well developed case study. There are a few publications about the assessment of fatigue details and what value fatigue monitoring can bring for doing the condition assessment. I think the way of further working on this case study is to also have a system perspective. This is very important. We are going with our methodology in the system perspective but the problems we are working in structural health monitoring and structural health monitoring engineers the focus is on the detail on this handle. This is very good but we need to connect this to a system perspective and the system performance. Another example is industrial case study. This is not an infrastructure system but some more solid tank monitoring. It is of reinforced concrete and this is I think an energy saving device for solar power plants. And here the challenge is what is the most efficient monitoring of the concrete strain and reinforcement corrosion. We have also cases where we have an extensive monitoring record. Also the most efficient way of what this is at work we see this as the largest potential of our methodology but I think this is very important. We also need to address these situations and what we can learn from this. So we could look was it efficient to do monitoring so we have a posterior decision analysis or I think this is the better way. Maybe we can look how we can show our predictions our prediction models for the next case like this and also what could be the most efficient decision-assisted with the experience of this case study and then to account or then go for the next case study but we then need to account for that we may have a different ground and a different case study and we have another uncertainty model. So I think the general challenges for our case study is beyond what is written here I think the way of thinking and to have a clear decision scenario I think this is the major step we have been taking this is maybe not our actual challenge anymore but of course and I think this goes also to a very important point it is the level of detail and we already know, all of us know we are working in engineering with very detailed models but the decisions based on the engineering predictions are taken with much similar models and this simple in the sense of detail not necessarily in the sense of the goodness of the models but they can be very very very efficient models but this step is here to work with the right level of detail and if we do, if we model a decision scenario then the level of detail must not be this high it must not necessarily include all our sophisticated models but we need to have a very clear interface to the model outcomes so that we can maybe not do the decision analysis with these sophisticated models but the input for the decision analysis comes from very sophisticated models so to harmonize the level of detail we need reasonable assumptions and simplifications and uncertainty in representation where are our probabilistic models are based on so these are two general challenges then specific it is, we have been often observing this so we have our SfM system and it provides an outcome how is it related to the performance of the system? this is a very important aspect and this is not solved by industry nor infrastructure operators this is the first task of us, of us as researchers to provide the models but the tasks of the engineers and our people who are working within the decision scenario is that there is an alignment of the information we are getting from our monitoring and inspection to the performance we are having or to the decision scenario which decisions should be supported with this information and then of course we have a complexity challenge so spatial time dependence, spatial and time resolution what is the right level of detail, this is what I already addressed we have these 19 case studies we have an approach of how to work on this is supported by our networking tools we are having mainly by workshops but also training schools we had a very successful training school last year in November and all the aspects, also the education was very nice organized by Maria Pinah, Imangeli so in this sense there is a few levels of documentation internally it is a fact sheet then there is publications of the case study we follow the classification scheme we would like to see the decision scenario which structure, what is the objective of the decisions and what are the results, what is the value of information is it worth in this case to implement SHM, the very basic question but what strategy, what location should be monitored and how long and of course the work on our case studies helps in our construction on the level of the theoretical framework on the appropriateness of tools and methods we are having and we learn from case studies in general specific insights but we also learn about bottlenecks so enough for the introduction part I think this was already a lot of information so let's have a break, refresh the mind and then we go into the case studies thank you