poam-items should optionally encode planned and actual times of item changes and resolution

[aj-stein-gsa]

User Story

As a developer of OSCAL-enabled tooling and engineer documenting systems in OSCAL, I would like the information model to include an optional field to encode the planned and actual completion date of individual poam-items in a plan-of-actions-and-milestones document instances.

Goals

• Allow teams documenting an information system to provide times and durations for POA&M items
• Allow teams documenting an information system and writing OSCAL-enabled software to find duration of new, ongoing, or closed POA&M items

Dependencies

No response

Acceptance Criteria

• All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

[aj-stein-gsa]

I would love community and NIST maintainer feedback, the quickest viable way to add this would be through props that have datetime-with-timezone matches requirements and not adding assemblies, fields, or flags, but I am open to opinions on either approach and I will draft a PR.

I will not mark this as a "bug" but I was modeling data with a colleague and realized we do not have good examples and no such modeling exists in core or "extension-by-constraint" in the models or FedRAMP work over the years, so I think it is very much worth pursuing sooner rather than later for an upcoming release. Thoughts?

[aj-stein-gsa]

I proposed some changes in #2117. These values are relevant dates for information that could show up in a POAM for individual rows of POA&M items as required by FedRAMP in their published template and analyzing production data. I am proposing them as optional fields in the core model in the core namespace because we believe them to be generally applicable. If NIST maintainers disagree with that assessment, we can pull that into FedRAMP-specific namespace and external constraints and not propose them in the core. I just wanted to give NIST the option to review and get an idea of what is missing, and coordinate a quick decision there, @iMichaela.