Component-Def/component/protocol/port-range start and end points are not identified.

[RS-Credentive]

Describe the bug

If a component definition has a port range with a start and end, eg:

                        "port-ranges": [
                            {
                                "start": 80,
                                "end": 80,
                                "transport": "TCP"
                            }
                        ]

oscal CLI reports the following:

[WARNING] [/component-definition/component[X]/protocol[X]/port-range[X]] A start port exists, but an end point does not. To define a single port, the start and end should be the same value.
[WARNING] [/component-definition/component[X]/protocol[X]/port-range[X]] An end point exists, but a start port does not. To define a single port, the start and end should be the same value.

Who is the bug affecting?

Me

What is affected by this bug?

component-def validation

When does this occur?

When passed the attached component definition rails-puma-component-def.json

How do we replicate the issue?

oscal-cli component-definition validate rails-puma-component-def.json

Expected behavior (i.e. solution)

Document should validate

[iMichaela]

@RS-Credentive - Hi Rob - this is a known-to-NIST error in the OSCAL definitions (the constraints). We will have it corrected in the next OSCAL release, but to ensure traceably at your end, do you mind moving this issue to OSCAL repo? Thank you.

[RS-Credentive]

I will do this. Thanks!

[iMichaela]

Issue https://github.com/usnistgov/OSCAL/issues/2023 addresses the core problem of this issue, and future releases of oscal-cli will not exhibit this error after the https://github.com/usnistgov/OSCAL/issues/2023 is closed.

[inickles]

I think this issue should remain open until it is fixed in a released version of the CLI, I was about to file a duplicate of this issue until I stumbled across this.

I'm still seeing this behavior in v1.0.3.

[iMichaela]

This bug is propagated from the OSCAL model. It has been fixed there, and the locally generated oscal-cli based on the new models no longer display this error. Unless the open-source policy changes, we are not planning to release it to MAVEN in the near future. users can generate their own copy or reach out to NIST team to obtain one.