Removed Default Status. Adjusted Constraint on Absense of Part.

[brian-ruf]

This PR updates the usnistgov/control-status branch in PR #2202.
It removes the default value and adjusts an undocumented constraint to ensure controls with certain status values can be empty. This is identical to what is currently allowed for "withdrawn" controls and simply expands the rule to also cover "reserved", "deprecated" and "superseded" controls.

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 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.

[Copilot]

Pull request overview

Updates the OSCAL catalog metaschema constraints around control status handling, expanding which status values allow omitting a statement part and adjusting the documented allowed status values.

Changes:

• Expanded the expect constraint so statement is not required for additional status values (reserved/deprecated/superseded).
• Removed normal from the documented status allowed-values enumeration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The constraint id oscal-catalog-control-require-statement-when-not-withdrawn no longer matches the updated logic (it now also exempts reserved/deprecated/superseded). Consider renaming the id (and/or adding an inline note) so future maintainers don’t misinterpret what this expect is validating.

Suggested change

	<expect id="oscal-catalog-control-require-statement-when-not-withdrawn" target="."
	<!-- Require a statement part unless the control is in an exempt inactive lifecycle state. -->
	<expect id="oscal-catalog-control-require-statement-when-not-inactive" target="."

[brian-ruf]

revised the label to better reflect the constraint revisions.

[Copilot]

Grammar issue in the deprecated status description: “may be describe the remarks” is ungrammatical and should be rephrased (e.g., “may be described in the remarks”).

Suggested change

	<enum value="deprecated">This control will be withdrawn. The withdrawn timeline or milestone may be describe the remarks.</enum>
	<enum value="deprecated">This control will be withdrawn. The withdrawn timeline or milestone may be described in the remarks.</enum>

[brian-ruf]

fixed the grammar issues

[iMichaela]

Please see inline comments.

[iMichaela]

The suggested description of a superseded control reads: "This control has been superseded by the artifact indicated by one or more "superseded-by" links or as described in the remarks." If we allow for the control to be empty, then we also allow for the important superseded information to not exist. I disagree with this proposal that allows a superseded control to be empty because it is important to have which information is superseded.

This is also the case with a deprecated control. As long as the control is still used until it is withdrawn on date X, the information must exist to inform the user of the date when will be withdrawn and in the interim, the control content should be available for use.

Please remove deprecated and superseded from the ('withdrawn','Withdrawn', 'reserved', 'deprecated', 'superseded') list.

Please update then the id to: id="oscal-catalog-control-require-statement-when-not-withdrawn-or-reserved"

[iMichaela]

@brian-ruf - Please let me know if you had a chance to review the comments and if you want to discuss them.

[brian-ruf]

I did not see your earlier comment earlier.

I respectfully disagree with you assertion.
The framework or baseline author* - not the NIST OSCAL Team - decides whether the content must remain present or may be absent in any given set of controls. NIST is free to impose that requirement on 800-53 controls, in an RMF-specific set of constraints; however, it is not fair for NIST to impose that restriction on other framework/baseline authors.

If that is the only way you will approve this, I will adjust the constraint, but I do so under protest.

[iMichaela]

I did not see your earlier comment earlier.

I respectfully disagree with you assertion. The framework or baseline author* - not the NIST OSCAL Team - decides whether the content must remain present or may be absent in any given set of controls. NIST is free to impose that requirement on 800-53 controls, in an RMF-specific set of constraints; however, it is not fair for NIST to impose that restriction on other framework/baseline authors.

If that is the only way you will approve this, I will adjust the constraint, but I do so under protest.

@brian-ruf -- I might not have explained properly the concern I raised. The definition of "deprecated" and "superseded" controls imply that the information is still available. For a "deprecated" control which will be removed in the near future, but still usable at the current labeling time to not have a content is problematic. What would someone implement? I requested today for the OF members that generate or use catalogs other than 800-53, to provide their perspective.