oscal-cli validation rule for ssp/system-implementation/components/protocols/port-ranges/transport

[Telos-sa]

User Story:

As an OSCAL {stakeholder}, I want to pass a token styled data, and it still validate as long as the token format is met.

Goals:

Adjust the requirements and validations for transport token, to allow either TCP/tcp UDP/udp as either format would be an accepted token format

Dependencies:

Updating the SSP model reference on the Nist Site. Updating metaschema to support all token formats for each token, updating validation.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• [ X ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

[iMichaela]

@Telos-sa - This is an OSCAL schema issue not OSCAL content. Can you please move the issue to the https://github.com/usnistgov/OSCAL repo? . I could do it myself, but it would not preserve the issue ownership. With the said - is the capitalization of the allowed values TCP and UDP such a difficult issue that it cannot be addressed programmatically and requires a schema change? Maybe there is more background info related to this issue that we could benefit from better understanding it?

Also important to note that oscal-cli supports the OSCAL schemas so the change is NOT in oscal-cli
Thank you.

[Telos-sa]

Thanks for the quick response!

I think the root of the request, at least for core metaschema validations, would be for all accepted token formats to be standardized.

User Story: CSP developing legacy content will not have data in tokens. Xacta converts all data elements to token format as single rule, all lower case, replacing spaces with "-". This formula seems to work in all other instances of token usage. For this field, we are creating an additional function for findings token elements that have a different lettercase requirement.

It is not difficult programmatically, but it is a difference that may catch other CSPs, that were converting strings to tokens based on formatting requirements, that they need to be aware when validating, there is also a lettercase check.

[iMichaela]

@Telos-sa - Thank you for the additional explanation. This is still not an oscal-content issue. Are you OK if I move it to the correct repo?

[Telos-sa]

Thank you! Yes please move Stephanie Lacy | Senior Solutions Architect ***@***.*** | www.telos.com<http://www.telos.com/> [signature_19392405]

…

________________________________ From: Michaela Iorga ***@***.***> Sent: Friday, August 23, 2024 1:42 PM To: usnistgov/oscal-content Cc: Telos Solutions Architects; Mention Subject: [Caution: External] Re: [usnistgov/oscal-content] oscal-cli validation rule for ssp/system-implementation/components/protocols/port-ranges/transport (Issue #276) @Telos-sa<https://urldefense.com/v3/__https://github.com/Telos-sa__;!!OIEPfio!XwaZ5wStmL6FTXmIqAMAvByvHywgBVh4NRpaNqI-70tO919aKdClLSBAIx7jBxA9o9q09dYQFP-qdB5zG04viQM$> - Thank you for the additional explanation. This is still not an oscal-content issue. Are you OK if I move it to the correct repo? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/usnistgov/oscal-content/issues/276*issuecomment-2307534189__;Iw!!OIEPfio!XwaZ5wStmL6FTXmIqAMAvByvHywgBVh4NRpaNqI-70tO919aKdClLSBAIx7jBxA9o9q09dYQFP-qdB5zJ2tQhmI$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/A6KF2RJ37OPCRHP6JV5LBG3ZS5YARAVCNFSM6AAAAABM6HZEF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBXGUZTIMJYHE__;!!OIEPfio!XwaZ5wStmL6FTXmIqAMAvByvHywgBVh4NRpaNqI-70tO919aKdClLSBAIx7jBxA9o9q09dYQFP-qdB5zVAgzc8s$>. You are receiving this because you were mentioned.Message ID: ***@***.***>