Defined additional allowed values for the control 'status' property

[brian-ruf]

Committer Notes

This PR updates the allowed values for the "status" property associated with controls in catalogs and profiles.

It is intended to address #2195

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]

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

[iMichaela]

@brian-ruf - The proposed new allowed values appear reasonable. However, I have two specific recommendations:

1. Status Context: The value active may cause confusion since all controls are implicitly active by default. We should consider defining this status more precisely, perhaps it should indicate that a parameter has been set by an authoritative entity and that permissions to override that parameter have been revoked. This would give the status a functional purpose beyond the default state.

2. Case normalization: To ensure robust validation, we should include both lowercase and capitalized versions of these values (e.g., 'withdrawn' and 'Withdrawn') to accommodate different data entry styles."

[canb227]

In regards to # 2: personally I think we should just normalize to lowercase instead of allowing both uppercase and lowercase.

[brian-ruf]

@iMichaela

On 1. Status Context I may not have been clear enough about my intention. I was only trying to have an explicit status that is the moral equivalent of a control with no explicit status (as 99% exist now). I selected active somewhat arbitrarily and am open to a different value.

When I read "permissions to override that parameter have been revoked", I interpret it as "you are not allowed to tailor this control", which sounds like it has implications for profile resolution. I am open to the idea of a status value with this semantic meaning. Since such a status would/should impact profile resolution, are you OK with addressing it as a separate issue that can receive more attention?

That said, I am absolutely open to changing the value from active to something else that better represents the moral equivalent of normal controls in a catalog with no status.

On 2. Case normalization, 98% of the allowed values in OSCAL are strictly lower case. There are a few exceptions that are strictly upper case. (I personally don't agree with even those exceptions.) The existence of "Withdrawn" with a capital "W" was an error from the release candidates, which is why it is marked depreciated, after version 1.0.0.

If anything, we should remove the capital-W "Withdrawn" from the metaschema since it is explicitly invalid after 1.0.0 anyway. If you agree, I am happy to make that change.

[iMichaela]

@brian-ruf - In principle, I agree with you to simplify and use only sentence case (lower case). I am concerned over the accuracy some catalog owners require/expect in the OSCAL representation. How will we accommodate it, if you have to do so?

The list of non-exhaustive keywords I collected:

• Withdrawn: Used heavily by NIST (SP 800-53) and ISO. It means the control is no longer a standalone requirement.
• Retired: Common in CIS Benchmarks and OWASP. It indicates the control or project is no longer maintained or relevant to modern threats.
• Deprecated: Often used in IETF (RFCs) and OWASP. It means the control/method is still available but discouraged and will likely be removed in future versions.
• Obsolescent: Occasionally seen in ISO standards to describe a process that is being phased out.
• Incorporated: Primarily used by NIST. This means the specific requirements of Control A have been folded into Control B (e.g., "AC-17 is now incorporated into AC-1").
• Superseded: Used by IETF and NIST. This indicates that a newer version of the control or document has replaced the old one entirely.
• Consolidated: Frequently used during major version jumps (like the transition to ISO/IEC 27001:2022). It means multiple specific controls were merged into one broader, more functional control.
• Modified / Enhanced/Renamed: Used across all frameworks (especially NIST and CSA CCM) to show that while the ID remains the same, the underlying requirements have been updated.
• Simplified: Seen in CIS v8, where controls were restructured to be more manageable for smaller organizations.
• Split: When one complex control is broken down into two or more distinct parts for better clarity.

NIST is using all capital letters or "Title Case": "WITHDRAWN" or "Withdrawn"
ISO, IETF, CIS: are using Title Case: "Merged", "Deleted"

[iMichaela]

Please see the inline comment.

[selenaxiao-nist]

Thank you for your contribution!

For these additional status prop allowed values, could this cause confusion/introduce the opportunity for inconsistencies?

If a control is withdrawn and incorporated into another control, there are 3 potential ways to represent this:

1. both the "withdrawn" and "incorporated" props, and "incorporated-into" link
2. the "withdrawn" status prop and "incorporated-into" link
3. the "incorporated" status prop and "incorporated-into" link

[iMichaela]

Thank you for your contribution!

For these additional status prop allowed values, could this cause confusion/introduce the opportunity for inconsistencies?

If a control is withdrawn and incorporated into another control, there are 3 potential ways to represent this:

1. both the "withdrawn" and "incorporated" props, and "incorporated-into" link
2. the "withdrawn" status prop and "incorporated-into" link
3. the "incorporated" status prop and "incorporated-into" link

@selenaxiao-nist raises a good point. OSCAL needs to be flexible and allow a catalog owner to represent the data they have . This brings forward the definitions the PR provides. I don't think we should define the meaning of any status value. The meaning of a term is defined in each catalog and we should not overwrite it with our definitions. OSCAL only facilitates data representation.

In this context, my comment on the definitions @brian-ruf provided is obsolete. However, the term "active" is not something I encountered. In all catalogs I reviewed, the default status of a control is not documented.

[brian-ruf]

Thank you for your contribution!

For these additional status prop allowed values, could this cause confusion/introduce the opportunity for inconsistencies?

If a control is withdrawn and incorporated into another control, there are 3 potential ways to represent this:

1. both the "withdrawn" and "incorporated" props, and "incorporated-into" link

2. the "withdrawn" status prop and "incorporated-into" link

3. the "incorporated" status prop and "incorporated-into" link

@selenaxiao-nist this is a fair point. Perhaps we should drop the "incorporated" and "moved" allowed values for status and just stick with the "incorporated-into" and "moved-to" links to represent those concepts.

I would still expect a control to be withdrawn if "incorporated-into" or "moved-to" links are present, but am reluctant to enforce that in a constraint until it is better exercised in the wild.

NOTE: I edited this comment after posting to remove an incorrect assertion.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

[brian-ruf]

@iMichaela I made updates and pushed changes last week following our exchange above. Wanted to ensure there are no other concerns.

[stephenbanghart0]

+1 to the changes in general, expanding the natively defined values for props that allow-others is (IMO) typically a strict improvement - users that don't want to use these values are still free to continue using anything else instead.

As an optional (at least, I think its optional) it seems like the default behavior of the model should be that if it doesn't appear then it simply means nothing. Either setting the default to something like "unspecified" or instead setting no default at all seems to make more sense to me.

[brian-ruf]

In the OSCAL Foundation TWG meeting on March 24th, @iMichaela verbally stated that this PR and associated issue were "controversial" and that NIST would not move forward until the OSCAL Foundation resolved the controversy.

@iMichaela, it would of great help if you could please::

• comment here if I misrepresented your position
• concisely identify exactly who has concerns and what those concerns are
• identify exactly what would it would take for NIST to move forward on this PR

Alternatively, please suggest other possible approaches to the original issue #2195

Thank you!

[iMichaela]

In the OSCAL Foundation TWG meeting on March 24th, @iMichaela verbally stated that this PR and associated issue were "controversial" and that NIST would not move forward until the OSCAL Foundation resolved the controversy.

@iMichaela, it would of great help if you could please::

• comment here if I misrepresented your position
• concisely identify exactly who has concerns and what those concerns are
• identify exactly what would it would take for NIST to move forward on this PR

Alternatively, please suggest other possible approaches to the original issue #2195

Thank you

The following values are listed in the updated PR:

<enum value="withdrawn">The control is no longer used. It may have been retired, incorporated into another control, or moved to a different control.</enum>
                        <enum value="normal">[Default] This control exists as intended.</enum>
                        <enum value="reserved">This is a placeholder for a future control.</enum>
                        <enum value="deprecated">This control will be withdrawn. The withdrawn timeline or milestone may be describe the remarks.</enum>
                        <enum value="conditional">This control is only applicable under certain conditions described in the remarks.</enum>
                        <enum value="superseded">This control has been superseded by the artifact indicated by one or more "superseded-by" links or as described in the remarks.</enum>
                        <enum value="modified">This control has been updated from a prior version, as described in the remarks.</enum>
                        <enum value="experimental">This control is a pilot or proposed control; not yet required.</enum>

@brian-ruf - The PR has not been reviewed by the foundation or by any other community.

1. [breaking change]: The controversial part in this PR is the proposal of a "Default" value which implies every single control will have to have a status and the "Default" value must be used when no other value is specified in the original (non-OSCAL) catalog. This is a major change for authors and users of a catalog, and it is not aligned with the past representation of the controls in already published catalogs. I requested the removal of any 'Default' value for that reason.

If you insist on having a "Default" value, and each control to have a documented status, as opposed to having a status only when a change in that control happened and needs to be documented, then the PR needs to be reviewed by the community at large (all authors and users of existing catalogs existing catalogs).

The official review of the OSCAL Foundation members is expected in this case. Based on the OF's review, if a "Default" value is kept in the PR, we will discuss it with all international adopters of OSCAL which authored catalogs (NIST RMF team included) to assess the impact before moving forward with a change that includes a "Default" value.

Today, no prop@name="status" value="" is included the default representation for controls that are active/normally/not-changed

2. [needs further implementation support] Additionally, the status "reserved" is strange. Why would anyone include an official control that says NOTHING - has no statement? Just a title ... If there are today use cases when this feature is permitted, we can incorporate it. Otherwise it will be an addition the implies additional functionality in Profile Resolution Specification.

The support, through this PR ,of a prop@name="status" value="reserved" must be associated immediately after with the proper support in Profile Resolution Specification: (documentation and toolchain)

If the need for an empty control with the status "reserved" is not something needed by the catalog owners, why should we implement it and maintain it. Profile Resolution Specification is complex, difficult to implement, and has issues already. Supporting empty controls in catalogs comes with a lot of overhead and extra work that personally I do not think is needed, but if the community needs it and assists with the implementation, we will work with the interested parties.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

[brian-ruf]

Adding links to Department of Education "Reserved Controls" examples:

• AT Family - See:
  • Section 2.2, Control Overlay AT-02 ED-02 and Control Overlay AT-02 ED-03
• CM Family - See:
  • See section 2.2.4, Control Overlay CM-02(07) ED-02

For example, in the AT-02 control overlays, it appears they previously had overlays 01 through 03. They withdrew 01 and 02, but intend to re-use those identifiers if they have a reason to define other overlays for that control in the future.

All I know for certain is that they explicitly depict some overlays as "Reserved" and "withdrawn" while they wish to depict other overlays as simply "Reserved".

[brian-ruf]

@iMichaela respectfully, perhaps "controversial" isn't the best word. Semantics aside, the clarification about a perceived breaking change is fair to question.

Apologies if I am not making myself clear. First, there is no intention to make this a required property. In this PR, the status property remains optional. There is also nothing that invalidates currently accepted value.

All existing OSCAL catalogs would remain valid as-is. Thus no breaking change.

Implied vs Explicit Meaning

OSCAL aside. From a strictly language and semantics perspective there has always been an implied status when a control is present in a catalog with no explicit status (such as "withdrawn) stated.

I was only attempting to define an explicit status value that was the moral equivalent of that implied status.
It seems the real "controversy" is that we can't agree on that implied meaning when no status is explicitly stated.

I will remove the default value from this PR so that it can be merged.

When NIST can accurately define the meaning of a control's existence in a catalog when no status is explicitly stated, we can circle back with a new PR to add an allowed value that represents that moral equivalent.

Meaning of reserved

Respectfully, we have presented a real-world use case where a US Government Agency uses a status of "Reserved" for some control identifiers.

See explicit examples posted in the comment above.

Compelling the OSCAL Foundation to Respond

As I have stated elsewhere, NIST has no authority to compel the OSCAL Foundation to respond to PRs as a justification for blocking them.

You have notified the Foundation in two separate TWG meetings that you would like its input. While I welcome any input the Foundation elects to provide, it is not valid to insist on OSCAL Foundation input as a requirement of merging this PR.

[iMichaela]

@brian-ruf :

1. Implied vs Explicit Meaning - If the [default] value is removed, the first issue is resolved. It eliminates the inconsistency and confusion caused by having some controls include a prop with status="normal" (implicitly treated as default), while others omit the prop entirely.

2. Meaning of reserved - The Department of Education use case appears to be unique at this time. We can support it under one of the following conditions:

   a) The current Profile Resolution Specification and NIST toolchain support modify and merge operations on empty (“reserved”) controls that have an ID and title but no content.
   If you have tested this scenario and can provide evidence (e.g., a sample profile that resolves successfully and supports modification/merge without errors), please share it so we can validate locally. Once demonstrated, we can accept the "reserved" value.

   b) The current Profile Resolution Specification and NIST toolchain do not support modify and merge operations on empty (“reserved”) controls.
   In this case, I recommend removing the "reserved" value from this PR to allow timely approval, and addressing it in a separate PR after the Specification and toolchain are updated accordingly through a dedicated PR.

3. Compelling the OSCAL Foundation to Respond - You are correct, I do not have authority to compel responses beyond my team. The Foundation represents one voice within the broader community, a voice committed to support NIST and the community. I appreciate you noting that I requested review from the OSCAL Foundation twice; I did so intentionally. Even optional values introduced in this PR will require support across tool vendors implementing OSCAL, including updates to profile resolution if current specification is not addressing such case.

Supporting 'reserved" (i.e., structurally empty) controls that may be populated later could introduce non-trivial implementation challenges for existing tools.
If the OSCAL Foundation is unable to prioritize this review, I will seek input from other OSCAL stakeholder communities I engage with.

To summarize: - You have agreed to remove the [default] value, so item (1) should be resolved. I look forward to your response on item (2):
If condition (a) applies, please provide sample artifacts so we can validate locally and proceed with approval.
If condition (b) applies, additional work is required; we can proceed with the remaining values in this PR.

In the interim, you may continue using the "reserved" value within the Department of Education namespace, and remove the namespace once the necessary Specification and toolchain support are in place. At that time the "reserved" value can be added to the ones proposed herein.

[brian-ruf]

@iMichaela

1. I have removed normal (default) as a choice.

2. I adjusted an undocumented constraint that only allowed controls to be missing parts if they have a status of withdrawn or Withdrawn. It now allows controls to be missing parts with a status of 'withdrawn','Withdrawn', 'reserved', 'deprecated', or 'superseded'. For other status types like experimental, a part would still be expected.

3. You have recently revoked my NIST access to this repo. So I am no longer able to push these changes directly to the OSCAL/control-status branch.

• I have created PR Removed Default Status. Adjusted Constraint on Absense of Part. #2222, which merges these changes from the brian-ruf/control-status branch to the OSCAL/control-status branch.
• The intent is to keep the discussion and changes here, but someone on your end needs to merge it.

---

OSCAL Foundation

My volunteer time with the OSCAL Foundation should not result in my contributions as a small business owner being held to a different standard.

I submitted this PR and its associated issue without any mention of the OSCAL Foundation because these were real-world use cases I encountered in course of my client work. This PR has no relationship to current Foundation efforts. While I welcome any feedback the Foundation elects to contribute, you have announced this PR twice in Foundation meetings and there has been no interest from them in this PR.

---

Inconsistent Demanding/Ignoring of Foundation Involvement

The OSCAL Foundation has existed for nearly 1.5 years. In that time you have not attempted to impose Foundation involvement on any previous PR. Indeed, you recently even pushed through a PR that added over a dozen new fields explicitly against the Foundation's wishes.

Please hold my small business only to standards similar to what you imposed on PRs such as #2203 and #2206.

The inconsistency is ... very disturbing.

Further, there is an existing MOU between NIST leadership and the OSCAL Foundation. If you believe that MOU should require some specific involvement in PR reviews, I strongly encourage you to work though your leadership to affect that change. Until then, please stop imposing a different standard on my small business.

Please make no further attempts to use a PR submitted by a small business to litigate your concerns with the OSCAL Foundation.

---

Another Non-Typical Requirement Imposed

In addition to the non-typical insistence on OSCAL Foundation involvement, you have also imposed a NEW condition that I must demonstrate profile resolution tools will handle a "reserved" control correctly. This requirement has never been imposed on any previous catalog syntax change PR for two very good reasons:

1. Specifications. Not Tools: This repo is about specifications, not tools, and the profile resolution specification is deliberately agnostic to catalog syntax. It is well known among the community that any prop can have any name, class, group, value or ns without any impact to profile resolution processing.

2. Tools won't attempt resolution until "reserved" is an allowed value. (chicken/egg): The OSCAL-CLI tool is the only NIST-recognized tool that performs profile resolution. It won't attempt resolution with a "reserved" control present until "reserved" is an allowed value. It will currently identify the catalog syntax as invalid and halt processing prior to resolution.

You personally compile the NIST OSCAL-CLI after each OSCAL release. You personally KNOW it won't process this content until this PR is merged and you have updated the tool. You imposed the requirement to demonstrate through tools at this step in the process knowing the updated tool is not yet available.

---

Valid Catalog Syntax Remains Unchanged

There are no changes to the catalog syntax to support this beyond the allowed value on an existing property. All existing catalog syntax remains as-is. Including minimum required fields.

The syntax for a "reserved" control is identical to the existing NIST-published "withdrawn" controls. The only difference is the use of reserved instead of withdrawn in the status property.

Here is an existing NIST SP 800-53r5 withdrawn control:

            - id: ac-2.10
              title: Shared and Group Account Credential Change
              props:
                - name: label
                  value: AC-02(10)
                  class: zero-padded
                - name: label
                  value: AC-2(10)
                - name: label
                  value: AC-02(10)
                  class: sp800-53a
                - name: sort-id
                  value: ac-02.10
                - name: status
                  value: withdrawn

Simply replace "withdrawn" with "reserved" on the last line and the above example is completely syntax-valid for "reserved".

Summary

• An analysis of NIST approval history on PRs demonstrates an imposition of different standards for this PR compared to historical requirements on other PRs. My volunteer work at the OSCAL Foundation does not justify holding my submissions as a small business/independent consultant to a different standard.

• I have removed the "default" status value as discussed/agreed and fixed an undocumented constraint that would have prevented "reserved" controls from using the same syntax as "withdrawn" controls. The change allows like syntax.

• Your recent change to my status with NIST blocks me from pushing any further updates directly to this PR. I have offered a workaround, which requires action from you.

• I have gone to great lengths to demonstrate to the greatest degree possible that any concerns about profile resolution for "reserved" controls is no different than profile resolution for existing "withdrawn" controls. The syntax is identical, thus the processing is identical given the profile resolution specification is not impacted by changes to any specific control property.