Should SystemComponent Status include under-major-modification like SystemCharacteristics?

[fsuits]

Question

SystemComponent allows ImplementationStatus state as being one of [under-development, operational, disposition, other]. SystemCharacteristics is the same, except it also allows under-major-development. Is this intended? As an automation code writer it is helpful to have a common set of options where possible, and as a document creator it is less confusing not to have these small differences. Plus - it seems natural that a component itself could also be in a state of major development.

[aj-stein-nist]

Thanks for the willingness to open a question about this. Let us talk about this with the team and respond when we have had time to discuss, probably best case early next week.

[fsuits]

For a concrete coding scenario, in trestle the schema gets broken down into python classes representing content that is common across different models - a simple example being Parameter, which many models share. In contrast, SetParameter is needed by different models with slightly different forms due to different needs of each model.

But something like ImplementationStatus is a more generic concept that includes a simple token State in some models, but has very restricted list of options in SystemSecurity plan - where the two lists differ only by one extra element: under-major-modification. In the SSP model, ByComponent has a State of the generic token kind, while SystemCharacteristics has a State that includes under-major-modification, and SystemComponent has a State that does not have that additional option.

I would have thought ImplementationStatus would have the same possible values for SystemCharacteristics and SystemComponent - and having two separate lists of options to be aware of adds cognitive complexity to the code and to what authors need to keep track of.

[Arminta-Jenkins-NIST]

At the 11/9 Triage Meeting: @iMichaela will refresh her memory regarding this ticket.

[Arminta-Jenkins-NIST]

At the 11/16 Triage Meeting: We will revisit this next week after we assigned to @iMichaela to look over.

[AleJo2995]

Hi @Arminta-Jenkins-NIST and @iMichaela . Hope you're doing well. I'm Alejandro Leiva, product owner of Trestle now. Frank is no longer in the team but he has given us an update on this being prioritised to be worked on. From now on, I will be the contact for this issue. Do you need me to re-open it or is it ok to follow here? Thanks

[iMichaela]

Analysis and Summary

Control implementation status

system-security-plan/control-implementation/implemented-requirement/by-component/implementation-status = indicates the degree to which the a given control is implemented. The implementation-status is used to qualify the status value to indicate the degree to which the control or the control objective is implemented.

The value MAY BE LOCALLY DEFINED, or one of the following:

implemented: The control is fully implemented.
partial: The control is partially implemented.
planned: There is a plan for implementing the control as explained in the remarks.
alternative: There is an alternative implementation for this control as explained in the remarks.
not-applicable: This control does not apply to this system as justified in the remarks.

System status

system-security-plan/system-characteristics/status = describes the operational status of the system. The status is used to qualify the state value which MUST be one of the following:

operational: The system is currently operating in production.
under-development: The system is being designed, developed, or implemented
under-major-modification: The system is undergoing a major change, development, or transition.
disposition: The system is no longer operational.
other: Some other state.

When other is selected, a remark MUST be provided.

The implementation-status@status serves a different purpose than the status@state and the two lists are totally different. While the implementation-status@status may have locally defined values, the status2state may not.

@AleJo2995 - can you please clarify if the above analysis is not addressing the question posted. The question appears to not reflect accurately current OSCAL specification. Maybe the question is old and obsolete?