Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation about transport layer ports being IPv4 implies they are not IPv6 #2065

Open
aj-stein-gsa opened this issue Nov 9, 2024 · 0 comments · Fixed by #2070
Open
Labels

Comments

@aj-stein-gsa
Copy link
Contributor

Describe the bug

As a developer directly using the official documentation directly through a browser or via OSCAL-based software that provide hints via this documentation, I would like clear explanation of /system-security-plan/system-implementation/component/protocol/port-range inline documentation that suggests the poort range therein is "[w]here applicable this is the IPv4 port range on which the service operates." This framing implies the transport layer ports embedded with in IP (TCP; UDP; SCTP; et cetera) work with IPv4, but not IPv6. I would propose a change to tighten this wording.

Who is the bug affecting

Developers who rely on documentation through direct review or prepare software the use this documentation to hint to developers proper definition of OSCAL data who want clear guidance on port and protocol ranges.

What is affected by this bug

Documentation, Metaschema

How do we replicate this issue

Review the above Metaschema module reference and resulting website documentation rendered.

Expected behavior (i.e. solution)

The documentation does not imply that port ranges are not IPv4 only, clarify they are transport layer protocols (e.g. SCTP, TCP, UDP).

Other comments

No response

Revisions

No response

@github-project-automation github-project-automation bot moved this to Needs Triage in NIST OSCAL Work Board Nov 9, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Nov 13, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Nov 15, 2024
aj-stein-gsa added a commit to aj-stein-gsa/OSCAL that referenced this issue Nov 15, 2024
By rebasing I reintroduced the deprecated CamelCase datatype variant.
This change reintroduces the new kebab case preferred in Metaschema
models, per @imichael's request during code review.
iMichaela pushed a commit that referenced this issue Nov 15, 2024
By rebasing I reintroduced the deprecated CamelCase datatype variant.
This change reintroduces the new kebab case preferred in Metaschema
models, per @imichael's request during code review.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Needs Triage
Development

Successfully merging a pull request may close this issue.

1 participant