I'm Ned Smith, and I work for Intel. As you can tell from the slide, I'm working in the Open Technology Center for Intel. And my background is in security. I've been spending most of my time working with the Open Connectivity Foundation defining the security model and the set of an object model for OCF there. And what I wanted to talk about today was gateways and some of the challenges that gateways present in the context of doing software update. If you are not familiar with OCF, they're defining an IoT framework. I'm going to go into more detail about what a framework is and so forth. So don't worry about that. But to get started here, I just wanted to introduce some sort of the big picture in terms of the software update process. Just so that we're all on the same page. And then I'll go into more detail in terms of how the IoT frameworks fit in the context of software update. So just to introduce some of the ideas here, in terms of this process, you can consider that many of the products that are delivered today in IoT and other spaces are essentially built from contributions from a variety of different suppliers. Those suppliers provide functionality that is fed usually to a vendor or an OEM who is responsible for that product. So presenting the entire solution to a user community. And in that context, they're going to provide some additional support in terms of building the product, testing it, and then producing a manifest or something that is signed for secure reasons, which then is put into some sort of a package given to some sort of software update distributor. In other words, some way for that update image to be communicated to the end device. Then there's the notion of an update installer. This is something that is going to be able to unpackage that image and present it to the target platforms. There may be multiple platforms that that installer is targeting. So in this context, there's manual update. There's over-the-air update. There is a variety of different ways to do update. I'm not trying to focus on any one particular way to do that, just really to talk about it more generally, so that we have some context for update process. Now as the topic alludes to, the idea here of this talk is to help understand, well, what are the complexities of software update in the context of a gateway? And so to better understand that, we need to understand what's the complexity of it, just doing an update in the first place. When we talk about a target platform, there's updates that can happen at various levels. Even at the lowest levels in the CPU level, there's microcode updates that typically have to go out. We don't often see that. Many vendors don't see that because it's sometimes taken care of by the BIOS or the OEMs who are providing firmware updates. And the microcode updates essentially get bundled in with the firmware updates. But then on top of that, there's system software updates. Those are sometimes there can be framework updates and application on top of those frameworks that also need to be updated. And the reality here is that there may not be one update mechanism that satisfies all of those needs for the different types of software update. So what you end up with is multiple kinds of containers for packaging up the update, multiple types of distributors, whether it's an app store model, or whether it's the update mechanism that's provided by the operating system vendor or the OEM. These tend to be different. And then of course, there's the installers. There's a variety of different technologies for installers. And if anybody's been following any of the update path for this conference, there's been a variety of different installer technology that's been discussed. And of course, at the very end are the devices that are the targets of the update. So the point here is that every single platform build is going to have a target that's potentially is going to have multiple update infrastructures that it has to address in order for that update to be applied properly. So another focus of this talk is around interoperability through standards. And there are several standards that are driving an IoT framework. So you may be familiar with some of these. There's the Open Connectivity Foundation. There's OMA. UPNP has been around for a while. But it still fits in this category of a IoT or IoT-like framework. All Seen Alliance is another one. One M2M is another one you may be familiar with. And there are others. This is just a few. There are a lot of these out there. And if we are trying to get to the nirvana of IoT interoperability, then we need to talk about translation gateways because all these protocols need to be translated, at least at the semantic layer. So we're going to talk a little bit more about that. But at the end of the day, translation is essential to interoperability. And there's really no way around that. So the focus of this talk primarily is at the IoT framework layer. There's all these other layers we could talk about and have been talked about in other parts of the conference. This talk is going to focus more on the IoT framework layer. And so this is above the operating system, below the application level. So I also want to point out this notion that there's a single image. Many of the constrained devices are built around the notion of just creating a single image. So in that scenario, there are still an IoT framework component that's embedded in that image. But the image itself has the need to go through this translation layer. And so that, I think, becomes an interesting aspect for update as well. I'll talk about it a little bit more. I'll talk about it more a little later. But the takeaway here is that the IoT framework layer is really rich in semantics. And so when we're doing translation, translation is all about gaining access to that semantic layer and doing a semantic mapping. And that has to be done in the clear. So there's really no opportunity for end-to-end security, for example. And so the translation gateway becomes a trusted third party or a trusted entity in the whole end-to-end security model. So let's take a closer look at the object model for interoperability for many of these IoT frameworks. Just to introduce the notion of an object model, if you're not familiar with the lightweight end-to-end model, they basically define this notion of clients and servers. And they communicate to one another through interfaces. The server has its own object model where they define these things called objects. And those objects have attributes. And then the interfaces define how to interact with those objects by the client. This is typically done over co-app. In the OCF model, Iotivity has sort of a similar but different approach to an object model. They also define clients and servers and interfaces for interaction. But they have the notion of resources. And then resources have properties. But otherwise, there's quite a few similarities between the two object models other than sort of this naming difference. There's also the all-join object model. There, they refer to consumers and producers. And they interact with one another through routers. They define interfaces that are essentially logically similar to objects or resources in the other models. And then they define methods, signals, and properties as the type of data that interfaces expose. The whole idea behind these frameworks is to get interoperability between the clients and the servers. So the idea is that there should be different vendors producing clients from those vendors that are producing servers. And if everybody adopts one object model or one IoT framework, then we have ubiquitous interoperability. But the reality is we have multiple of these frameworks. And so in order to get interoperability, we have to introduce the notion of translation. Translation happens at the semantic level or the information model level. And so we need something that performs that translation. And often that comes in the form of a gateway or a bridge or some other device that sits between these networks. All right, so here's another view of where the translation gateway fits. You can see there's a network A that is built around one IoT framework approach, a network B, which is built around another IoT framework approach. And then you have this notion of clients and servers within the network. And they're able to communicate with clients and servers in the opposing network through the gateway. And the gateway essentially introduces this notion of a virtual server or virtual client that connects to sort of its opposing virtual components. So a virtual client talks to a virtual server. A virtual server talks to a virtual client. And the translation happens in between while on the gateway. So at the end of the day, you can get an end to end interoperability solution where an application using a client on one network and network B is able to talk to a server in network A as if it was talking to one of its own devices. So the whole idea here is to provide this illusion that the clients and servers in network B are sort of magically populated in network A and vice versa. Now the interesting thing about what's introduced by this translation gateway is that from a vendor perspective, vendors not only have to update their device, which in this case is the server or the client, they also need to update the virtual component that's represented in the gateway. So there's really two targets of update when we're talking about translation gateways. And of course, if there's a second vendor for each one of these virtual devices, then there may be other vendors for other clients and servers and other networks also have to perform an update. So from the perspective here of the gateway provider, there's a dependency on the vendors from both network A and the vendors of network B are both depending on the gateway to provide this translation for hosting this translation of the virtual devices. Now there's another aspect I think about here in terms of update, and that is if the virtual device on one network is updated to provide say new functionality, then that might imply that the virtual device in the other network that's trying to talk to it might also need to be updated in order to take advantage of that new functionality as well. And so there may need to be some coordination between vendors A and vendors B in order to get their new functionality realized in this model. So the whole point here is to help illustrate that there's some additional complexity when we have to work through gateways. All right, so a gateway is not limited to a single network that can translate between multiple networks. And so when I say network, I'm referring to a network that's built around an IoT framework. So think OCF, All Seen Alliance, 1M to M, et cetera, et cetera. So for every IoT framework, there is potentially another target for the application in one network to talk to the server in the other network. So you can sort of think through some of the accommodatorics here. So let's talk about updates. So there could be vendors that are providing the application component, while other vendors are providing the framework component. And so each of those components need to be updated. There can be a large number of devices. So think different vendors of different types of devices, whether they're lights or thermostats or switches or pumps or whatever they are. They may all have different vendors. And so the gateway is essentially instantiating a virtual instance of every one of those kinds of devices. So think about the complexity of your IoT networks and how many devices there are. And then map that onto a gateway. There's potentially lots of virtual devices on a gateway. Now the other point here to note is the impact of update on the gateway becomes really important in terms of the latencies that are introduced through the update mechanism. Start counting up the numbers of things there that there's potential for all of the accommodatorics to add up. OK. So I think what this means is that gateways need to be designed for availability. That should be a primary design objective. If you sort of try to calculate what the mean time to failure is, essentially what you're saying is the rate of failure of devices in network A is going to be a function of the rate of failure in network B and network C. And if there's D, E, and F, whatever, all of those add to the MTBF of the entire system because this gateway is providing this fundamental translation function between all the networks. So the question here then is, what if an update requires a reboot of the gateway? It essentially means that the gateway becomes this central point of failure. And so the overall network, the combination of all these networks, becomes really the point of failure for the entire network. And that becomes a main concern from an availability perspective. So the question is, do updates require the server to reboot? Now, if you're familiar with any of the existing update mechanisms, they tend to rely on a reboot. So that could be a challenge. And it gets worse. So let's consider also the case where there may be different versions of the IoT framework. And the gateway may need to host multiple versions. So there may be in this example, there is version one of the blue class of framework. And then an update happens and introduces version two. And so now the translator has to be versioned. So we get a second version of the translator in order to map the different versions between the different IoT frameworks. And of course, if you add another network, then that also potentially updates the translator. So you have translator code that's sort of fundamental part of the gateway. That also needs to be updated. And so you add to our equation here that the availability of the gateway itself is now another dimension of our MTVF function. So you might say, well, hey, I can fix that problem by introducing new gateways. And certainly you can do that. But just keep in mind that for each one of those gateways, there's the complexity that the single gateway has. Now we multiply that complexity by three. And now we're really complicated in terms of update. So now as a device vendor, I have my physical device that I have to update. I also have to update the virtual device on all the gateways that are in deployment. And if the gateway is unreliable, and the solution to unreliability is that we introduce more gateways, now as a vendor I have to somehow make sure that my virtual device image gets properly updated on all of those instances of the gateway. So this seems like complexity that's difficult to manage. So what are some of the solutions? I think there are lots of potential solutions. But certainly solutions for the gateway where you can do some sort of dynamic update of the gateway such that it doesn't have to ever reboot is a great opportunity here. I know that in the academic community there's some discussion around dynamics offer update and some interesting tools and techniques that basically do stack modification and other things that essentially allow updates to happen in real time. So the kernel doesn't ever reboot. But this talk isn't about that. I think that's a whole other talk maybe for another day. But just to point that out, this really is what is going to be the kind of technology that we're going to need in order for these gateways to be successful. All right, so another aspect of update has to do with securing the updates and managing the keys that are associated with that update. So I'm going to kind of dive into that a little bit right now. So just to understand the terminology here, I'm using k to the minus 1 to represent an asymmetric private key. The k is essentially representing the public key, an asymmetric public key. And then square brackets denote signing. So when you look at kind of what we have here, the left-hand side of the screen is trying to represent essentially the existing solution in terms of how we manage security for update. And it's fairly simple in the sense that a vendor has a private key and he uses that private key to sign his update package. So there's some signature and whether it's in a package or whether it's streamed, it sort of doesn't matter. The point is he has his key that he uses to sign that package and then his key is also embedded in the device in some sort of secure storage so that when the package arrives, it can be validated. Now, this works because the vendor controls the manufacturer of the device and has access to the device during manufacturing and can embed his key in the device in some secure storage. There's a variety of different ways to do that and every vendor, many vendors have their own proprietary ways of embedding keys in hardware. Okay? On the left-hand side, we have the gateway and the point here is when the vendor is now trying to update the gateway, he has to produce an update package. Only this update package is a virtual image, not the device image. This is particularly appropriate for the scenario where you have a single image device, a constrained device that has a single image. You can't use that image to update the gateway because the gateway can only deal with the virtual sort of these virtual devices, okay? So there's something that sort of represents the device at the IoT framework object level and ignores everything underneath it, okay? Because it's not running on that constrained environment when it's on the gateway. So that's essentially a different image that needs to be signed and packaged and installed. Now, the installer has to essentially provide the verification key to the gateway in order for this verification to work. And what that implies is that somehow the installer is able to provision his public key into the secure storage of the gateway, but the gateway has to approve it. In other words, somehow the gateway's key has to sign the vendor's key in order for that trust relationship to be established properly. And so that's a separate, think of that as a separate installation step where the vendor not only has to install the package, he also has to install the key that verifies the package, okay? And so that gets into the next sort of question of how do we do that efficiently? Now, from a gateway vendor perspective, if you're happy to be a gateway vendor, the problem is essentially that you need to establish a trust relationship with every vendor, okay? So, and again, this is not just every vendor in your favorite IoT framework, it's every vendor for every IoT framework for which you intend to provide translation. So this potentially could be all devices, okay? So as a gateway vendor, you want to maximize your value, you want to be able to translate from all possible IoT frameworks, you're going to need to have trust relationships with all possible device vendors, okay? And keeping in mind that vendors change their keys and also vendors change, they come and go, they go out of business, there's a lot of dynamism in the whole vendor community. So as a gateway provider, you have to deal with all of that. Okay, so let's kind of review here what are some of the essential features or capabilities for some sort of scalable update mechanism that involves gateways. So first of all, automation, this should be obvious. There needs to be some sort of notification that an update is available. So you can imagine all the vendors are working feverishly to update their products. And so as a gateway provider, you want to know when those updates are available. There should be some sort of install package customization so that the image, you can tell the difference between an image that's targeting a physical device versus one that's targeting a virtual device. And there should be some mechanism for rollback that should be automated. So if for example, the installation fails, you can respond to it appropriately. I think in terms of the complexity for rollback when you're trying to coordinate excuse me, when you're trying to coordinate the installation of both the physical device and the virtual device, if one of those fails, then you got to roll back the other one, okay? And vice versa. That's an added level of complexity. We should be concerned about in terms of security, images need to be signed. It doesn't make sense from a gateway vendor's perspective to install a virtual device that potentially is going to introduce some kind of security malware into their gateway and bring it down. So they're going to require signed images. There needs to be a root of trust in the devices. This is, and so this applies both to physical devices but also to the virtual devices that has to be there. And then there's this notion of a trusted image repository. There needs to be someplace to store the images that the gateway needs to install. And again, the installers themselves need to be trusted. So whatever solution that the vendor is providing to the gateway to install the virtual devices, the gateway vendor needs to trust that. Testing and validation is also an important component. If you think about vendors typically test their devices, they're going to have the added responsibility of testing the virtual device as well and making sure that interoperability is the interoperability promise of working through a gateway that does translation is a supported capability. We also need to establish some open source technology for doing things like having common images. So bundles, packages, manifests, whatever that is, we really need to have, we need to reduce the number of choices that are out there so that we don't introduce unnecessary complexity just in the way that we create update images. And I know that's, everybody has an opinion which package and package manager that they like but every time we have a different one, that just adds some complexity that makes it more difficult to ensure that you've addressed all of the corner cases. And messaging at the framework layer is also another area where we could look at having open source technologies address the need here. In other words, when you look at many of the update mechanisms, they introduce their own framework layer for messaging. And so in the context of IoT frameworks, they're defining essentially messaging framework for achieving that connectivity. And so it doesn't seem to me, it doesn't make sense to have multiple different types of messaging frameworks, especially ones that are focused narrowly on, hey, here's how I'm gonna do over the air updates using this new type of messaging framework when the whole gold industry for interoperability is to standardize around a few IoT frameworks. And then another component here is essentially an image repository. And I'm gonna go into more detail about that in future slides, was there a question? Okay, if you have a question, just raise your hand. I'll call on you. Okay, all right, so suggestions for update scalability So I think a cloud, the assertion here is that a cloud repository is essential in order to scale the complexity. We need to find some way to reduce the apparent complexity from the perspective of the gateway and from the perspective of the vendors. So a great way to do that is introduce a cloud service and hide a lot of that complexity. So here's a suggestion for how we might do that. If we have a cloud repository that's built around the published subscribe model, essentially you can have the vendors be represented as publishers into the cloud. They publish their images and then the installers are the subscribers. They then consult the cloud when there's a new version of a vendor's virtual device or physical device is available. They then get notified through public subscribe and they can react then by installing the appropriate sort of updated image to the appropriate device, whether it's a physical device or a virtual device on a gateway. So you see here on this slide is just sort of an example is vendors one and three are publishing to version 1.1 of a particular framework and the installer one is the one that's installing and it's installing both the device A and device B and it's installing into both the virtual device as well as the physical device and they all happen to be sort of the blue flavor of the IoT framework. Vendor two on the other hand is building a device that can speak on all three different IoT frameworks and so it has a little bit tougher job and then it needs to provide, it needs to publish to each of those topics for each of the flavors and then the installer that needs to be able to install each of the flavors on both the virtual and the physical devices. So you get a sense for what this slide is trying to represent here. Now keep in mind this diagram doesn't deal with what happens if there's installation failure and how rollback works. That's added complexity that needs to be considered. All right, so now let's talk about key management of the cloud repository. So on the far left, you'll see essentially how things work today. This is sort of simplified version of how update works today. You have a vendor provides his updates to some sort of repository that then gets applied to the device and the device has this public key for which it is able to verify the update. Now some vendors go out of business and that leaves their devices that are out in deployment and someone really have to update them. Some of the ways that they deal with that is they license their updates to another outsourcer and so they essentially delegate through key signing, they delegate to the outsourcer. And so essentially what that means is the outsourcer key is signed by the vendor key and then the updates are provided by the outsourcer but can be signed by the vendor key. So essentially the device doesn't have to change in terms of its trust anchor. It can still verify the outsourcer's provided update. So it's an accommodation but as an accommodation it really doesn't scale much better than the current model where vendors provide their own private keys and embed their trust anchors in their own devices. So in terms of a cloud update model essentially what we're suggesting is that the cloud repository provider has its key and that certainly the gateway device will embed the cloud repository public key as a trust anchor in its secure storage and when the updates are provided to the cloud repository they are signed by the cloud and so the cloud then becomes a trusted entity in delivering those updates. But what this does is it really simplifies this notion of root of trust. So every device has this one repository trust anchor then there's some simplification that happens there. So let's take a look at key management scalability. There's actually a couple of approaches that we can look at. There's the PKI approach which many of you may be familiar with. The idea of PKI is there's a hierarchy of CAs and that there's a root CA that everybody sort of knows and trusts and you basically embed the root CA key on the device and then you build a certificate chain and at the very bottom layer of that certificate chain this is the vendor CA if you will. He's going to create a key that is his signing key for his update and then the vendor's update key which is highlighted in purple here. That's signed by the vendor's CA which is this lower layer. There may be multiple intermediate CAs but then you get to the sort of the first level and the root level CA. So this is just a bunch of signatures over keys until you get to the key that signs the update. That's typically how PKI works. Some things to note here. The verification essentially requires all keys so there could be four or more verify operations. For each update the root CA has to be trusted by everybody. This is interesting because it means that there is some outside entity that's providing a key that a vendor is putting into their device and they have no control over that vendor. They have no control over this CA provider. So if something went wrong, say their keys got compromised or whatever they're taking risk, they're sharing risk of their product line with this other vendor. So from a business risk perspective you have to think about whether or not that CA provider is putting as much investment in protecting those keys as you're putting into your investment in your product line and in your product, okay? So if we compare that with the cloud repository approach essentially the cloud repository has an update that's signed by the vendor. The vendor, the cloud then countersigns the update with the cloud repository key. So you see this again highlighted in purple, the counter signing of the cloud key of the update that's also signed by the vendor. What this means is when you install, the verifier could just verify with one key. Either they verify with the cloud repository key or they verify with their own vendor key. Either one can work and you only need to do one. There's only one verify as needed. You just have to pick which key is appropriate. And many vendors are going to include their vendor key anyway because the other types of updates for example, firmware updates or kernel updates may be something that they use a different update infrastructure for which they control so their vendor key is gonna be there anyway. So the expectation here is that each vendor is going to establish some trust in the cloud repository. So it's similar in that sense with the PKI approach but it's the cloud repository as an entity that's focusing on sort of being a meaningful participant in updates. And so the business conditions may suggest that the cloud repository provider is going to make the appropriate investment, okay? And of course the question is, do we really need to be the PKI root key in this scenario? And that's an open question, I don't know. So let's take a look at, do these IoT framework repositories exist today? This isn't a complete list but there's a couple of them that are interesting. There's one called OpenTDT. So this is, I think this is, the T is for translator to things. And the idea here is that from OpenTDT perspective, there are these schemas that are created by industry providers. So vendors of devices will create virtual devices that are built around the schema and then they'll contribute that schema to the OpenTDT repository. And it's mostly driven by standards organizations. So I think of things like OCF, All Seen Alliance and so forth, they're providing, they're essentially defining these schemas that are contributed to the OpenTDT repository. Developers can create their own translators and schemas as well, that's okay too. Translators can run on devices, cloud connected things, gateways, they sort of run on anything. Assuming, given that you have the IoT framework component underneath them. Okay, another interesting one is the Oscar Bundle repository. This is essentially bundles of OSGI objects. The OSGI, it's sort of an OSGI defined manifest that goes with that. It offers programmatic access to a web repository. However, developers can submit bundles to the repository but there's no sort of automated way to do that. It's all sort of manually put together. So there's still work to be done to make it automated. But this seems to be the type of choices that are available today. One of the challenges with OpenTDT is that schemas need to be standardized. So maybe there isn't the promise of vendor differentiation maybe more difficult to get to. In the case of OSGI, essentially it sort of lacks this developer automation that's needed to make it scale. Okay, so the other sort of mean from the perspective of security, there's still a bit of key management that's ignored by any of them. All right, so let's talk conclusions. Essentially reliance on IoT frameworks implies the need for translation. This sort of seems to be where the industry is going and given that gateway architectures need to add some sort of support for dealing with the complexities of that update brings and put update automation. It's needed to ensure scalability. There are a lot of challenges that are facing us in terms of achieving that scalability. But certainly one of the ways that hardware vendors can help out is to provide some support for embedding of trust anchors and keys and protecting those keys. It seems to be one of the fundamental components to all of this. So with that, open to questions or comments others may have. Yes. Yeah. It's a great observation. And I'm not trying to advocate one sort of business model over another. But certainly there is the possibility that vendors can go out of business and they don't support their products any longer. And the question to the industry is what do we do about that? One possible solution is that presents a business opportunity for somebody to go and support them. But in the absence of that, then what is the industry?  From a gateway vendor perspective, it's sort of one of the options for the gateway vendors to say, oh, well, I can't support this translation device any longer because the vendor's not supporting it. That creates essentially maybe a useful control point for preventing that device from creating a problem because they can just remove the virtual device from their gateway and now that connectivity is not allowed, sort of a way of turning off the physical device. But ideally, that's not the best answer. Ideally, there's some way for those devices to be updated by somebody who wants to pick up support for it. Other questions? Thoughts? This talk was intended to get you thinking. It's not trying to provide an absolute solution, but really it's something that as an industry we have to be aware of and try and work through it and figure out what's the best way to address this. I think we're making great progress with over-the-air updates and so forth, but everything I've seen so far at this conference in terms of updates is focusing on update just the physical device and there should be some thought given to updating the virtual devices and working with gateways and helping them scale. Okay? Comments, questions? If not, thank you very much.


Bismillahir Rahmanir Raheem, and alhamdulillahir Rahmanir Raheem. Allahumma salli ala sayyid, Muhammad ba'ala wa sallam. Welcome to this latest update on MCC construction. We did an update about a month and a half ago, and we're right now in the last 10 days of Ramadan, the Ramadan Qareem, and all of you have a very blessed last 10 days. We're going to give you a detailed update on construction. When I say we, I say you and myself, I'll cover a little bit of the higher level and then say I will go into some of the details of the construction plan and how we plan to get from here to there. So before we start, we should show you our vision statement. This hasn't really changed since, I would say, going back to 2007. So I'm not going to go through the details. The reason I put this up, this is a good way to think about the language we use is sort of the dot on the wall. That is to say, what are we at MCC trying to aim for? So that's our vision. I actually want to go a little more detail on our strategic priorities. Again, most of these have not changed, but there are a handful that have sort of come and risen to the top. And a good way of thinking about this is post COVID. We've seen just a great amount of growth here at MCC itself and also the environment in which we all live has changed. And specifically, I mean, the entire, as an example, the entire gender thing that's caused many, many of us to want to have more control over education. So here are our strategic priorities. I won't go through all of them. I actually want to just highlight the ones on the left-hand side that have to do with, if you see the first one, it's K through 5. We've actually, K through 5 has been on our list since we put our bylaws together, going back where we first founded MCC. But what you'll see there is because of the growth, another priority we've raised is not just having Sunday School but also having a Saturday School. As we go through our presentation today, we'll give you a sense of how we're going to approach that. And then the last one here to talk about as new is a really, really important one, and it came to focus last year and last summer when we were trying to get the land purchased. So we decided not to, but we realized the critical need of really, really having a middle school and a high school available for our community. So, inshallah, that is now on our list of priorities. We don't have a date yet. Obviously, we're going to start looking at what the requirements are, look at what properties are available, and start that process. But it will take a long time. With that, let me kick off our MCC, what we're calling MCC 3.0. If you think about 3.0, 1.0 had to do with, when we just founded MCC, 2.0 had to do with being in this building. And 3.0 has to do with what we're going to be doing and specifically accelerating our growth. And we've been in hyper incremental mode, and what we need to do is move forward to go into a hyper growth mode so that we can have this facility completely redone for future needs. So with that, in the past year or two, we've been talking about our construction plans. So we have now more detail. And before I go into this, I think it is fair to say, particularly when you talk about, by the way, we've broken this down into package 1, 2, and 3, and say that we'll talk about the specific reasons why these are called package 1, 2, and 3 in a bit. But package 1 has to do with everything we want to do on the outside. And that, as we've told you, I think for two years now, has been a picnic area, a trellis, barbecue, a basketball court, a parkour outside with the stations, children's play structure, a play field, and then the parking lot gets re-changed and we have some EV stations coming. Package 2, which will be after package 1, these are sequential, will be everything we're doing in the building inside. Now, the really, really important thing about this that we haven't really emphasized is we're actually going to build a second story. And the second story will be a little bit about where the ladies' area begins and all the way back from there. The second story is adding 1,400,000 square feet and it allows us to have both a Saturday at Sunday School and also administrative offices up there and so forth. With that, you free up the place downstairs. You get additional conference rooms. We have space for both male and female lounges, along with a sort of gym incorporated, a parent-child room with a specific area for kids to play in, a library, senior lounge, and the main prayer area gets redone, sitting gets raised, a member sort of gets put in place. And then last but not least is Package 3, which has everything to do with food. The dining, the dining if you will, so that specifically means a dining hall and it means a cafe, both a covered aspect, un-covered aspect, and then a patio. So those are the packages. And before I ask that you have had to get up and talk about how we actually construct these, I do want to say it's taken us much longer than we expected. Our expectations and the expectations we set for you were that by the end of last year we would have this done. So my apologies on behalf of everybody here at MCC and something myself. We should have done a better job communicating. There's all the steps we need to go through to get there. Having said that, I feel really good where we are today and Brother Sayyid is going to get up and give us the process from here going forward. Assalamu alaikum wa rahmatullah. Thank you Brother Parvez for the brief introduction to the slides. I'm going to walk you through the rest of the process for construction and where we are today. The slide that you see, that's on the screen, the package one, package two, and package three. The construction project itself is pretty large, to say the least, and we decided to break it up into packages as you see one, two, and three. Part of the reason, I should say maybe most of the reason was to have these packages in such form so we are able to get the approvals through the Hacienda Association as well as the city in a normal and a sequential manner such that one package does not hold back any of the other packages. If there is a problem of one package being delayed, this allows us to move forward with the other packages being worked on in parallel. What you see on the left-hand side on the slide, the CUP modification. By the way, CUP stands for Conditional Use Permit, which is granted by the city, and we operate MCC under Conditional Use Permit. Some of the changes that we are doing today may require a CUP modification, which we are very, I should say, working hard to avoid because that just adds delay to the whole process. You have to go back to the city. It may require public hearings and all that, and of course the delay associated with all the added requirements. As you can see, package one has, we are not required to have the CUP modification. And owner's association has approved package one, and we are in the second round of our approvals with the city. In other two weeks, we are expecting a response on our second round. As you can see, we have taken the liberty to start some construction for this package, and mostly we have done the stuff which does not require any city approvals or inspections, like the cleanup and putting in some pavers, opening up some additional doors in the lobby that you see recently. Package two, CEP not required, association approval in hand, and we are planning to apply for this approval with the city, the week of April 8th. And again, we have not started the construction on this yet because all this work requires city inspections, and we cannot start without a permit in hand. Package three, we have not heard back from the city yet as to a CUP modification is required or not, but we do have a verbal approval from the association. We are hoping to apply with the city the week of April 15th, and again, the construction on this has not started. A conversation I had with our structural engineer who works out of his home office in Idaho, he was here on a visit to the site to come up with the design, he wanted to look at the actual building before he dived into the design for the second story addition. He asked, he wanted to add some rooms to his home, to his farm in Idaho, he went to the county and asked for permission, and the county said, you know, it's your home, you can do whatever you want to do with it. I hope we wish we were in that situation, but we do have codes and rules and regulations to follow, and they are there for a good reason, I'm sure, and so here we are, we don't have that luxury to be able to do that. Anyway, so that's where we are today. As you can also see, we have put some numbers for the approximate costs. Each package, the package one is around 500K, and this is most of the stuff outside. We are hoping and we are trying to get this done by the fall of this year. Since we are in round two with the city approvals and we have also started to do some construction. The package two is we are hoping to start this fall, hoping to have all the approvals in hand be able to start, and this is the large ticket item, it's 1.6 million plus, and then of course the same goes for package three, which we have not started yet. These are just visuals of rendering, visual renderings of what the MCC would look like after we add the second floor. It's also a requirement by the city and the association that we produce these renderings so they can have a visual sense of what the building is going to look like. With that, I'd like to hand it back over to Brother Parvez to continue with the rest of the presentation. Thank you very much. Say goodbye, thank you so much. We're going to move on to financials, and I want to step back and talk about what we've raised, how much we've raised and how much we've spent. First of all, not just now, but if you look back the last five years, this is beginning with COVID, actually the year before COVID, 2019 through now, we've raised about $900,000 plus, and on the right hand side of this slide, you can see where that money has been spent. A lot of that money actually has been spent in the last year, and if you look at the top line, the roof changes we made, because it was leaking before, the HVAC that we put in, the parking lot changes, fire alarm, etc., the consulting, the maintenance, that by itself, the stuff you don't see is about almost 50%, because part of the thing is in the lobby also that you don't see, which has to do with the HVAC ducting that we've done, the electrical, the metal cheating, etc. If you add all that up, more than 50% is stuff you don't see, and then there's all the stuff that you see at the bottom here on the right hand side. Now if this is how much was spent, the question then is how much have you raised and how much you have to do what you say you're going to do? So construction funds available, if you look at the bottom chart here, this is donations by year, and if you notice last year, 2023, we really did not ask for money for building, and we did not for the construction fund, and we did not because frankly we had raised some money, and we didn't deliver to what we thought we were going to deliver to. So in the past five years we've raised about $800,000. You may ask how do we spend $900,000 if we only raised $800,000, and that has really to do with two things, how much do we have money beforehand, and then also some of the rental income we get also goes to fund mostly the building fund and sometimes also the operations fund. So do we feel better? I think the question is we're behind, why do you think you can actually get this done inshallah by fall or by the end of this year? I've talked about package one which is all the outside stuff. There are three things that are really required to get this done. One is you've got to know exactly what you have to get done. Two is you've got to have people who actually can get the work done. Three you need permits, and four you need the dollars. Three are those four we have. The permit process is well along for the outside, and inshallah, inshallah, please make the offer this, that in this next round with the city they approve the outside, and then we have, here's the important point, we have $550,000 available, and we think we may need about $500, we have $550,000 available to get the first, to get phase one, package one done. And remember package one is all the stuff we talked about outside, and particularly the basketball court which I think there's a lot of demand for the youth. Now stepping back, what Saidvai just said is well that's package one, we still have quite a lot to do in package two, and package three. For package two we're going to need plus or minus $1.6 to $1.7 million. And what we don't want to do is get through package one, have no money, and wait to raise money, and raise a bit of money, and then say we're going to start package two. So our objective is, inshallah, to raise and have at least $200,000 now, and before we start, and then in the fall we'll do another major fundraiser. Our objective is since we are in Ramadan, we'd like to ask you, alhamdulillah, since we're going to be raising money later this year, please give some money now. It will make us feel a lot more comfortable that we have money at hand before we start the next phase. That's all for our quick update here. Inshallah, you'll see some progress this fall. I have everything here done outside, and we can start then working towards package two and package three. The laws of course are all requested, and I want to thank Saidvai, and the entire team, Saidvai does this pro bono, completely pro bono, and has been doing incredible work with him and his team, and that's the people who do the construction work and a whole bunch of volunteers as you know, the MCC, we're very, very thankful. We're also thankful to you for your patience and your trust in us, and inshallah we'll make this a fantastic place for our youth, and inshallah for our seniors also, and for everybody. Jazakumullah.


Hi, my name is Simon Walter and I'm a junior art history major at the University of Vermont and this past semester I completed an archiving internship at CCTV especially during the pandemic when remaining isolated from other people and staying away from other people is a necessity. I felt like this internship helped me stay grounded and stay connected to the culture and the history of the Brownington area and Vermont in general. And it felt really good to be able to make that history and that culture more accessible for more people. I feel like the archives at CCTV are such a great resource for anyone who's interested in the culture, the history, or the political landscape of especially the Brownington area, but just Vermont as a whole.  They're only a portion of what CCTV does and I feel like everything that they do is such a great thing to support free speech and that it makes local politics accessible to people. You know, it makes these events like town meetings and press conferences and this and that really accessible to people that are all in one place. They don't have to seek it out on their own and it helps open up those channels of communication between the general public and policy makers. And you know, so that supports people's right to advocate for themselves and for their interests. So I would I would definitely recommend this internship experience, you know, either in the archives or you know, in production or in any other aspect of what CCTV does to anyone who has, you know, an interest in either in specifically in the history and culture of this area or just in politics in general and in media. I feel like it's a great experience and CCTV as a whole is just such a great resource for this community.


Mr. President, Ambassadors, Secretary-General, NDB President, Rousseff, distinguished diplomats, ladies and gentlemen. Today's meeting takes place at a time of several major wars. In my testimony, I will refer to four. The Ukraine War, which started in 2014 with the violent overthrow of Ukraine's President, Victor Yanukovych. The Israel-Palestine War, which has flared repeatedly since 1967. The Syrian War, which began in 2011. And the Sahel Wars, which began in 2012 in Mali and have now spread throughout the Sahel. These wars may seem intractable, but they are not. Indeed, I would suggest that all four wars could be ended quickly by agreement within the UN Security Council. One reason is that major wars must be fed from the outside, both with external finances and armaments. The UN Security Council could agree to choke off these awful wars by withholding external finance and armaments. This would require an agreement among the major powers. The other reason why these wars can end quickly is that they result from economic and political factors that can be addressed through diplomacy rather than through war. By addressing the underlying political and economic factors, the Security Council can establish conditions for peace and sustainable development. Let me consider each of the four wars in turn briefly. The war in Ukraine has two main political causes. The first is the attempt by NATO to expand to Ukraine despite the timely and repeated objections by Russia. Russia considers NATO presence in Ukraine as a significant threat to Russia's security. The second political cause is the East-West ethnic division in Ukraine, partly along linguistic and partly along religious lines. Following the overthrow of President Yanukovych in 2014, ethnic Russian regions broke away from the post-Ku government and appealed for protection and autonomy. The Minsk-2 agreement, endorsed by this Council in Resolution 2202, called for regional autonomy to be incorporated in Ukraine's constitution, but the agreement was never implemented by Ukraine despite the UN Security Council backing. The economic cause of the war results from the fact that Ukraine's economy faces both West to the European Union and East to Russia, Central Asia and East Asia. When the EU tried to negotiate a free trade agreement with Ukraine, Russia expressed alarm that its own trade and investments in Ukraine would be undermined unless a three-way agreement was reached among the EU, Russia and Ukraine to ensure that Ukrainian-Russian trade and investment would be sustained alongside EU-Ukrainian trade. This is a well-known event in trade negotiations. Unfortunately, the EU was apparently not prepared to negotiate with Russia over such a three-way arrangement, and the competing East-West orientation of Ukraine's economy was never resolved. This Council could end the Ukraine war quickly by addressing its underlying political and economic causes. On the political front, the P-5 countries should agree to extend a security guarantee to Ukraine while also agreeing that NATO will not expand to Ukraine, thereby addressing Russia's concerns over NATO enlargement. The Council should also work to achieve a lasting governance solution regarding Ukraine's ethnic divisions. On the economic side, there are two considerations, one in policy and the other in finance. On policy, Ukraine's strong economic interest is to join the European Union while also maintaining open trade and financial relations with Russia and the rest of Eurasia. Ukraine's trade policy should be inclusive rather than diversionary, allowing Ukraine to serve as a vibrant economic bridge across the East and West of Eurasia. On the financing side, Ukraine will need funding for reconstruction and for new physical infrastructure such as fast rail, renewable energy, 5G, and port modernization. As I described below, I recommend that the Security Council establish a new peace and development fund to help mobilize the financing to help Ukraine and other war zones to turn away from war towards recovery and long-term sustainable development. Consider in a similar way the war in Israel and Palestine. Here, too, the war could be ended quickly by the Council enforcing the many UN Security Council resolutions made over several decades, calling for a return to the 1967 borders, an end of Israel's settlement activities in the occupied territories, and the two-state solution, including in UN Security Council's resolutions 242, 338, 1397, 1515, and 2334. It is clear that Israel and Palestine are unable to reach agreements in line with these UN Security Council resolutions on both sides hardliners repeatedly frustrate moderates who seek peace based on the two-state solution. It is high time, therefore, in my view, for the UN Security Council to enforce its decisions by implementing a just and lasting solution that is in the interests of both Israel and Palestine, rather than allowing hardliners on both sides to ignore the mandate of this Council and thereby to threaten global peace. My recommendation to this Council is that it immediately recognize the State of Palestine in a matter of days or weeks and welcome Palestine as a full member of the United Nations, with the capital in East Jerusalem and with sovereign control over the Islamic holy sites. The Council should establish a peacekeeping force drawn heavily from the neighboring Arab countries to help provide security in Palestine. Such an outcome is in the overwhelming will of the international community and the manifest interest of both Israel and Palestine, despite the vociferous objections by hardline rejectionists on both sides of the divide. An economic strategy should accompany the political strategy. Most importantly, the new sovereign State of Palestine must be economically viable, and I give several examples of how that can be done. But most importantly, both Israel and Palestine should become part of an integrated sustainable development plan for the Eastern Mediterranean and Middle East that supports climate resilience and the region's transition to green energy. The Council could similarly end the war in Syria. The Syrian war broke out in 2011 when several regional powers and the United States joined forces to topple the government of Syrian President Bashar al-Assad. This deeply misguided regime change operation failed, but it triggered a prolonged war with enormous bloodshed and destruction, including of ancient cultural heritage sites. The Council should make clear that all P5 countries and the countries in Syria's neighborhood are in full agreement that all regime change attempts are now permanently ended and that the UN Security Council intends to work closely with the Syrian government on reconstruction and development. On the economic side, Syria's best hope is to become closely integrated into the Eastern Mediterranean and Middle East region, especially through the construction of physical infrastructure connecting Syria with Turkey, the Middle East, and the Mediterranean nations. The war in the Sahel has similar roots. Just as the regional powers in the U.S. aimed to overthrow the regime of Bashar al-Assad in 2011, the NATO powers similarly aimed to overthrow the regime of Muammar Qaddafi. In pursuing this aim, they grossly exceeded the mandate of UN Security Council Resolution 1973, which had authorized the protection of Libya's civilian population, but certainly not authorized a NATO-led regime change. The violent overthrow of the Libyan government quickly spilled over to the impoverished countries of the Sahel. Poverty alone made these Sahelian countries highly vulnerable to the influx of armaments and militias. The result has been ongoing violence and multiple coups, gravely undermining the possibility of economic improvement. The countries of the Sahel form a natural aggregation for regional economic investment in infrastructure. The entire region urgently needs investments in electrification, digital access, water and sanitation, and road and rail transport, as well as in social services, notably education and healthcare. As the Sahel is among the poorest regions of the world, if not the poorest, the governments are utterly unable to finance the needed investments. Here too, and perhaps more than in any other region, the Sahel needs external funding to make the transition from war to peace and from extreme poverty to sustainable development. All P5 members, and indeed the whole world, have suffered adverse consequences from the continuation of these wars. All countries are paying a price in terms of financial burdens, economic instability, risks of terrorism, and risks of wider war. The Security Council is in a position to take decisive actions to end the wars precisely because it is clear that the interests of all UN Security Council members and notably all of the P5 countries is to bring these long-standing wars to an end before they escalate into even more dangerous conflicts. The Security Council is vested with considerable powers by the UN Charter when it has the resolve of its members. It can introduce peacekeepers and even armies if necessary. It can impose economic sanctions on countries that do not comply with UN Security Council resolutions. It can provide security guarantees to nations. It can make referrals to the International Criminal Court to stop war crimes. In short, the Council is certainly able to enforce its resolutions if it chooses to do so. For the sake of global peace, let the Council now choose to end these wars. The UN Security Council can also bolster its toolkit by engaging in economic peacebuilding alongside the more usual decisions on borders, peacekeepers, sanctions, and the like. I've mentioned already several times the idea of creating a new peace and development fund that the UN Security Council could deploy to create positive dynamics for sustainable development and to work with other investors such as the World Bank, the IMF, the Regional Development Bank, such as the NDP, and others to co-invest in peacemaking. I would recommend three guideposts for such a fund. First, it would be funded by the major powers by transferring a part of their military outlays to global peacemaking. The U.S., for example, now spends roughly $1 trillion per year on the military. While China, Russia, India, and Saudi Arabia are the next biggest spenders, with combined military spending roughly half of the U.S. Suppose that these countries reduce military outlays by just 10% and redirect the savings to the peace and development fund. That alone would free up around $160 billion per year. Second, the fund would emphasize regional integration. This is paramount for peacemaking as well as for successful development. The Ukraine would be helped to integrate both West and East. Israel, Palestine, and Syria would all be helped to integrate in a network of the Eastern Mediterranean and Middle East. The Sahel countries would be helped to break their isolation and lack of services through a network of infrastructure. Third, the Peace and Development Fund would partner with other funding streams such as China's Belt and Road Initiative, the United Nations Global Gateway, the G7's Global Partnership for Infrastructure and Investment, and increased lending by the Bretton Woods institutions and the regional development banks as the Secretary General has called for in the SDG stimulus. Interestingly, the Fund for Peace and Development could be a vehicle for greater investment partnerships that links China, the EU, the United States, and the G7. These two would be a contribution towards peace, not only into ending today's wars, but into increasing cooperation among the world's major powers. Directly across the street from us is Isaiah's Wall, with the visionary words of the great Jewish prophet of the 8th century BCE. They shall beat their swords into plowshares and their spears into pruning hooks. Nations shall not lift up sword against nation. Neither shall they learn war anymore. It is time to honor Isaiah's words by ending these useless and destructive wars, slashing military outlays and turning the savings into new investments in education, healthcare, renewable energy, and social protection. As an American, I am proud that our greatest president, Franklin Delano Roosevelt, was the visionary who oversaw the establishment of this great institution. I firmly believe in the capacity of the United Nations and of this Security Council to keep the peace and to promote sustainable development. When all 193 UN member states or 194 with the membership of Palestine live up to the UN Charter, we will have a new global age of peace and sustainable development. Thank you.