|
Post by mraineri on Mar 26, 2024 16:44:54 GMT
Message objects do allow for OEM extensions. There's the typical "Oem" object defined at the same level as MessageId and Message here: github.com/DMTF/Redfish-Publications/blob/main/csdl/Message_v1.xml#L88You are also allowed to modify "Resolution" in your usage of messages. There's no requirement to take the resolution from the message registry as-is since DMTF can't give implementation-specific information for every possible situation. We have this statement in the Resolution property that describes this: > Services can replace the resolution defined in the message registry with a more specific resolution in message payloads. "ActionNotSupported" makes sense to me for what you're describing; you can certainly provide a resolution like "Enable feature X on resource Y." in your message object to convey that situation back to the user.
|
|
|
Post by mraineri on Mar 25, 2024 20:47:17 GMT
It sounds like you're mixing the usage with a multipart HTTP push update and the vendor-specific HTTP push update. If you're trying to push using the URI provided by the HttpPushUri property, it takes two steps: 1) Perform a PATCH to /redfish/v1/UpdateService with "HttpPushUriOptions" and other nested properties in the request body to set the parameters for the next update. 2) Perform a POST operation to the URI provided by "HttpPushUri" with the binary image. I would recommend using multipart HTTP push update since that will send everything in one shot with the parameters in a JSON form and the binary itself in a separate octet-stream form. There's an example of this payload in the Redfish Firmware Update White Paper here: www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf (see "3.1.2 Multipart HTTP push update").
|
|
|
Post by mraineri on Mar 24, 2024 19:50:23 GMT
If you're getting into that level of control for collecting diagnostic data, then you should be making an OEM action for supplying all of the details you need. It looks like you're outgrowing the simplistic intent of having "OEMDiagnosticDataType" as an easy-button way to specify vendor-specific diagnostic data. I'd be very hesitant on adding more OEM parameters to standard actions at this time.
|
|
|
Post by mraineri on Mar 21, 2024 15:16:44 GMT
I did ask some folks more familiar with SSDP and they also agree; if you never send an "alive" message, you'll also never sent "byebye" or "update" messages due to how they tie back to previously sent "alive" messages. So, since there are no other messages used by NOTIFY, setting NotifyMulticastIntervalSeconds to 0 will have the effect of disabling all usage of NOTIFY.
|
|
|
Post by mraineri on Mar 21, 2024 12:56:57 GMT
1) Yes. 2) Yes. I would expect /redfish/v1/Systems/1/Bios to be updated when the system resets though and BIOS has taken the new settings.
The "Settings resource" clause should describe all of these behaviors for that to populate in the settings resource and when the active resource is updated.
|
|
|
Post by mraineri on Mar 21, 2024 11:53:24 GMT
The more I'm reading about "update", I think the same can be said of that too; update is used to advertise changes to a previous alive notification...
So, I'm currently in agreement; set NotifyMulticastIntervalSeconds to 0 and you disable everything due to the strong reliance on sending alive in the first place.
|
|
|
Post by mraineri on Mar 20, 2024 20:35:31 GMT
Reading a bit more into SSDP mechanics with NOTIFY and it might be that if NotifyMulticastIntervalSeconds is set to 0 (which turns off sending any alive notifications), that might have a side-effect of disabling other NOTIFY uses. The byebye message is only sent to clear a previous alive message, so if you don't send alive, you'll never send byebye. The update message is a bit different though; still looking more into this.
|
|
|
Post by mraineri on Mar 20, 2024 13:02:56 GMT
Q1 "services shall allow the end user to disable the traffic separately from the M-SEARCH response functionality" => Does this mean disabling SSDP notify packets except for M-SEARCH? If so, does it mean disabling all kinds of SSDP notify packets or only specific ones? 1. Disable all SSDP notify packets (upnp:rootdevice, urn:dmtf-org:service:redfish-rest, urn:schemas-upnp-org:device:management, UUID) 2. Disable only SSDP notify packets for UPnP (urn:schemas-upnp-org:device:management) If you look at the the UPnP spec, there are really only two types of traffic: search requests initiated by an external user with M-SEARCH, and advertisement broadcasts initiated by the service with NOTIFY. The requirement is to disable everything regarding the latter. There are various forms of how NOTIFY is used, such as the alive message, and all of these are shut off when disabled by the user. Given the configuration options for SSDP in ManagerNetworkProtocol, there's no distinction on different types of SSDP support for different URNs; it's all or nothing. However, I see we don't have a general "disable notify" and only call out the "alive" usage. I suspect Redfish did not envision more general usage, and it might be worth us adding new properties to disable all usage of NOTIFY. Q2 "services shall allow the end user to disable the traffic separately from the M-SEARCH response functionality" => Does this mean disabling SSDP notify packets except for M-SEARCH? If so, should both types of notify packets, ssdp:alive and ssdp:byebye, be disabled? It's everything. From my previous answer, we may need to add something in ManagerNetworkProtocol to give a standard option. Q3 Which property should be used to control the disable/enable functionality except for M-SEARCH? See above; NotifyMulticastIntervalSeconds just affects the "alive" usage, and we need something more general to disable all NOTIFY usage.
|
|
|
Post by mraineri on Mar 19, 2024 17:10:36 GMT
Had to look at this a few different times and it just popped out to me.
Inside of the ContosoSensor.v1_0_0 namespace, the BaseType for the Sensor ComplexType needs to be...
<ComplexType Name="Sensor" BaseType="ContosoSensor.Sensor"> If that doesn't solve the last bit, I'll do some testing on my end when I have some free time to see what might be going on.
|
|
|
Post by mraineri on Mar 12, 2024 15:07:29 GMT
I see one issue so far; in your payload, you have "#ContosoSensor.v1_0_0.Sensor" as the @odata.type. This would mean inside of the ContosoSensor.v1_0_0 namespace, there needs to be a "Sensor" ComplexType. So, either you change the two ComplexType definitions in your schema to have the name "Sensor", or change the @odata.type value in your payload to be "#ContosoSensor.v1_0_0.ContosoSensor".
|
|
|
Post by mraineri on Mar 5, 2024 14:08:28 GMT
Thanks for pointing this out. I'll raise this for further discussion.
|
|
|
Post by mraineri on Mar 1, 2024 21:35:43 GMT
At this time, you're correct with the current constraint; profiles only allow a comparison to be done against another property in the same resource. Comparing outside of the resource is currently not supported. However, given your use case, I can see how it would be needed. We can certainly bring this up for further discussion.
|
|
|
Post by mraineri on Mar 1, 2024 13:32:53 GMT
No, what I'm suggesting is that it's reasonable to log an event that an account is locked when it enters the locked state as a general policy; not all services will do this, and it's going to come down to product requirements.
In this case, that would occur on the 5th failed login attempt. A 6th failed login attempt wouldn't result in that type of message to be added to a log file since the account is already in the locked state.
|
|
|
Post by mraineri on Feb 28, 2024 14:20:47 GMT
For the ReadingType error, OEM is not a valid value for the property. For your usage, if it truly is an OEM sensor with units/type that we cannot standardize, I would recommend removing the ReadingType property. For your OEM schema extensions, you'll need to use a ComplexType definition; EntityType is used for resources, whereas ComplexType is for embedded JSON objects. There's an example definition you can leverage as a starting point in DSP2043 to ensure you also have other necessary hooks (like the proper base type): www.dmtf.org/sites/default/files/standards/documents/DSP2043_2023.3.zipInside, public-oem-examples/Contoso.com/ContosoServiceRoot_v1.xml, take a look at the "<ComplexType Name="ServiceRoot" BaseType="Resource.OemObject">" definition.
|
|
|
Post by mraineri on Feb 26, 2024 12:19:33 GMT
A few reasons.
In many environments, the internet is not accessible. A schema-driven client in these situations would need some other repository of schemas to decode information on the service.
Services implementing OEM extensions may not have a well-known publication URI for their service, and use the service itself as the repository.
In some cases, services will modify standard schema files per the "Schema modification rules" clause to prune out properties or other definitions not implemented by the service to describe to the client exactly what they implemented.
|
|