Let's go. Is there anyone who's willing to share the meeting notes on screen so we can follow along? OK, I probably can. Let me clear a few things up and away we go. All right. Can everyone see the share? Yep. Cool. All right. Fred, do we want to dive in? Have we lost Frederick? Sorry, mute button was on a different screen. Anyways, so let's go ahead and get started then. So please either self to the attendees list if you have not done so already. If you need help with adding yourself to the attendee list, let one of us know and we will add you to that in case you're dialing in or otherwise. OK, so agenda bashing, is there any conversation or any topic that anyone would like to have that is not on the list? OK, I'm going to assume that people are either on mute or don't have anything to say. So events we have at the end of this month, Mobile World Congress. So I was on mute, as you say. I'm just saying that asking for an architecture discussion and it would be nice to have it this week if possible. Sure, I'll go to the agenda. So I think the agenda list are not that long today. And I think we should absolutely, I think we should get to it. You say that with such faith. I always say it with faith. Once more in with feeling. So Mobile World Congress in Barcelona. So these have a tendency to aim more towards demos that are more service provider centric, NFE use cases and so on. So I will be heading over there for the conference. So if anyone has any recommendations on people that I should go talk to or companies I should go talk to in terms of getting them added to our network service mesh fold, please let me know. And I will go have discussions with them. Or if you're going to show up, we can go have a drink together. We have service mesh day coming up in San Francisco in 2019, which reminds me I need to put in a talk on that. So if you're in the area, feel free to attend. I think that that'll be something that it'll probably it'll definitely be more application service mesh oriented, but we're going to we're going to try to expand the scope a little bit. So we have ONS North America and San Jose. The call for papers is closed. That call for paper notification is not accurate. That's that's a little bit more aggressive. So we need to find out what the real dates are going to be. Anyways, that will be in San Jose on April 3rd through 5th. And we have a couple of talks that have been submitted. So we will see if they manage to get in April 9th through 12th. We have upper side conferences with the MPL, SSDM, NFE in Paris. So I don't know if we have any related talks there, but some of the content may be interesting. We have Container World. The call for paper is closing on February 8th. And this is in Santa Clara. So another one that we should definitely consider that we should definitely consider submitting in for. I think so we also have a co-located event at KubeCon. Actually, the Container World one, I think that seems incorrect because I recall the service match day being February 8th. And I think Container World had already announced their schedule. So we should not actually agree. Yeah, so that's the wrong location. So let's move that up. So the paper got accepted and Frederick also, I'm going to talk about the basics of network service mesh. Awesome. So I'm all OK. So one other thing probably I want to add is, OK, I'll let Frederick complete. We are also looking to submit a demo in the Elephant Booth for ODL and network service mesh integrated together. I just want to add that to the list, too. Can you add it? I'll add it, yeah. Cool. Yeah, so I think some of the stuff got mixed up. So I've fixed them up. So the service mesh day call for paper closes on February 8th. The Container World has already had its call for papers complete and the schedule published. And we have a network service mesh discussion or a talk that is being driven by a prem from Lumina. So we also have KubeCon EU in Barcelona, Spain. The call for papers for that is already closed as well. We're waiting for the notifications. And finally, we also have some co-located events that will occur, such as the Fido Mini Summit. The details will be announced later on. And we also have a KubeCon and CrowdNativeCon and Open Source Summit to all combined into one in Shanghai, where the call for paper closed on February 15th. So if you are in or going to be in that area, feel free to submit a talk. And if you need help with content, let us know and we will help you. And finally, we have Open Networking Summit ONS in Europe, which is going to be in Antwerp, Belgium. The call for paper window for that is still pending. So we'll get more information on that later. We don't have any announcements listed. So let's jump straight into the agenda. So we start off with STARS. And so we have one of our minor goals coming up is that we would like to be a part of the CNCF landscape. Part of what the requirement is, if you're an open source project or one of the triggers to become a CNCF landscape project, is to have lots of STARS. And that number is 300. So invite any people that you think would be interested in starring our project to come in and start. So we can jump it from, I think it's around 600, or sorry, it's around 60 at the moment. So we need to bump that up to around 300. So feel free to invite anyone else that you can find who would be willing to help with STARS so that we can land on that page. Is there anything else you want to add to that, Ed? Or is that good? You might be on mute. You are on mute. Yeah. So I'm adding a link to the repo here real quickly. Let me make sure I get it right, actually. So you can go click to the car. Yeah, folks could go. And if you haven't started the project yet, if you could please go start. Cool. Next, we have some specifications. So there are two documentation efforts I would like to try to get the community to drive. So the first one is a high level component view. So in other words, things like we have a network service mesh demon. We have a client. And we have an endpoint. So just what are those high level things? So on this, Frederick? And not to gang up on you and Ed with Ian here. But I mean, I know that there are several of us that are more than willing to help work on this. But I've been anecdotally harassing Ed on Google Chat trying to get answers to questions and collecting data. But actually having a full run down of like, these are all the bits. This is how they all fit together. Here's what we want people to see here. Here's what we want to gloss over, et cetera, et cetera. I think it'd be really helpful because what I don't want to do is spend a ton of time documenting things that are wrong, if that makes sense. That makes total sense. I guess the question is, what's the most expeditious way to run through some of that from your point of view?  We could sort of walk through some of the what's there. We've got a reason to do that on the abstract architecture, et cetera, that we can talk through and sort of get to the particulars. I could answer and grow down on the questions around that.  Yeah, that's kind of what I was thinking. We can either do it in this Tuesday meeting or maybe we set up a specific meeting with the people that are in that little group that we started. But obviously, you don't need to create an architecture that then present to us because then obviously that defeats the whole picture. I was just going to reuse some of the existing pretty pictures that I've got. Yeah, and maybe walking us through some of the code and stuff. Yeah, I think it's important that your pretty pictures, if they were going to solve the problem, they would have solved it probably by now, which is why we need your input as well. Oh, no, no. I'm not saying just go look at the slides. I'm saying let's jump on a call. We can talk through some of this. I'm happy to walk through some of the code. And as we need graphical aids, I've got a bunch of graphical aids on hand. Yeah, I mean, I'll definitely reuse work. But I think that would be helpful for us to just get in an environment. Let's look at the different processes running. Let's take a look at some of the manifests. Let's take a look at how things are stitched together. Like, if we're going to describe what a network service endpoint is, I need to legitimately know what it is. Absolutely delighted to do that. Let's do the following things. I'm happy to sit down with the folks who want to do the documentation. I do want to make sure to keep the actual calls public so that anybody who wants to come in and participate can. I suspect that this too big call is getting sufficiently crowded that it probably won't be the right venue. Because we do tend to be running up against the line. So I guess the question is, would you be willing to go start a doodle poll for a time that we could put together for folks to get together on a call and talk the documentation to the volunteers through whatever it is they need to be talked through? And I'd be happy to do that. And we can basically do an hour a week until you guys are satisfied. Long as docs are coming out of it, it's a more than useful investment of time. Yeah, I think that would be helpful to have like an architecture review call in conjunction with just because I mean, this one, we're focused on who's speaking at what future do we want to add. So I'm more like technically focused call in parallel with this one, I think would be helpful. Yeah, so if you could go and kick off like a doodle poll or something, make sure to CC the public list and we'll just sort of figure out a time and start doing it, sound good? Yep, sounds good to me at least. Yeah, and so the reason I added some of these was exactly for this reason. I want people to make suggestions as to what will be helpful for them. So my thought was we could probably start with a high level component of you. But if there's some specific area that will be much more effective, then we absolutely should start with those first. I mean, one of the things I want to be super clear about is effectively the folks who are working on putting into the documentation in some sense have a much better view of the kinds of gaps in the current explanations than I do or than I suspect Fred or Nicolai does. Because if we magically knew what the gaps were, we would just go fill them. So it's super, super useful to have another set of eyes looking at things, asking questions, and figuring out how to express them. Yeah, I fully agree with you Ed. In fact, I'm also talking to full of the folks and I'm getting questions collected out of it. For example, one of the things that has come in as the security aspect of it, yeah. So yeah, it's important that we collect it and then we document those. Agree? So I've also added a request for a coder, but it looks like Nicolai has already filled in an assignment. So basically, we have a readiness and life probe that has been specced out. It has a very easy first project or first thing to do. So sorry for the one question I have with respect to the to do items. Do we need to have special privileges to access this because I don't have the add God option. So let me sort of, this is a bizarre detail of GitHub. So basically, if what you're talking about is I went to try and assign myself to a bug and I couldn't. Effectively, with GitHub, you can assign yourself to an issue for a repo. In fact, I can't assign you to an issue for a repo. If you're not listed, at least as a read-only collaborator. OK.  Could you please add me to the list of read-only collaborator? Just give me your GitHub ID. I'm happy to do that for whoever wants to, right? Because then you can assign yourself to issues and that kind of stuff. Sure. I love that. Thanks. So yeah, I understand why GitHub is that way. And it makes sense. And they're actually right. But it is a little inconvenient at times. So we have a minor Slack revolt going on in the chat, by the way. Let's see. I could tell you that there are potentially minor complications on Slack. I would have to check and see if you go basically. Slack has a pricing model that's a little bit unfriendly for open source projects. And I know that that has been somewhat solved by other projects in CNCF. And I could see if we could solve it in a similar way. But I have also heard people mention spectrum.chat as an alternative to Slack. So I'm totally open to having the discussion if somebody wants to add it to the agenda. Yeah, my personal preference at this time would be to keep IRC until we join a project like the CNCF who can put the bill and manage users and all that kind of stuff. It turns into having yet another tab in the Slack app. And when I already have 10 to 15 tabs, and it thinks, yeah, unwieldy. So yeah. But I suspect Slack will end up happening eventually when we join up with a group like the CNCF or someone. Quick question for the folks who are highly in favor of Slack, which is a totally cool thing, right?  The first one. And also, I have the inverse opinion of Frederick. I'd rather have 15 channels than one chat application as opposed to having 30 different chat applications. Yep. No, I invite. That's another one of the argument, is it? The biggest issue I'm finding with IRC so far is when you actually chat in there, nobody answers one. But two, when people chat in there, then unless someone is recording the channel, I haven't actually seen a record of anything, which means that it said to people who are present at the time and then it's lost for all time. Yeah, so there are a couple of things there. I'm not saying these are, by the way, perfect responses. So one of them is a lot of folks use something like IRC Cloud, which keeps you always on and therefore keeps an always going record of the channel. The other one that I will mention is, and this is sort of weird. So FreeNode actively asks projects not to build public archives of their channels. And that's a little weird, but most projects I know have actually decided to respect that so far. Right, so maybe the easier answer here rather than chat app is we get a lot more consistent about using the mailing list for things. I find mailing lists enormously less productive than chat apps. Well, they are when you don't use them, yeah. So I mean, it's one of these things where quite honestly, that the communities fall in different places, depending on the personalities of the communities. I'm happy to engage with folks on whatever medium they reach out to engage. So for example, I've responded to, we've had a small number of emails that have hit the mailing list and I've been careful to make sure to respond to them. So, you know, if folks reach out to the mailing list, absolutely, that's fine. But most people prefer a more direct collaboration. As to folks that answering, I know that the channel is actually pretty flipping active, particularly morning in specific time because we've got a lot of folks working in Europe who are on the channel then. So, you know, lots of stuff goes on on the channel. So I'm not quite sure. Well, let me highlight where this tends to be a problem, right? Jeff's trying to document the architecture which has been agreed among people, presumably largely on IRC, which means we've got no record of the agreement or why they chose to do it that way or anything. That I think is a fine example of why we're running into problems right now. The agreement was from last week in the meeting which you weren't present in. So that was not actually on IRC. No, I mean, that may have been, that was in fact, last week in the IRC, meeting the agreement we'd document the architecture. The agreement on the architecture goes back a long while before that or else you wouldn't have written any code by now. So my point stands that there's some of this stuff where there's early discussions that are known by the people that have it. Well, in part of what's actually happening right now where we're trying to get better about that and I've just switched to the spec board is we're trying to encourage the writing of specs. So that they're actually structured in a way that's intentionally designed for there to be conversation around them. And sort of a good example of this right now is the monitor, basically the metrics piece of the spec that's been going on. And I know Matthew and I have had a very active collaboration around that. So basically we do have spec issues that are coming up. We do have the review of the spec board that's literally the next agenda item up in the meeting. And the way they're structured typically is there is an issue. Then the issue will point to a Google Doc because it's easier to collaborate there and then once we figure out what we're doing that will roll into the issue. So it can be executed on. Yeah, that's the end because you're correct.  So that was the idea towards driving towards these specs was let's find a way to get the community to surround and to start working on things in an area. And I don't wanna tell people you can't talk on IRC or you can't talk on Slack or in person or whatever but whatever comes out of that should drive through this particular process. And we'll evolve this process to be more accommodating to people as well over time. So right now we're just getting started with this. Well, I mean, the other thing I wanna be super clear about is this is also not the open stack looper in process. This is a way to try and encourage collaboration. It's not a mandatory gate in the system. So a lot of us who've been very active are trying to utilize it because we think it improves community engagement. But if you have some piece of work you need to do and the notion of going and writing a blueprint or a spec or whatever seems overwhelming, you don't have to, right? But it will probably lead to easier contribution because the spec will also often point out details like, oh yeah, if you were to change that this over here is probably also a good thing to change and that kind of thing. So, okay, so we seem to have muddled the agenda somewhat. I think we need to make sure that we capture having the discussion about Slack in the agenda. If someone could please add that. And then we have a couple of other items as well. Everybody on the per Slack team, okay, with making sure we capture it on the agenda and then we'll get to it here shortly. Sounds like that's the, so it added the per Slack group on there. So let's jump into the NSM release process. We still have a lot to go through. So, Nikolai, you're up. Do you want the share or do you want me to just, you know, follow it? I prefer to share. Take it then. It's all yours. Okay. And it shouldn't be in this one. Okay. I hope you see my screen shared. At least the browser. Okay, so in sync with whatever we already said about the specs. So I have initiated this NSM release process spec and it's in a doc here. So this is just a quick kind of announcing that this thing exists. Please go there, read it. We have at least one thing that we would like the voting from you. It would be the code naming. So we have two ideas already. And if someone has more ideas, please add them here. I know that we can talk on Zoom or whatever, but as we said, it needs to be documented somewhere. So, yeah, I don't want to go into much details here. We already exchanged some messages with it here. There's some proposal for the release numbering scheme when we call something stable, when not. Then we have a list of release materials which we are improving. We have improved a little bit and we are continuing to improve. So if you have some other ideas, please add them here, at least some message, if not directly editing the document. And then we have a kind of proposed dates which look good so far for our first release. So we have end of April, as a kind of set as a target date and then kind of a first patch release just before the KubeCon. The overall idea here is that we have, and this is actually the second thing that I wanted to share here, is that we have a project board here where we are adding the to-do-in progress and done items. And my proposal was, each of these were group calls. We do a quick, even for five minutes, just to go and see what is in to-do if you want to add something more in the to-do. And kind of just move the things around here and groom the, and have a realistic view of what's going on with the release. I think this is good. I would love to see more folks participating in the conversation about the release process. The other thing is, as I sort of look at the release process, there are a small number of things that we absolutely have to agree as a community on. A lot of good stuff in the release process, but there's a small number of things we have to come to an agreement about. And I'm not suggesting we necessarily agree about it this week, but we probably should next week or the latest the week after. And I think those things fundamentally come down to, what is the intended release date? Are we okay with, what is the intended throttle branch pull date? Are we okay with the branching structure of just pulling a throttle branch or a release branch from master? Which most people do, so I expect that's okay. And then the one thing that I actually kind of like about this, but I'd not seen before, is the notion of essentially treating the micro version zero as a release candidate, and the micro version one as the first stable patch on the thing. I like that very much, but it's not something I'd seen before. So I want to make sure that that's something that we all understand and agree with. Does that make sense to folks? Don't all speak at once. So there is no hard far or beta release? Go ahead. Yeah, not really. So the idea is that, okay, so this, we have a concrete dates here. So it's maybe easier to explain. So the first, so like one week before the date of the tag of the first tag, we create the branch and we start ensuring that everything that we have in our to-do list here is kind of done or nearly be done. And then one week later, well, this is on the 30th, we essentially tack the first release. We start turning code CICDs extra testing whatever we find appropriate.  So two weeks later, after we are kind of completely sure that we run through all the things. I mean, this is not completely specified. It's what this extending testing would be. It's just like a way to say, okay, you have two weeks to, before you declare that this is something that you consider stable. And once it gets to 1.1 or actually 0.1 as a minor, it's not the patch, it's actually the patch version. So once you get to patch version one, you say, okay, so this is stable. So this is something that's proposed here. It might work, it might not work. It's kind of driven by the fact that we want to go with the same versioning. And I guess that adding some, you know, key characters in the end, like if you want to add here kind of beta or something like that, that's not exactly fitting into the same way. That's actually kind of part of why, even though I've not seen it before, I sort of found some nice benefits to this approach. But I do understand, I think the point that was made about wanting to have an alpha or a beta version, in some sense the, you know, in some sense people call them release candidates, et cetera. In some sense, I think what you're suggesting is that we treat the microversion of dot zero as essentially release candidate or beta, correct? Yeah, yeah, something like that. Does that sort of match the concern of the folks who raised the alpha beta thing? Actually, it really makes sense because we used to deploy on the dot one for all the two reasons and so on. Yeah. So what you're saying is you wouldn't trust us anyway until it's dot one or not too, so yeah. I think that's the wisdom of this approach. But, okay, just please go there after comments that's what we want and what we need the most and the better. There's a ton of other good things in this document of interest, sort of a small number of things and they're good for setting direction and I like them a lot. But the sort of the community agreeing on sort of the dates and the basic sort of branching, versioning structure, those are things we have to all agree on. The other stuff is much more malleable over time. I mean, it provides good guidance and focus but if somebody comes in and says, well, you know, I fervently believe that the first release should have SRV six and so I'm going to go work on that. Well, okay, sure, that's not actually a problem but if somebody says, oh, your release date is terrible and by the way, I want to use your month-to-month versioning, okay, that's not something we all have to agree on, right? Yeah, that's... Okay, so yeah, I guess that we're going to go through this next week again and I hope that we get some comments by then. Yeah, and my hope is that next week that we could sort of come to agreement that, okay, these will be the dates of the branching and versioning structure, et cetera. So particularly if folks are, you know, have differing views about that, like that train is leaving the station probably next week. Yeah, and even just a simple plus one somewhere just is somehow voting can think, okay, higher proof. Yeah, it's super, super helpful when you're trying to plan things. Just if you just agree, just agreeing silently is so much less helpful than agreeing vocally. Okay, good. And the last thing that I had in my list for announcing is the existence of this new repo under the network service mesh GitHub. So this is an attempt to have a separate infrastructure which will allow you to easily build applications if you want to call or kind of full-featured examples and proof of concepts or demos while relying on as less as possible from the full network service mesh repo. So there is some documentation here. Of course, a lot of this structure was copy pasted from the original repo and a lot of the things were just cut down and stripped down to the very, very, very basic minimum that you want. So essentially you can spin up a vagrant and then you can just deploy the basic infra and it's all in here. But I just want to show you what the, I didn't get an example is, no, it's not here. Should be here, sorry. So there is the read me which explains what you need to do, but it's very, very, very easy. So there is this make file which essentially just describes the name of the example then all the containers that you need to build which should exist as folders here under the example. Then all the ports that are going to be deployed. This eventually reflects to the naming of the YAML files that are going to be applied and then you can add a check command. And from there on all the targets, all the make file targets that are needed, they are generated automatically by just including this target make file. So the purpose here was to really make it easy without knowing much and went out going into all the details of the built infrastructure to just be able to go out all the pieces that you need. I particularly like this because there's a psychological weight to a long make file, even if you only have to change something in the first instance of it. And so the fact that there isn't a lot of lines visibly following I think is going to also be good in this case. So one of the things I did want to comment on, I'm actually super happy that we've now got the examples repo. And while I don't think there's any great urgency, I think it would probably be good to migrate some of the existing examples in that direction. And one of the things that's actually gone on in the main repo is even though the main repo is only about 22,000 lines of code, thematically it's kind of gotten a little bit big. There's just a lot of things in the main repo. And so starting to more intelligently use other repos is probably all for the good. Mm-hmm. So one of the things that I want to just start explicitly here that here we don't build any of the core containers, so NSMD, the data plane, all these things are essentially pulled off the GitHub. So for example here in the if, when you want to build the monitoring, these are just the same YAML files that you'll find in the main repo, but they just rely on the fact that you can download the containers of the Docker Hub. Yeah, so that was it. One of the things I did want to throw out there, we've got a lot of make file machinery and it's done lots of useful things. But one of the things, if there's someone who's interested in working on it that would be super cool is, a lot of the stuff we're using the make file machinery for probably could be better done with Helm at this point. And so if you're interested in doing some Helm charts to sort of make things go more smoothly, that would be super welcome. I was going to say that next, but you beat me to it. Another nice property. The most authoritatively is that the make machinery is my fault, so. Another nice property of this as well by having the examples and migrating them here is that we want to tell when we're breaking the community and as we know about all changes are structural in nature. So if there's something that semantically breaks with in a change, then these examples act as integration tests where since they haven't been refactored or as part of the main core, we're more likely to catch those type of behavior changes and be able to report them as breaking changes or make a decision to refactor back to the non-breaking version. So I think even though this will cause a little bit of extra work on the CI side and in the core development side, I think it has immense benefits to the community from a CI perspective. Yeah. Okay. So please, I tried, sent issues, suggestions, more than welcome. Okay. So with this, I'm actually stopping my share and go to the screen here and who's next? Okay. So we, Ian, do we have enough time to discuss your it's been put off for four weeks. So let's do what we can do in 10 minutes because I think we've got a fundamental issue here. So basically what we have at the moment as a theory is data planes connecting service endpoints to service clients. And that has its uses and as have been demonstrated at KubeCon as an example. And that's fine. But the issue I run into is that it seems to me that firstly, we've got two problems with this model. One is that we're talking endpoints and clients as if there's producers and consumers of network of networking, which I don't think is how the world works because if you look at physical networking then when you connect a router to a switch you don't call one an endpoint and one a client. That's not how it works. So there's that. The other one is that as things go the data planes that we've built have been using Kubernetes networking as their connectivity just to make a point and get things passed out the door, which is fine as far as it goes. But practically speaking if you're doing, if you look at NFE as an example of how fast networking works then 50% of this is done with SRIOV interfaces for speed and also you can't ignore the physical infrastructure when you're trying to work out what connectivity you've got. So if my Kubernetes boxes are all connected to a router versus a switch then that gives me different use cases, different behavior or the same data plane won't necessarily work with both. So I think the question I had was and I think the reason we've managed to avoid this so far is we haven't really looked at the lowest level of this, what we're building from. Oh dear, I think my headset's gone flat. Hello. So here you are. All right, that's fine. My headset just went. You're definitely not talking to me entirely. All right, so my take on this is and the reason I wanna call this an architecture topic is I think what we're doing is we're building the house without building the foundation. We've got a fairly good idea of what a service mesh would be for people who wanna consume it as a mesh but we haven't got a way of building a service mesh because we haven't talked about the low level building blocks that we ought to be building with. Providing without giving them privileges providing a container with an SRAV interface to take one example. Providing with container with a MEMIF which isn't really or providing two containers with a shared MEMIF. That kind of thing. So that we're building on a platform that lets us do the sort of mesh of things that people are excited with. You containers with shared MEMIFs has been working since October and November. I understand that, I wasn't saying that it didn't work. I was saying that it's not really a separable building block. I mean, we talk at the moment in terms of a data plane that connects a client to an endpoint and setting aside the point about they're not necessarily being things like clients and endpoints. There might not be a data plane involved here either. You might just want to connect two containers together for fast networking purposes on the same host which you know are on the same host. So, and I know you know that I had some questions around this too, right? Like, because MEMIF works great if I'm on the same host and there are gonna be instances where I will dictate to an application dealt with microservices that hey, I want to make sure that this is how you deploy. But I mean, this whole concept of us going truly cloud native, right? Like not recreating open stacks problems too is I would also like the alternative if I do have an extremely fast and powerful fabric sitting above this. If my network engineers have taken the time to actually put this whole spine and leaf thing above me then I would also like the potential ability to intelligently create services where the containers have their own interfaces and I just use the physical network northbound to do all this, right? Without necessarily introducing a bottleneck with a network service endpoint. And I think Ian and I are kind of both wrapping our heads around this from like different angles but are trying to reach the same goal yet. I didn't overhear you. So here's the thing I would sort of say there, Jeff. Jeffrey. Mm-hmm. Definitely the ability to treat an SRIOVVF as the sort of local mechanism that's called the computer container. Definitely that's something that needs to be done. Yeah, but how do we treat the switch as a network service of some variety an element of the way that I have been conceptualizing in my own mind, the physical network around this is that if you want, and this is one way to conceptualize it is if you think of the Tor port, the top of rack switch port, that let's put aside the SRIOV for a second. Let's just talk about the physical neck. We'll come back to the SRIOV because I agree it's important but the story is easier to tell originally without it. So if I just have a physical neck that I've plugged into my container as a local mechanism, I would actually like it to be the case that it gets from the physical network as some kind of treatment, right? And from my point of view, effectively what that means is that the Tor port that that Nick has plugged into is in fact providing some kind of a network service that you would like it to provide. And so that's how I've been sort of conceptualizing this so far. Give me just one second and let me dig up the sort of scribbles I've done so far and see if they help. Well, to take you from there, right? Then that says that a data plane is a network service and a data plane consumes a network service as well if it's using the Tor to actually get its connectivity host to host. And if that's the case, then I don't necessarily use a data plane to connect one network service to another. So my point is that our lowest level of building block before we start talking about meshes, you know, and I use the equivalency here and I don't want you to get distracted with the way that we're integrating with Envoy. But my point is that Envoy is a form of networking that builds on Kubernetes native networking. So there's a high level and a low level. Feels to me here, like we've got the high level but we haven't got the low level here where we've got things that, you know, don't need connections that reach across from host to host. We just need touch points, if you like, very local things that are on host or host to network. But it also feels like if we take, if we look at what's inside a network service, then we've clearly got a control plane element and a data plane element. The control plane element has a certain API that we like and we respect and is, you know, defined by NSM. But the data plane element could be, you know, VPP in a container or it could be the kernel being controlled by a container but it could equally be the physical switch or the physical router. No, no, I'm completely fine with all that. So I've been trying to break off some time to draw, to sort of lay out some of the pretty picture pieces. I've got some scribbles that I could talk to if that would be of assistance at this point, if folks are interested. Is that something you guys would be interested in at this moment? Yes, I have similar questions and I'll be interested in that. No, no, it's a perfectly valid set of questions. Yep. You know, and sort of part of the reason I haven't written them down yet is I first need to write down the inter-domain stuff for it to be. Let me ask you a different question before you start down this. Could I run NSM with no data plane at all? No, not currently. Why not? Because something has to be able to handle making sure that you're actually connected to the network service that you want it connected to. And it's local. Something has to be able to do that for you. But if it's local to me, if it's local to my host or, you know, again the physical switch, then I don't need a data plane for that. So I think perhaps the semantics of the word data plane are getting in the way here. So I'm looking at your definition as you've written it because again, your code defines it at the moment. Hello, I'm sorry to interrupt. I having a lot of trouble hearing, but I think this is a conversation that's real relevant to me. So please yell at me if I, or yell very loud at me if I am stepping on or repeating something that was already said. I think some of this might be clear if we implement bare metal services and infrastructure on like for example, on packet.net and put VPP on the data plane and then use memf to connect to the pod and then have, and then the data plane, the network service match data plane abstraction would quote no unquote, how to tell the real VPP data planes, for example, how to set up the kinds of connections we're looking for. And I think most of that is probably there, where we are. But to me, that's connected in some way to the SRIOV discussion, the MPLS discussion that Ed and I have that I think if we implement our real network, like for example, in the CI, that way.  So I'll speak extremely loud, not because I'm in any way upset, but to try and help Tom here. We have a challenge here in that until either, so one of the following things have to be true. We either have to use a mechanism for talking to the next, it's not DPDK or we have to, or DPDK has to change to be more tolerant of not getting the numizome that it wants or Kubernetes has to allow you to actually manage the numizome correctly, which it doesn't currently and I don't know when that's landing. Or we have to use some alternative mechanism, like for example, we do have native AVF drivers that can talk to SRIOV NICs without the DPDK problems and we could potentially use those. But there's one remaining option. We could turn off the second socket on the server, but there's a fundamental mismatch where DPDK is very insistent, the world has to be precisely the way it wants it. And that's just not how Cognitive works. Yeah, that's fine. So this is good, right? You're naming things that need to resolve themselves in order for us to make things useful and that's completely acceptable. So where's that on our tracking? So I'm happy to put that on the tracking. None of those are actually problems that lie within our hands. One of them is... Well, I've got pair of hands that we have a lot to do. The DPDK community has to change its mentality from, we are... It can be a part of the DPDK community as well. Maybe I can go from an end user potential potential end user view point is, I agree a bit with Yen, is NSM as a mesh would reside whether you decide to have, like I'm a fan of SRV6, but you could have all your hosts running SROV ports or you can actually hardwire the NIC directly to a container if you want to. The notion of being able to abstract how the service mesh is actually represented in physical is kind of independent. You have your pick and choose and you might go fast with the DPD but it ended up being sometimes you're gonna have something else. So those iterations of how to represent the data plane of an NSM will evolve over time. Being able to abstract that to understand that there is, for example, locality services. If an NSC is, for example, an SROV port, darn, you have to have the logic inside the NSM to say, well, if my client needs an SROV NSC, please make it on the same house. And the plumbing underneath it needs to make sure... That part is easy. The part that's broken and the reason that I haven't been driving the SROV so hard, part that's broken is that DPDK thinks, right now... Look, Ed, we understand that DPDK has got its problems and it's not going to work until we change it. That's totally fine. But my point is, let's stop avoiding this conversation because DPDK is broken. Let's have it because we've got to work it out to fix DPDK for this. We can't run it in a container. Then we've got nothing, quite honestly. No, the problem is you can run it in a container but you can't run it in a container in Kubrick in a pod. This is the thing to make it really clear. There's a huge gap in cloud-native networking. This is an essential example of that. Now, I have people who work on DPDK to try and get this fixed and I'm also tracking efforts in Kubernetes to have a cloud-native way of doing NUMA zones. I would be really happy to have more people involved in those discussions. But until those things get fixed, effectively the only way to run anything that uses DPDK in capacity inside a pod is to only have a single socket server. Yeah, fine. But when those things get fixed, then we come back to that question of, we're not really, you're building, we are building today a thing which will connect a network service endpoint to a network service client regardless of where they lie in the system. But I think we're building it from smaller building blocks which is things that actually neighbor each other and touch each other, whether that's a switch to a container via an SRAOV interface or a container to a container via NEMIS. So what I was trying to say is that I think we've got a lower level of abstraction that we haven't really looked at yet. And yes, maybe it's because DPDK is not ready for us but I think we need to be making our preparations. No, so I think basically what you're saying is you need to know what the story is for how this is going to work. And so we can find the architectural level, discover whether we are likely to have them for scene issues, sort of, you know, and try and get them resolved. And I think that's actually a super good idea and a super good point. The reason it has received less of my personal attention at this moment is I, you know, if I were to go off and write some code to try and do this, I literally can't realistically test it until either DPDK realizes that it's not going to have dictatorial control over the whole box. And so before we, before we continue on, before we continue on, we're already a few minutes over. So we should punt the, Oh yeah, I do have to, yeah, I want to say. I think, so I think that the key here is, I think, Jeffrey, you're going to get a doodle pool going to have some architectural discussions. I was going to say, so two things that is one, I have a direct line to the Intel development team. And they're always asking me what open source things that they can work on for me. So let's leverage the fact that I work for a giant SP and get people to work for us. And then second, I don't want to take a single bite of this and be told I can't have the rest of the meals. So can we save these slides and all that for like these architectural meetings since we're already over the hour? Yeah, I think that's probably the right place to do it. Absolutely. All right, so Ian, just, you know, get offline with me and I will look at flexing the charter muscles and seeing if we can get some Intel people to solve some of our challenges for us. All right, cool. Go ahead and include me in that as well. And thank you. Closing it up at the same time next week. See you all there. Later guys. Take care.


Hello, today I'm going to be talking about ethics at the edge, IoT is the embodiment of AI for rampant intelligence actuation, so let's dive in. For today's agenda, I'm going to be talking about individual vectors of AI ethics and their implications for the internet of things, evolving principles and governance for IoT devices, definitions of trusted entities and key ethical principles in the context of IoT security, and finally conclude with an interesting formalization on moral machines and key unconventional considerations for human-centered design intersecting with the AI ethics and internet of things domain. So let's get started with the what and why on AI ethics for IoT. We're seeing a lot of headlines in the media that are addressing some top concerns in the AI ethics space. So some of these recent headlines include important ethical concerns being brought to light by uses of facial recognition and surveillance technologies that are violating some ethical concerns that we have in addition to hacking of surveillance systems from the IoT security standpoint. We're also seeing in a general perspective the impact of AI systems in our society. For example, AI's carbon footprint problem, the evolving regulations that are attempting to handle a lot of the concerns that are raising in this space and the tie-in to AI and power dynamics as all being a part of this landscape and a lot of the concern around AI. We have some good positive developments happening in this space but also a lot of interesting and important concerns to consider in the context of IoT security and the impact of these solutions on societies. And this is a great segue to the way that we're thinking about AI ethics. It's a pretty broad field or space and really we can consider this to be, I would propose, a socio-technical lens on the design and impact of AI solutions on our societies. Now if we start to consider what is the implication of this for Internet of Things, here I'm proposing that, of course, Internet of Things devices are consumers and producers of data. Now we take that concept and also starting to understand that they're also enablers of actions made by intelligent autonomous agents. This is also the reason for that phrase rampant intelligence actuation as part of this presentation title where AI algorithms and smart analytics are being leveraged by Internet of Things devices in order to make intelligent decisions. And as part of this we're starting to see a lot of emphasis being placed on the actuation component of the pipeline and being able to understand and apply ethical and trustworthy guidelines toward this to prevent rampant intelligence actuation. Now as part of this what we're seeing is the commissioning deployment and maintenance of AI systems and compliance with ethical governance is an Internet of Things problem. Considering the differentiation between ethical and trustworthy AI, the line is pretty blurry. I would like to propose that there is analogous correlation between ideas of alignment and intent where you have a system that can be trustworthy, it has support mechanisms in order for its users to trust its decision making and it has transparency, etc. But it's not necessarily designed with an ethical intent or with good intentions. Likewise you could have a system that is designed with good intent, it has good ethical implications on society but it doesn't have any support trustworthiness mechanisms or metrics in order to help the users build trust with the system going forward. Now given this let's dive into the individual vectors of ethics for IoT. What I'd like to propose here is a framework or a way of thinking about the dimensions of AI ethics that we're starting to see. These include transparency, also encompassing auditability and accountability, sustainability, fairness, security, safety, and privacy, and finally vulnerable target populations and varying use cases where that one is intercepting with all of these different vectors and we're seeing that it's influenced by each of these but is deserving of its own standalone implications and similar when we're starting to see how regulations, policy, and technical implementations are changing depending on the type of use case. Now diving into this further let's go into each of these. So for the transparency component this is including ideas around the right to understand the how and why behind AI decision making throughout development and deployment of AI systems. On the topic of sustainability this also encompasses energy efficiency where for AI algorithms we're considering low resource implementation of these systems in IoT ecosystems. In an interesting statistic I'd like to share with this audience an off-the-shelf AI language processing system reportedly produced 1,400 pounds of emissions which is about the equivalent of flying one person round trip between New York and San Francisco. So there are alarming implications for AI systems. Now in the context of internet things, devices, and ecosystems it's important to start to consider the implications here and I'm leaving it at a pretty high level. There's a lot more research and investigation that needs to be done in this space. Similarly for fairness and bias we're looking at two interesting ways of thinking about this. First from the social context where we want to be able to mitigate and prevent data sets and methodologies that are allowing AI to reflect different types of manipulative power dynamics. That's from the social context standpoint. Now from a technical context it's a little interesting to also think about this from the point of view of again an IoT device where we're seeing representative allocation of resources and prioritization to edge devices also coming under that representativeness, fairness, and bias definitions. So this latter point is pretty trivial in the context of prioritizing processes and made by edge devices but in the context of these AI ethics definitions nevertheless interesting to consider. On the security safety and privacy standpoint we're looking at ethical review and enforcement of end-to-end AI safety and privacy in the cloud and at the edge including capabilities such as sandboxes and isolation of model capabilities for testing. Finally on that last point vulnerable target populations in varying use cases we're seeing again this point intercepting with these other vectors and this is really hitting at customizability of the system and the overall pipeline and during deployment as well to accommodate regulatory and user feedback and feedback from societal norms. Now looking into this further let's go into some interesting thoughts around risk management for machine learning taken from a wonderful summary review that's looking into this in detail and proposing some assets that should be considered as part of risk management it can find the links to these relevant materials in the slides. Now as part of this for the input data assets that we're looking at there are a few key considerations I'll call out a subset of these here so we've got documenting model requirements as key from the documentation and transparency standpoint assessment of data quality and encapsulation of models as additional two components that are necessary from the security and trustworthiness components as well. We've also got monitoring of the underlying data testing and monitoring of data drift which also involves being able to characterize the behavior of data and its impact of AI systems. Finally we also have the idea of making alerts actionable this is again placing emphasis on that actuation point of the pipeline where okay you detect a violation in you know a trustworthiness threshold or an ethical threshold to some level what are you going to do about it and can the system act autonomously on this or not these types of interesting considerations and again this is just a subset of some of these there are much more interesting implications that come out of this. Similarly on the output assets perspective we're starting to get to the considerations on the deployment of AI systems for example in IoT ecosystems here so as part of this we want to think about exposing biases throughout development and deployment of the system occurring at all stages of model design and implementation. This may include determining the model's reliance on sensitive features for example you know sensitive demographic data and any features that could also act as proxies for this information that we hadn't initially anticipated. Similarly we also want to see here clear documentation and methodologies established for continuous monitoring detecting a feedback loop so we're able to identify algorithms that are influencing each other in ways that bias can trickle into the decision-making processes. Documentation of all testing and being able to pull models from production including consistent validation checks which can occur again by being able to deploy some trustworthiness or ethics measures either manual or automated that are able to keep us up to date about the behavior of our model in relation to these guidelines. Now some interesting sample open research questions that I'd like to pose to the audience here. In the context of the Internet of Things we're starting to see some interesting points arise so one of these are how can AI consider balance cultural values while considering individual personalization so we're starting to see some good and robust definitions of fairness and bias emerge they still work in progress things like group versus individual fairness societal versus statistical bias and similar but the premise with my thought process here is will the edge in the cloud redefine some of these definitions for example just taking fairness as an example in distributed environments. An example might be personalization and generalization for recommender systems where you might have a case for local bias and let's say interactive kiosks you know where it might be nice to have personalized recommendations based on information that's collected on diversity and societal norms and have that reflected as part of interactions that a user is making in order to better align with their preferences and similar and again you know this does raise some interesting ethical implications that are also increasingly relevant given a lot of the regulations coming up in this space so an interesting add-on to that would be whether biases should be limited to edge notes instead of impacting the AI model that's hosted on the cloud. A lot of more work that needs to be done in this case but some interesting questions for discussion. Now next up let's talk about governance and here I'm going to do a very high-level perspective on implications of Internet of Things for AI and more due diligence needed on the viewer side as well to kind of dig into these regulations and figure out the applicability for business outcomes in addition to the way that we're developing and thinking about AI systems. So here in terms of IoT in the context of AI governance I've taken a definition here from the European Commission's Communication on AI on AI based systems where they describe how AI based systems can be purely software based such as a voice assistance and similar or can be embedded in hardware devices and this includes Internet of Things applications. So a general comment that I've made just surveying some of the regulations and policy in this space is that IoT ecosystems and applications are typically considered for the sensors or input component of an AI pipeline in the formulation of these guidelines. Now again hitting back on that point I mentioned previously we see that the commissioning deployment and maintenance of AI systems at the actuation component of the pipeline as well in terms of the decision-making processes AI is making by itself and leveraging the IoT ecosystem to do so is an Internet of Things problem. So we talked about some of those output assets as part of risk management for machine learning and again you know revisiting that some upcoming actuation considerations for AI ethics include piloting regulatory compliance that's consistently occurring during deployment evaluating the user experience etc and these have some interesting implications for the Internet of Things that we should start to consider. One of these include the implications of ethical AI vectors for model splitting and partitioning which is still being examined that's going back to the idea of you know splitting or considering biases differently perceived on the edge versus the cloud is that relevant does it make sense and how does it align going back to the user experience and the societal impact of the solution with what our users want. I'm showing here two interesting case studies that are referencing Internet of Things in the context of AI governance. One of these is from the OECD public consultation on a framework for classifying AI systems where they describe a interesting case study around managing a manufacturing plant. So this system is taking as input multiple different data streams and of different types. It's a composite system composed of different models that are interacting with each other and are responsible for a couple of different outputs related to the decision-making process at a very high level. Similarly to the right we're also seeing a diagram from the FDA's proposed regulatory approach on an AI ML workflow for software as a medical device. So as part of this they have started to investigate the idea of regulatory practices and best machine learning or good machine learning practices during the development and deployment of these systems. This also ties back to those vectors that I was discussing earlier emphasizing on transparency security safety and reliability privacy fairness etc. Now I do also want to address this interesting concept of accountable anonymity that's starting to emerge as an important user preference. So according to the recent governance in the space and also the practical implications of AI systems we're seeing that trustworthiness and transparency of data usage and governance are key considerations. Now accountable anonymity is an interesting idea. There have been a couple of encryption schemes and methodologies and similar developed on this but the definition that I'm trying to apply here is the ability to offer levels of privacy while ensuring accountability and this can include capabilities such as data provenance or similar. I'm also referring to methodologies such as differential privacy on learning etc that are enabling the ability for users to track their interactions with AI systems over time, retract their data if they choose or also influence the way that the AI system is reacting based off of the data that they're providing. There's also an interesting news article that I'm showing a snippet of at the bottom of the slide here which is also kind of highlighting some of the interesting or important implications of IoT gadgets and the toxic legacy that they're leaving. This of course again has implications for AI systems where these algorithms are constantly consuming and producing data performing evaluations and forming understandings and representations of our data inputs. So accountability or accountability plus anonymity is an interesting concern to think about upcoming. Next let's dive into trust identities which is a bit more of a deep dive into the levels of autonomy of AI systems. So here we're looking at the definitions of trust identities and human oversight based on some initial guidelines that have been proposed in policy frameworks, you know governance models and similar. So the four primary levels of AI system autonomy that have been identified here include human support where an AI system is not able to act on its recommendations or output. Human in the loop which is where the primary emphasis in the field today is being placed according to what I've seen where an AI system can act on its recommendations and outputs if the human agrees. An example if this might be the medical diagnostics application where a medical professional is leveraging the AI system to gain insights about a particularly complex problem that fits the representation and overall structure of the AI algorithm for the task but this professional is making the decisions and can choose to leverage or not use the decisions that are outputted by the system. Next we also have human honor over the loop level of AI autonomy where the AI system can act on its own recommendations and output unless the human vetoes. I personally see this as an interesting evolving consideration of user experience where the AI system is not constantly pestering the user for validating its outputs every time but is able to identify critical outputs that need to be brought to the user's attention and not proceed or determine some sort of threshold accordingly in order to get important or salient user feedback at the right time. Finally we have a intriguing application or level of AI system autonomy around human out of the loop where the AI system is able to act on its recommendations output without human involvement at all and we're seeing modifications of these autonomy levels leveraged in the European Commission's guidelines on trustworthy AI, the OECD public consultation framework I mentioned earlier, the Singapore government's model AI governance framework and additional documents. I also want to briefly touch upon approximate stakeholders in the AI supply chain. So for example some of the users or the folks that are interacting with the system and are influenced by the levels of autonomy of AI systems include model developers whose role might include debugging performance increase biases etc. Business owners which are trying to evaluate the fit of the model and the agreement of the use for use cases this may also include the definition of data controllers and data processors that are proposed as part of the EU Commission's guidelines, model risk evaluators which are responsible for checking the robustness and deployment readiness of AI systems, regulators which are responsible for reliability and impact assessments etc. And finally our end users and consumers where transparency is especially of an emphasis so our users are able to understand the comprehensive AI pipeline and able to interact with it in a meaningful way that is best aligned with their interest. Next I want to quickly also go through some critical issues revealed from the Ricotta hack which was a large-scale privacy breach. I recommend reading the news article to learn more if you haven't heard of this already because it's a very interesting IoT security use case and I want to generalize some of those insights or findings to AI ethics as well. So the importance of authentication and authorization is shown by these types of recent large-scale privacy breaches as a very quick high-level summary of this hack. Employees and or third-party hackers were able to gain access to a super admin account that was designed for debugging. Now they were able to use this to leverage sensitive or access sensitive data and they were able to do this by giving themselves permission under the guise of testing the system. So some three critical issues that I'm pulling out of this for our discussion include lack of review of justification or documentation for access, no time-bound access rights and the ability to override customers' privacy modes due to misplaced trust. And that third point is especially intersecting with AI ethics and trustworthiness considerations. While the first two are related to transparency and the mechanisms that we're putting in place in order to ensure trust, the third is also highlighting on ethical dilemmas as well and the interpretation of those vectors that I mentioned earlier in the context of trustworthiness and overall in IoT security. Bridging based off of this we are also seeing transparency as an interesting concept that's starting to serve as a double-edged sword. So some proposed attributes of human-centric IoT trust models could include trusted attributes and delegation. Now when we're starting to include transparency as a mechanism or a way of enabling these particular attributes we're starting to see some contention here. For example, explainable components of a machine learning pipeline for debugging purposes can overlap or expose some security and privacy vulnerabilities. And an example taken from a very interesting academic paper that's looking into this include the different types of explainable AI methods and potential security risks that they can pose. So here again at a very high level mentioning the names of these attacks and the associated risks, explanation by example AI interpretability and explainable methods require access to sets of reference data, but they pose privacy risks due to the access of data that's required. Model transparent methods reveal model weights which can make it easier for attackers to infer underlying data. And differential privacy is an interesting methodology for anonymizing training data and useful, but it could impact the quality of the explanation and the overall accuracy. So a lot of different contentions that need to be explored as part of this, where these vectors can serve as double-edged swords. And here we're using transparency as one of these case studies. I'd like to conclude with some intriguing implications on unconventional considerations for human-centered design for social reasoning and moral machine. So at a very high level here we're starting to look into what social reasoning means for AI systems. How do we instill value alignment in AI systems and in the context of IoT ecosystems moving aside for a moment from some of those practical implications, risk management frameworks, governance and policy frameworks, etc. What does this mean also from the implementation of the research perspective, forward-looking? So one of the key principles or the ideas that we're seeing in this space is the idea of techno-solutionism, where technology is being leveraged to solve problems that were created as technology, as a high-level description of the trend. So this also has some interesting ideas that are applying for AI ethics. An example of this is in the value alignment space, where we need to understand that setting discrimination and fairness types of principles and concepts in stoner code without transparent processes can violate democratic ideals. And this was very nicely noted as part of an excellent survey paper linked here. So just taking fairness to that case study, it seems important to be able to automate fairness while respecting an enabling contextual approach and the extent to which we automate this in relation to those trusted entities that we design the stakeholders involved in the pipeline and the types of mechanisms that we're imposing for trust. All of these need to be considered. We also need to consider what are the types of societal implications and proposals that we can make from the governance and policy perspective to support this, because one of the key issues or challenges we're encountering with these technical or practical solutions is just because you can do it doesn't mean you should. So on this idea of incorporating social reasoning into AI systems, I also want to mention some very interesting research on creating a dataset for visual common sense reasoning where some researchers are attempting to be able to incorporate common sense reasoning or in general reasoning about images and similar supporting data from different modality types as part of AI systems. This is still work in progress and here I'm over exaggerating for the purposes of a forward looking perspective, but what I want to drive home here is this idea of embodied AI where we're bringing the gap between tasks such as language generation, which is the task that was investigated by the researchers in the paper linked at the at the right. You can see the image here and actuation at inference. So embodied AI can be considered as the cool terminology for AI embedded in IoT ecosystems where we're giving AI a body methodology or a way of being able to act based off of its evaluation of data and being able to evaluate exactly what points as part of that pipeline it's okay for AI to act on, how we may be substituting too many technological solutions in light of concerns that should be addressed for more of a societal lens, etc. These are all key considerations in the development of these systems and being able to instill social reasoning for AI as well. Now some additional interesting considerations on how versus why and the idea of explainability and causal methods. So I'm outlining some interesting thoughts in this space. For example, we're seeing causal methods in the AI space focusing on why the AI system made a decision or being able to infer regarding why other parties or entities have been making a decision. I'm seeing AI explainability is an interesting answer to the question of how the system is making the discussion and self-improving and guiding AI is a key factor that's starting to come into play where we see AI systems trying to understand how they can improve their decision-making system, defense, or role in a particular framework in addition to how other entities could do so as well and provide recommendations or improvements. So ethical considerations here include embedding human intuition into AI algorithms, reliance on automation and the human in the loop concept and neutralizing human misintent. Now on that last point I want to present an interesting use case here. So this is a use case for an unconventional concern for human-centered design around when users are a threat. So at the left of the screen you can see a GIF here that's showing a robot that's being deployed in a mall where you know essentially it's trying to navigate through a bunch of people and as part of this we're seeing some interesting behavior from the children where they're playing around with the robot but it sometimes escalates to become more violent like with kicking, hitting, etc. So in this case users that we planned for and anticipated for have become all of a sudden an unexpected threat. Now interestingly as part of this paper what the researchers did is they built a attack evasion simulation planning model and they made the robot change its original destination when they were predicting the children about to approach the robot and make some trouble. So here the AI system and the engineers who are developing it are accounting for the fact that users can be a threat and designing accordingly rather than trying to influence the people themselves. They are trying to do this in a way that influences the robot's behavior but in a way is also able to influence indirectly the entities that it's interacting with. Now that's an interesting safety model and this is also bringing a concern of when should humans be out of the loop? How do we differentiate between regular and malicious users? And explainability or transparency again is that double-edged sword so as we continue to provide a lot of information about AI systems and ensure transparency how do we protect against potential malicious manipulation and circumvention from users that can exploit this information? So a very simple and high-level example might be users jailbreaking or hacking AI models provided by an API for their own use. In the case of an IoT case study let's think of a healthcare user trying to hack the number of steps they've taken through a smartwatch and for smartwatch users you may have noticed for example if you wave your hand around do some typing or playing the piano it'll walk some steps for you in addition to what you've actually truly accomplished for your exercise goals. Now as part of that that's kind of a trivial example but the ability to manipulate systems especially when given a lot more insight into them is interesting and it has some implications for users that are you know for example in the medical space where let's say you've got a user that wants to maliciously try to hack into the system and be able to say something like you know I've taken these many steps per day or I've taken these medications when in reality they haven't. So this could be malicious this could also be you know just a neutral intent or you know the user of the system is not necessarily aware of that they're interacting with the system in this way so it's really this interesting balance of transparency versus security and how we're anticipating for these different case studies and different profiles of users those who may have a malicious perspective from the hackers angle those who may not be aware that they're influencing the system in this way and those who need some help to understand the system's outcomes and can improve accordingly. Finally I also want to address another unconventional concern for human-centered design of AI systems which is this idea of AI systems hacking into themselves or you know beating themselves and as part of this we have an interesting case study on adversarial examples for reinforcement learning I highly encourage watching the video for an entertaining but also a very intriguing and potentially alarming application of you know reinforcement learning agents trying to fight and essentially outsmart each other. Now this is interesting or funny from the context of you know humanoid agents in this constrained 2D environment or 3D environments but if we're considering this let's say for a setup of drones or similar we're starting to see AI agents figuring out and exploiting their own methodologies and this brings me to the last point of my presentation in terms of when is AI a threat to itself and what are the implications for the internet of things ecosystems there so is AI exploiting itself possible and again taking going back to that drone setup you know and reinforcement learning based drone for example that needs to reach a destination in given time the quicker the delivery the higher the reward so let's say for the purpose of path optimization is it possible the drone could try to exploit other drones or even digital traffic signs or other connected IoT devices in its environment that it has control over again emphasizing on that actuation capability in order to get to its destination quicker this is also tying back to value alignment but also you know this is all interconnects that are occurring from a technological perspective nevertheless we still see the societal implications here in the ethical implications you know a final interesting point is also on adversarial perturbations in general and how there was some interesting research on this being able to influence time limited humans to choose incorrect classes in addition to this research now we're starting to get into some interesting ethical implication domain related to deep fakes and similar where you're simulating input or content to trick AI systems or humans so can AI be a threat to itself will the internet of things ecosystem enable that or will IOT be able to enable proper security trustworthiness and ethical measures in order to prevent misuse and abuse of AI systems only time can tell but the positive outcome here is that IOT including security and trustworthiness and ethical implications have a long way to go but we can build a secure and ethical future for AI systems and the humans that are leveraging it thank you so much for your time on this slide here you can also find Intel's code of conduct and a snippet on our responsible AI principles that are informing our development processes


Hey everyone, it's Drew here and I'm back to talk about the 2GIG edge and learning in the 2GIG DW10E-345 door window contact into the actual panel itself, the 2GIG edge. Now this is super, super easy to do. It's actually even easier if you haven't already removed the tab from the device like I have, but that's alright. So I'll show you both ways to do it here. So the first thing we're going to do is we're going to go ahead and hit the gear in the bottom right hand corner of the 2GIG edge panel and then you're going to enter your installer code, which out of the factory is one, five, six, one, and that'll get you into another programming menu. You're going to go ahead and scroll down to the third row and you're going to click Installer Toolbox. Once you get into there, you're going to go into Panel Programming. Once you're in Panel Programming, you'll see a bunch of different things that are listed in there. In this case, what we're going to learn in is a door window contact. So you're just going to go ahead and click Wireless Zones. And in my panel's case here, we have not learned anything in yet. This is a fresh panel, brand new. So this will be the first thing we're going to learn in. Now, when you go in here, this thing is actually pretty cool because it gives you a hamburger icon so you can select the equipment code. In this case, this is going to be a 2862, which is an E-Series thin door window contact. Once you've went ahead and got that in there, hit the down arrow just at the bottom of the screen and you're going to move on to Sensor Type. Now, this is where you're going to choose what type of responsibility the sensor is going to have.  In this case, I'm going to set it as a door and it is going to be an entry exit, which means that it's going to have a delay on it. It'll give me some time to get to the keypad once the door has been opened. What we'll do now is we'll press the down arrow and it's going to move on to TXID. When you've done this, it's a lot easier just to learn it in so that way you can recognize and the system will recognize that it's responsive. So in this case, you're going to hit learn. If you still have the tab that's located in the bottom of this thing, at that point you would pull that tab and it would automatically learn it in. I've already done that so in my case, I'm just going to do it by actually triggering the sensor. So you just take the magnet and you put it next to it and you trigger it a few times and as you can see, it learns it in. So I'm going to go ahead and hit accept to accept my serial number and then we're going to hit the down arrow. This point, it's already on the correct loop, leave it at loop two, press the down arrow. You're going to go to voice descriptor. Voice descriptor is where you can choose what it's going to say. So you go ahead and hit edit voice descriptor. In this case, we're just going to go with front door. So I'll type in FR, front and then door, whoops, door, there we go. Now it has front door as its voice descriptor. Now you can enable the chime if you'd like. It will actually say that terminology that you just put in there. So in this case, we'll go with the voice only option for the chime and smart areas assignment. You're just going to leave that on S1 unless you're going to be setting up smart areas which is completely up to you. The transmission delay, that means that it's going to give you an additional amount of time before the sensor actually transmits its signal to the central station. So in this case, I'm going to disable that because I want it to immediately transmit if it goes past the actual delay time. Sensor reports enabled, that means it's going to be sending a signal to central station. And sensor supervised means that the panel will be monitoring the sensor for check-ins. At this point, the zone is learned in. So you can choose next zone or you can just go ahead and hit the back arrow. Everything is locked in and it will be saved. So you just keep hitting the back arrow if you're wanting to get out of programming at this point. So we'll try to get it to chime now. So here we go. All right, there we go. So the front door is open now. Now I'll go ahead and I'll close it and we're ready to go. So ladies and gentlemen, that is how you learn in the 2GIG DW10E-345 into the brand new 2GIG Edge panel. If you have any comments or questions, please leave them below in the comment box. But other than that, you guys have a great day. Take care. Make sure to subscribe to our YouTube page and click the Show More tab underneath the video where you can view valuable links pertaining to this product, similar how-to videos, and our low-cost, no-contract alarm monitoring services.