Option 2 for #2112

[xee5ch]

Committer Notes

Instead of adjusting the constraint, this changes alternatively proposes updating the enumeration with a new enum value of "recommendation." This may be the proposal of @iMichaela in the comment below, and this change proposal is to determine if it is the preferred approach.

#2112 (comment)

If merged, closes #2112.

All Submissions:

• Have you selected the correct base branch per Contributing guidance?
• Have you set "Allow edits and access to secrets by maintainers"?
• 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?

By submitting a pull request, you are agreeing to provide this contribution under the CC0 1.0 Universal public domain dedication.

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

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)?
• Have you updated the OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the OSCAL-Pages and OSCAL_Reference repositories.

[iMichaela]

@xee5ch - Thank you again for the second option proposed. This option is simply adding a new acceptable value recommendation. Is it all we need, another value?

<allowed-values id="oscal-control-part-name"
                        target="part[has-oscal-namespace('http://csrc.nist.gov/ns/oscal')]/@name">
[...]
                        <enum value="guidance">Additional information to consider when selecting,
                              implementing, assessing, and monitoring a control.</enum>
[...]
                        <enum value="recommendation">The part describes a specific approach for a set of implementation requirements more opinionated than a statement or guidance.</enum>
                  </allowed-values>

NIST SP 800-18 v1 defines:
guidance (scoping guidance) = "Provides organizations with specific technology-related, infrastructure-related, public access-related, scalability-related, common security control-related, and risk-related considerations on the applicability and implementation of individual security controls in the control baseline."

There is specific definition given by NIST around a statement being a "recommendation" but FIPS 201-3 defines the recommendation = "A special publication of the ITL that stipulates specific characteristics of the
technology to use or the procedures to follow to achieve a common level of quality or level of interoperability".

I'll search ISO/IEC for definitions to adjust the proposed description above for "recommendation". The focus should be on the level of enforcement (shall, should, in case you need this) as opposed to how opinionated the author of the statement is.

[xee5ch]

I actually opened this PR hoping we would discuss this feedback and further my point about namespacing part names. What if I do not want to have recommendation parts that must or should line up with a NIST special publication or ISO/IEC standard? Is this not why it should be in a separate namespace for whatever the individual and organization mean by recommendation in their particular context?

[iMichaela]

I actually opened this PR hoping we would discuss this feedback and further my point about namespacing part names. What if I do not want to have recommendation parts that must or should line up with a NIST special publication or ISO/IEC standard? Is this not why it should be in a separate namespace for whatever the individual and organization mean by recommendation in their particular context?

If humans do not have the same understanding of a concept, how will their machines do better and interoperate or understand how to apply the information? If "recommendation" means something else for you than for me, how will we be able to understand each other? Will it be based on what "recommendation" means in a specific standard, so it will require a human to code it base on each standard understanding or definition? Just trying to understand your point and objection to a standardized meaning. For example, what in ISO/IEC is "Other information" in the English version is translated not as "D'autres informations" but as "Informations supplémentaires". The translation was done manually. Do you think that the provided information needs to have in France a different understanding than in US? Or was ti done this way so French and Americans understand what to do with the information in the same way? OSCAL needs to have a way to make all tools speak the same language and understand it beyond any doubt. What is wrong with pointing to a standardized definition of a term?

Bill Murray (AWS at the time he used this example) was showing what the meaning of "secure premisses" is for navy, army, marines, air force.

It means: navy= turn lights off and leave the ship anchored; army=close the gates and stay inside; marines=take over; air force=sign the lease contract.

So I am asking you again: do we want in OSCAL recommendation to mean the same thing for everyone (e.g. "you should..") vs. guidance (e.g. "consider it if you feel like"), or be locally interpreted?

[xee5ch]

If humans do not have the same understanding of a concept, how will their machines do better and interoperate or understand how to apply the information?

I am not sure what we are arguing here but to focus on the OSCAL one subset of people should be able to agree on their use of a term and identify, specific to their context, with a namespace identified encoded explicitly with @ns, for a period of evaluation before proposing upstream like this or for the long term. This is how OSCAL supposed to work?

I ask as one of the few people proposing upstream changes. Namespaces allow an individual or subset of people to agree before or separately of the OSCAL maintainer as the semantics of a data point evolve. This is from the documentation I cited on the issue originating this change proposal.

Before I discuss the more detailed context conversation, can we confirm we're on the same page on the documented person of extensions and namespaces?