However the SensorType enumeration doesn't appear to allow for OEM types 0xC0 - 0xFF. Our system has a few OEM sensors, so if I translate the sensor type for SEL events for OEM sensors the Sensor Type field will fail JSON or CSDL schema validation as the value isn't in the supported list.
Similarly, for the LogEntryCode enumeration, it doesn't appear to allow for 'Sensor Specific' event types (which are defined in the IPMI specification) or OEM event types, so again if I translate the events the entry will fail schema validation.
The questions I have are as follows:
1. Is there a plan to extend these enumerations to cater for OEM sensor or events types, or add some other mechanism to allow them in the schema? 2. Since the 'Sensor Specific' events are defined in the IPMI specification, is there a plan to add support for at least these sensor specific events? 3. In lieu of points 1 and 2, is it reasonable to render the SensorType and LogEntryCode fields as NULL and instead use the OEM object (with reference to an OEM schema) to render the full range for our system, or is it more appropriate to render this into the Message/MessageId fields?
Thanks for the feedback. Yes, we see that the lack of an OEM enumeration type in both of those fields is an issue. We discussed this issue and will add that support in the next release of the schema (which we publicly state is expected in 4Q17). To support the fact that there can be multiple OEM extensions, we'll also add two properties to LogEntry to report those when the SensorType or LogEntryCode value is "OEM".
We will have to have a discussion on the Sensor-specific types, but looking at those tables, my opinion is that it would be better for us to spend cycles on creating modern, Redfish-styled Events (which are used as LogEntry records of type "Event") that cover everything useful from those tables. Those would be standardized as additional message registries with defined messages, parameters, etc.
Thanks for the reply and for considering this for the next schema release. The proposal for dealing with OEM sensor types sounds good to me.
I agree that it would be better to spend time creating specific Redfish Message Registry styled events, since they can afford to be a bit more descriptive and can optionally remove the need for a lot of the string content from the service.