 So we're clearly in the 3.1 timeframe now, so just to be clear, don't expect this in 3.0, the services profile. This actually came out of OpenChain. There was a question on one of the seminars in OpenChain about, okay, I want to capture security information about a service. I want to know if the certificate authority that's being used is valid. And out of that question came, okay, well, that doesn't fit in software exactly, but it is a service. And maybe we should be capturing information in SPDX, not just about the software, not just about the hardware, but about the services as well. So we started this group about four or five months ago in terms of the profile itself. We, the group we meet about every other week. There's a small group of us. And by the way, if you're interested, you are more than welcome to join. By the way, I should mention any of our meetings for SPDX, if you go to github.com slash SPDX slash meetings, in that meetings repository, you'll see all of our meetings when we meet what the, you know, the coordinates are, you know, so feel free to join. You can also look at all the meetings and catch up on that same repo. One thing we decided very early on is we wanted to keep in sync with what's going on in CISA. They actually have an active working group in SBOMs. We have one of the leads from one of the CISA working groups on SBOM in the SPDX group. So we keep in very tight sync between those two different groups. And we want to, of course, be compatible with existing SBOM formats, especially SPDX. We are focused a bit on security based on where we came from. And we are in the process of working on use cases. So similar to the hardware group, we're in the requirements gathering phase. And I'll just give you a little bit of an update of where we are in the requirements gathering. We've actually categorized the requirements into three different groups or categories. The customer data governance to ensure that the customer data, the customer of the service provider that is, is adequately secured, supplier infrastructure governance, making sure that, you know, the reliability, quality, you know, the SLAs of that service is reflected. And then regulatory compliance. There's a lot of regulatory compliance about boundaries, about privacy that affects services. And those also need to be captured within the services profile. So we decided that we're going to focus on information that is intended to be shared across organization boundaries. So if you are using a service and it's just within, you know, that organization, the services, we're not focusing on that today. Maybe in 3.2 we'll pick those up. But if it is, if you're sharing information across different organizations, that's what we'll be focusing on. We have, I have a link to the use case documents in the slides that you'll be able to click on. For the, you can look at the details of the use cases that are there. I'm guessing maybe in one to two months, we'll probably, we're almost to the point where we're going to vote on the use cases aside, which ones we're actually going to implement in 3.1. Then we're going to get down to the challenging work of defining the actual fields, properties, classes, models, and actually get this work done. So we can get it out there in 3.1. So that's the services profile. And the next up is Shane.