Correct way to use allowablevalues annotation

Yes, the @redfish annotations can be used for any property, but we would recommend it be used very sparingly, and only to show where an implementation supports a subset of the enumerations (and typically only for properties that are read-write). We defined the annotation to allow client software to avoid "try and fail" semantics by showing what the supported / valid values were in advance. The "BootSourceOverride" is our best example of this, as you'd really like to know what is supported before trying it a dozen times until you find the one that works...

I'll take a look at the spec to see if we need to clarify that these payload annotations are used in that manner, and not just for Actions. Note also that we defined the "ActionInfo" resource to provide more information about parameter usage, and that may be a more appropriate solution in those cases.

Your OEM example is correct, but I would only show that data if that "LedColor" is a read-write property, or there's something else that a client would need to know what possible values it may see.

And as an aside with that example, which is fine to help replicate physical displays on GUIs, in Redfish we try to expose the underlying conditions instead of reflecting indicators. So assuming those LED colors have specific meaning (like fault, enabled, connected, etc.) the client is better served getting values that report those conditions. But as stated above, there's nothing wrong with providing this in addition to the underlying conditions, to help software reproduce the physical display 'look and feel'.

Jeff