Missing property name values for components

[brian-ruf]

Describe the bug

There are certain properties that were intended to be aligned between component and inventory-item with the idea that the information could be provided either:

• directly in the inventory-item; or
• in the component identified by the inventory item's implemented-component field

Ideally, SSP authors provide as much information as possible within the component itself and each implemented instance (inventory-item) of that component only includes details that change for each implemented instance, such as MAC address (mac-address property)

The following properties should be allowed in both component[@type='software'] and inventory-item, but are currently not allowed in component of any type. For most of these, component is the preferred location.

• os-name
• os-version
• software-name
• software-version
• software-patch-level

The "model" property property, while allowed in both component and inventory-item, has inconsistent naming.

• It is model prop in component
• It is hardware-model prop in inventory-item.
• The prop name should just be model in both places.
• NOTE: hardware-model could be depreciated, but left in inventory-item for now if there is concern that this is a breaking change.

While "interconnection" components currently allow ipv4-address and ipv6-address props, they sometimes require a FQDN or UIR instead of IP address. The following properties should be allowed in "interconnection" components:

• fqdn
• uri

Similar to "interconnection" components, "service" components also require the ability to specific either an IP address, FQDN, or UIR. The following properties should be allowed in "service" components:

• fqdn
• uri
• ipv4-address
• ipv6-address

Who is the bug affecting

• SSP authors attempting to normalize information details between inventory-item assemblies and their related component assemblies.
• SSP authors attempting to accurately document interconnections and services.

NOTE: This also impacts the use of inventory component within the local-definitions assembly of AP, AR and POA&M.

What is affected by this bug

Metaschema

How do we replicate this issue

• Use any of the above properties within an OSCAL SSP
• Validate the OSCAL SSP using the latest oscal-cli
• Observe errors

Expected behavior (i.e. solution)

The above properties should be allowed within the identified component types.

Other comments

No response

Revisions

No response

[aj-stein-gsa]

I am supportive of this bug fix and it is immediately helpful to FedRAMP's use cases. It would seem that we need to add new values and maybe adjust @targets for allowed-values constraints. (I would need to more thoroughly review the core OSCAL v1.1.3 models.) That said, I can propose two options, and I am willing to draft PRs for each or either.

1. Simple, easy in the short-term, but less effective approach in the long-term: just update the relevant allowed-values enumerations without changing whether they are open or closed to extension.
2. Less, but more effective approach in the long-term: updated the allowed-values enumerations and change their respective @extensible property to better-suited to the FedRAMP's use of managed enumeration lists that should necessarily extend to co-exist with use cases outside of FedRAMP.

[wandmagic]

@iMichaela can you take a look at this

[iMichaela]

@iMichaela can you take a look at this

I'll put it on my ToDo list and mark it with high priority. Thank you.

[Gabeblis]

@brian-ruf if possible, are we able to add "hardware-model" to this list. See PR 1088. Thank you.

[iMichaela]

@brian-ruf if possible, are we able to add "hardware-model" to this list. See PR 1088. Thank you.

@Gabeblis - enhancing (adding) accepted values to existing constraints is not a problem. Adding constraints when they were not or removing values accepted before will cause a backwards incompatibility and need to carefully consider such situations.