Relax component protocol constraint for #1913 #2063
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aj-stein-gsa
force-pushed
the
1913-relax-service-component-protocol-constraint
branch
from
6751aaa
to
ef71276
Compare
|
I would request this change be considered for a potential patch release, perhaps 1.1.3, to resolve this issue and unblocking FedRAMP work in our backlog. I am more than willing to discuss further than #1913 to motivate that recommendation or support another release. Let me know. |
iMichaela
added
the
Waiting for Action
|
@iMichaela, against the documented guidance and my recommendations, per your request I rebased and this PR now targets develop. I would welcome the following.
|
This change also relates to usnistgov#1922. FedRAMP staff have analyzed the progression of this constraint as it pertains FedRAMP's tailored use of NIST SP 800-53 controls customized for FedRAMP processes. Previously, it was believed with a representation of a SSP prior to the "this-system" component construct that limiting the protocol assembly usage to _only_ components of service type was feasible. However, this does not allow homogenous this-system-based SSPs to have the same requirement. Moreover this limits the ability of understandbly different sub-component of components approaches with complex multi-layered architecture to have non-service components document their ports and have it filter up into later transformation and processing by OSCAL-enabled tools. For both reasons, we recommend removing this constraint. Staff reviewed historical documentation and believed this constraint to be an overreach of a previous business rule recommended by FedRAMP staff during collaboration with NIST.
aj-stein-gsa
force-pushed
the
1913-relax-service-component-protocol-constraint
branch
from
ef71276
to
48f0546
Compare
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Committer Notes
This change fixes #1913 and relates partially to #1922. FedRAMP staff have analyzed the progression of this constraint as it pertains to FedRAMP's tailored use of NIST SP 800-53 controls customized for FedRAMP processes. Previously, it was believed with a representation of a SSP prior to the "this-system" component construct that limiting the protocol assembly usage to only components of service type was feasible. However, this does not allow homogenous this-system-component-based SSPs to have the same requirement. Moreover, this limits the ability of understandably different sub-component of components approaches with complex multi-layered architecture to have non-service components (those of type software, hardware, etc.) document their ports and have it filter up into later transformation and processing by OSCAL-enabled tools. For both reasons, we recommend removing this constraint. Staff reviewed historical documentation and believed this constraint to be an overreach of a previous business rule recommended by FedRAMP staff during collaboration with NIST.
All Submissions:
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 written new tests for your core changes, as applicable?Have you included examples of how to use your new feature(s)?Have you updated all OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the docs/content directory of your branch.If CI/CD hasn't changed, this change will be automatically propagated by a new release.