Add Example Control Set profile and update README.md to explain contributing

[gregelin]

Committer Notes

{Please provide a brief description of what this PR accomplishes. Be sure to reference any issues addressed. If the PR is a work-in-progress submitted for early review, please include [WIP] at the beginning of the title or mark the PR as DRAFT.}

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you squashed any non-relevant commits and commit messages? [instructions]
• Do all automated CI/CD checks pass?

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you included examples of how to use your new feature(s)?

[aj-stein-nist]

Thanks for your time this morning. So far looking good, let's address this next time we meet same time next week.

[iMichaela]

@aj-stein-nist and @gregelin - I suggest not using the [email protected] as the mailing list might end up being abused. I suggest using [email protected] since snap protection exists and it is better implemented.

[aj-stein-nist]

@aj-stein-nist and @gregelin - I suggest not using the [email protected] as the mailing list might end up being abused. I suggest using [email protected] since snap protection exists and it is better implemented.

That's fine by me but that will put the onus on the three members on that distribution list (I am not a member) to answering and handling inquiries. The intent of the resource would be for the larger community to contribute and own it separate of the illustrious three. Also, I thought the mailing list now had moderator approvals?

Since we have a contact page, and I forgot in any absent-minded with the schema, we can even drop the email-address altogether and stick with a link to our contacts page.

[aj-stein-nist]

I circled around with Greg today and we will move forward with profile resolution and other work in our next sync meeting.

[aj-stein-nist]

OK, so you intend to take ownership of this in the repo and its managament? Last we had discussed this, I thought that was the reason we kept it pointed at "the OSCAL community" and the web address of this git repo on GitHub, respectively.

I am not sure if @david-waltermire-nist has any impressions/concerns with it, but this seems to be flip in intent from our previous chat. Will we talk next week about this?

[gregelin]

I'm comfortable with ownership identified with NIST or with GovReady. Changing the content was an opportunity to work with the data and the format and see how it looked.

Changing the content made me think about the UUID for GovReady and raised several questions:

• Can GovReady PBC have more than one UUID? What someone in my org creates a different UUID?
• Is the UUID I just a local convenience reference, or am I now responsible for always using the UUID?
• Can other people use that UUID when referring to GovReady PBC? On one hand I want others to use, but not to use GovReady PBC's UUID falsely.
• How would I publish GovReady's reference information of UUID and address information for others to find (e.g., directory services)? What if I update my address -- does my UUID change?
• etc., etc., etc...

[aj-stein-nist]

@gregelin, thanks for your time today. I will want to circle back with Dave on the organizational mechanics of how we handle you owning this with the contact info of the metadata block. Stay tuned, I will update when he returns from leave.

Re your questions below, I realized I had not addressed these during the call. I will answer some of them. When I say "must" the OSCAL information and data models require it, "can" or "could" means we don't restrict it in the models and it is up to you and other developers/community users how they would do it.

• Can GovReady PBC have more than one UUID? What someone in my org creates a different UUID?

You can have multiple UUIDs. The OSCAL specs do not say one organization must have a UUID in all interactions. An OSCAL-enabled tool could choose to flag that as an error and ask to unify them, or use both. You can see in our examples we give UUIDs to organizations that are actually different units of agencies or specific units of a component bureau (NIST is a part of the Department of Commerce). This flexiblity means you could have multiple UUIDs and tools can decide how they make people and their orgs manage one or more of them.

• Is the UUID I just a local convenience reference, or am I now responsible for always using the UUID?

As you put it with the two options, a a local convenience reference.

• Can other people use that UUID when referring to GovReady PBC? On one hand I want others to use, but not to use GovReady PBC's UUID falsely.

Anyone could use the UUID but OSCAL does not specify how an OSCAL-enabled tool must handle that concern as it is really up to how human users interpret it. I understand your point, but different orgs must refer to one another, and UUIDs are to avoid conflicts and allow faster indexing/lookup than inconsistent, free-form names. UUIDs in OSCAL are like the very prevalent use of UUIDs in the Microsoft Windows Installer ecosystem (they call them GUIDs, but it is the same thing). No one centrally manages or communicates GUID for a Microsoft Office or Slack or Adobe Photoshop GUIDs across the ecosystem or often even for their own company.

• How would I publish GovReady's reference information of UUID and address information for others to find (e.g., directory services)? What if I update my address -- does my UUID change?

OSCAL does not say you must change the UUID. You could change the UUID in an OSCAL document with an OSCAL-enabled tool based on how significant a change you make to the subject attached to the UUID. Maybe for the author of a SSP or their SSP authoring tool, the address of the org does not have a significant impact. What about the address of a data-center where the system described in the SSP is operated and maintained? (Personally, and this is just my opinion and does not confer any strong guidance recommendation from the NIST OSCAL Team: I'd not change the UUID for the former and would for the latter since that is a meaningful change; the former it's the same legel entity and the SSP authoring software and its development org, as a subject, is not meaningfully changed by a HQ address change.)

• etc., etc., etc...

Let me know if there are/were additional details or nuances I didn't cover in the above answers, or if you have new questions. Hope this helps!

[GaryGapinski]

https://pages.nist.gov/OSCAL/concepts/layer/overview/ levies a requirement that the root element UUID of an OSCAL document must change when the document is changed. The requirement has consequences. A document which undergoes change can not be referenced located by UUID (e.g., UUID in a URN). An identifier other than UUID must be used. The utility of the mutable UUID is difficult to perceive. It offers uniqueness.

[aj-stein-nist]

https://pages.nist.gov/OSCAL/concepts/layer/overview/ levies a requirement that the root element UUID of an OSCAL document must change when the document is changed. The requirement has consequences. A document which undergoes change can not be referenced located by UUID (e.g., UUID in a URN). An identifier other than UUID must be used. The utility of the mutable UUID is difficult to perceive. It offers uniqueness.

Well, my answer to "How would I publish GovReady's reference information of UUID and address information for others to find (e.g., directory services)? What if I update my address -- does my UUID change?" in #140 (comment) focused narrowly on the kinds of UUIDs Greg asked about for this reason. That UUID in a document was not what I was addressing. I understand that is a challenge and if want to discuss that informally or formally, we can talk about that in another issue maybe? :-)

[aj-stein-nist]

@gregelin I would like to revisit this work and whether we will allocate or commit time to it in the same ad-hoc fashion moving forward. If I do not hear back from on this message by 24 February 2023 I will close this and reopen the issue accordingly.

[gregelin]

@aj-stein-nist Sounds fine to revisit later.