Redfish direction to update EEPROMs

Yes, both the mechanisms and the policies around updating EEPROMs are highly varied among device implementations. We created the "BinaryDataURI" property in the Assembly resource to provide a standard method to extract EEPROM contents (or any other configuration memory / structure). While a fairly rare service event, there are times that vendors want to view that data, and they were typically using "raw IPMI commands" and IPMItool to perform that task. By providing that functionality via Redfish, we hopefully removed a need to keep IPMItool around, and also made the request much easier to perform without requiring machine-specific instructions.

Now, beyond that, there are certainly times that vendors desire an ability to change the contents of those EEPROMs. From a Redfish perspective, if that is a user-settable value, it would be exposed by a read-write Redfish property (the fact that the value is stored in an EEPROM is a behind-the-scenes detail). But for other "internal" data, it is certainly useful to provide a mechanism to change those contents in the field. And so one possibility is to allow a PUT/PATCH operation on the BinaryDataURI location that performs the update, much like a "raw IPMI command" would do. But that should be a protected operation, enabled/disabled through other means to prevent usage except in those rare service use cases. Which is exactly what you're recommending, and that would be my advice as well.

Jeff