Finding in oscal-observation-values enumeration has ambiguous name

[aj-stein-gsa]

User Story

Several community members had indicated that in the assessment layer, given there is a top-level assembly for findings from the assessment, it is confusing to have an observation type in an allowed-values enumeration called finding. Those who had provided said feedback had said they would support renaming the enumeration to tool-finding or something similar. I wanted to bring forward this proposal and draft a pull request to that end.

Goals

• Disambiguate a finding from an observation type with a similar and ambiguous name

Dependencies

N/A

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

[iMichaela]

Great point.
I am also aware of some constraints collisions. We should collect all those issues and address them. We might need to further discuss broken backwards compatibility and the best way to address it.

[aj-stein-gsa]

Great point. I am also aware of some constraints collisions. We should collect all those issues and address them. We might need to further discuss broken backwards compatibility and the best way to address it.

Currently oscal-observation-values is @allow-other="yes" and thus not backwards incompatible, but happy to discuss.

[egyptiankarim]

Rather than tool-finding, which on the surface doesn't account for observations made by "[...] penetration testing, and other means", can we consider another noun like implementation-issue (or maybe even something a bit more opinionated like problem or bug)?

Part of me likes the idea of of going with implementation-issue, and then also changing ssp-implementation-issue to documentation-issue; Then we'd have a very clear delineation between an observation of something being wrong versus something being documented incorrectly.

Side note: Kudos on the continued awesome work with OSCAL! You all are doing wonderful stuff here!

[aj-stein-gsa]

Rather than tool-finding, which on the surface doesn't account for observations made by "[...] penetration testing, and other means", can we consider another noun like implementation-issue (or maybe even something a bit more opinionated like problem or bug)?

I like this feedback and actually had a similar reflection before drafting the PR but thought to myself "no AJ, you're overthinking it," but glad I am not alone.

I will think about this comment and how I can incorporate it the related PR. No one has reviewed the PR yet anyway.

[aj-stein-gsa]

@egyptiankarim, I adjust my proposal in aj-stein-gsa@dff1aac as it matched my intent and I think it is better than what I proposed before, it will now deprecate the other enum value and add some symmetry with documentation-issue versus implementation-issue. I hope your comments will motivate a timely review from @iMichaela and others.

[iMichaela]

@egyptiankarim and @aj-stein-gsa A finding is not an issue. A finding is a discovery or result, while an issue is a problem or challenge that requires attention. Also, in practice, the system owner is dealing with documentation-issues and implementation-issues as part of the implementation step of the RMF, before the SSP and the system are entering the assessment or ConMon steps of the RMF. I am for an update, but not with the discussed choices.

[aj-stein-gsa]

@egyptiankarim and @aj-stein-gsa A finding is not an issue.

Where does this definition come from?

A finding is a discovery or result, while an issue is a problem or challenge that requires attention.

Where does these definitions come from?

I can completely agree with that, and the proposed change is actually to the @type of observation, so saying an observation in an AR is of type finding is confusing, I think we actually agree on this perspective from different angles. I would recommend we look at the specific change in context in #2105 for that reason.

Also, in practice, the system owner is dealing with documentation-issues and implementation-issues as part of the implementation step of the RMF, before the SSP and the system are entering the assessment or ConMon steps of the RMF.

I do not understand, does that preclude system owners or assessors from addressing them outside the Assessment Phase of the SP 800-37 lifecycle and/or doing so when encoding it in OSCAL AP/AR data? I know the RMF a la SP 800-37 is descriptive, but not prescriptive, so should we not be open to allowing people to encode that reality as they need be? It is a flexible process framework, I was trying to not to propose changes where the data model inhibits the flexibility for encoding this any time in the lifecycle. (I am just proffering my perspective when I opened the issue and proposed a change, for context.)

I am for an update, but not with the discussed choices.

Can you propose other choices in the PR review so we can possibly bring it to a close? So far @egyptiankarim is the only person to offer a counterpoint or an opinion and the PR has been open for a little over two weeks, so I presumed us three are the only people with an interest in a change or the status quo.