`//metadata/location` "type" Property incorrectly limits allowed values to only `data-center`

[brian-ruf]

Describe the bug

The "type" Property in Metadata Location restricts @value to only data-center, and only allows the property @class to be set to primary or alternate if the @value is data-center.

This is artificially restrictive and needs to be relaxed to reflect more real-world scenarios including:

• head quarters
• regional office / satellite office
• cloud regions / cloud availability zones / failure domains / fault domains
• edge / cdn
• point of presence
• peer data centers (where there is no primary/alternate hierarchy)
  As well as some means of expressing co-location or dedicated location

There are other location types that organizations may have, which may be domain or industry specific, but are still clearly types of locations.

Who is the bug affecting

Large cloud service providers, organizations with diverse data center types and locations, and anyone who needs to express a physical location beyond simply data-center.

What is affected by this bug

Metaschema

How do we replicate this issue

1. Create an OSCAL SSP with the following in /*/metadata/location. Use any value other than data-center in the @value attribute.

        <location uuid='8d19731f-5ae9-4b1a-99ee-4a7889ccf869'>
            <address type='work'>
                <city>City Name</city>
                <country>US</country>
            </address>
            <prop name='type' value='edge' />
        </location>

2. Validate with OSCAL-CLI

3. Observe the output:

`[ERROR] [/system-security-plan/metadata[1]/location[1]/prop[1]/@value] Value 'edge' doesn't match one of 'data-center' at path '/system-security-plan/metadata[1]/location[1]/prop[1]/@value'

Expected behavior (i.e. solution)

Other token values should be allowed.

Other comments

The recommended solution is:

Minimum

Include allow-others='yes' on the two allowed-values assemblies HERE

Change this:

                    <allowed-values target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='type']/@value">
                        <enum value="data-center">A location that contains computing assets. A <code>class</code> can be used to indicate the sub-type of data-center as <em>primary</em> or <em>alternate</em>.</enum>
                    </allowed-values>
                    <allowed-values target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='type' and @value='data-center']/@class">
                        <enum value="primary">The location is a data-center used for normal operations.</enum>
                        <enum value="alternate">The location is a data-center used for fail-over or backup operations.</enum>
                    </allowed-values>

To this:

                    <allowed-values allow-other="yes" target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='type']/@value">
                        <enum value="data-center">A location that contains computing assets. A <code>class</code> can be used to indicate the sub-type of data-center as <em>primary</em> or <em>alternate</em>.</enum>
                    </allowed-values>
                    <allowed-values allow-other="yes" target="prop[has-oscal-namespace('http://csrc.nist.gov/ns/oscal') and @name='type' and @value='data-center']/@class">
                        <enum value="primary">The location is a data-center used for normal operations.</enum>
                        <enum value="alternate">The location is a data-center used for fail-over or backup operations.</enum>
                    </allowed-values>

Ideally

In addition to adding allow-other="yes" above, collaborate with the OSCAL community to canonicalize a more complete list of allowed values for location types.

Revisions

No response

[MatteoFari]

To ensure this PR remains low-risk, I stuck strictly to the minimal fix proposed.

However, I believe we could improve usability (while keeping allow-other="yes" for flexibility).

1. Add a "starter" vocabulary for prop name="type" with short descriptions. (e.g headquarters, regional-office...)
2. Add documentation notes (remarks) near the constraints to explicitly clarify that the enum list is non-exhaustive and that @class is intended for sub-typing.

Let me know what do you think it's best.