Profile resolution: clarification needed wrt pruning?

[wendellpiez]

"Pruning" is what the profile resolution spec describes as the removal of items from catalogs to produce baselines (resolved catalogs), where those items are not wanted or needed. A typical example would be how after selecting only a few controls from the catalog, in resolution a processor should know how to propagate only those resource objects in the back matter, that are actually referenced as links in the included controls. So the back matter gets trimmed to what is actually used. This can be overridden by including a property keep with value always, as described etc. etc.

Except as written, the rules are too greedy, and following them would require including (for example) controls that are specifically excluded.

For example https://pages.nist.gov/OSCAL/concepts/processing/profile-resolution/#d2e1504-head,

If the object appears in a reference anywhere in the final result catalog, except in other objects that also meet all other pruning criteria, it MUST NOT be removed. A reference to a given object exists if #{distinctiveID} appears anywhere, where {distinctiveID} is the distinctive ID of the object ...

If we follow this, then any control that is cross-referenced via link[@rel='related'] must be included, even when explicitly not included.

Similarly problematic are references from the merge phase.

Let's consider tightening these rules for example to include only references to parameters (which cannot be pruned without doing actual damage to document semantics), not just any reference to something?

[wendellpiez]

Also, it says a processor SHOULD perform the pruning: shouldn't this be a MUST?

As to the pruning itself, instead of keeping controls whenever somewhere there is included content that references them, maybe we should prune the related links that point to excluded controls. Arguably this changes the control (baseline) content significantly.

[david-waltermire]

@wendellpiez We should take a stab at writing a better set of specification requirements. Perhaps we could do this and post a proposal in this issue?

[david-waltermire]

Assigning this to OSCAL 1.1.0 since this is a major interoperability issue that affects effective baselines produced through profile resolution.

[wendellpiez]

Suggest we discuss pruning as two sets of requirements:

• Removing "unused" stuff such as parameters that can be determined to be orphaned, or unused references, but not excluded controls
• Rewriting links that can be determined to be broken in resolution result
  • typically, cross-references to controls

Both of these require care but for different reasons. Note that rewriting links assumes they are not among the class of things to be removed if "unused".

Maybe we should rewrite the spec with this distinction in mind?

[Arminta-Jenkins-NIST]

UPDATE: This issue is blocked. Some work has been done to implement a concept, but the question about the Profile Resolution spec is blocked until @nikitawootten-nist (and team) has the capability to drive the unit testing for Profile Resolution. We should revisit this issue in a few weeks when progress is made on unit testing the Profile Resolution.

[Arminta-Jenkins-NIST]

At 11/9/23 Triage Meeting: @JustKuzya suggested that this ticket along with #1442 will be superseded by a new issue in order to create examples and if needed clarify the profile resolution specification.