PATCH on array property (validation)

PATCH request contains only one property of the array type (IPv4StaticAddresses). Thus, in the case of #2 and #3, we get a situation where the property has been updated, but partially.
I know that "Address", "Gateway", "SubnetMask" are also properties. But properties of nested JSON objects.

Could you please give an example of Redfish response in #2 and/or #3?

I'll attach here since I'm running into a very similar issue with ConfiguredSpeedGbps.

DSP0266 says:


The nuance comes in when the payload is complex.

Here, the user is attempting to modify "IPv4StaticAddresses", with a complex payload, consisting of Collection(IPAddresses.IPv4Address) - encoded in JSON as an anonymous array of IPv4Address objects.

Let's assume the user is PATCHing the payload the original poster supplied:



{ //snip

"IPv4StaticAddresses":
[
{
"Address": "10.10.10.10",
"Gateway": "10.10.10.250",
"SubnetMask": "255.255.255.0"
},
{
"Address": "10.10.1000.10",
"Gateway": "10.10.1000.250",
"SubnetMask": "255.255.255.0"
},
{
"Address": "11.11.11.11",
"Gateway": "11.11.11.250",
"SubnetMask": "255.255.255.0"
},
]

// snip }

How many properties are being PATCHED here?
A) Only one property is being updated - the entire IPv4StaticAddresses array, it's children and it's contents constitute a single property update to the "IPv4StaticAddresses" property.
B) Three properties are being updated - each instance of IPv4Address in the array is counted as an atomic property write, as the application of a complex object needs to be considered in it's entirety
C) Nine properties are being updated - repeated instances of Address, Gateway and SubnetMask are the most fundamental components of the request that hold the meaningful data
E) Combinations of above, eg. A+B or B+C or A+B+C


DSP0266 defines behavior for partial successes of multiple properties, but does not define behavior for partial success within a single property update. Understanding whether this is a single property update or multiple property update is key to identifying whether DSP0266's partial success clauses apply. 

My understanding is that when considering a single property update, it can either be:
Entirely successful - in which case for anything that's not volatile (counters, modified externally etc), the user should expect to see exactly (disregarding linting, string escapes...) what he put in the input payload upon reading it back
OR
Failed entirely with no changes being made to the property that caused the failure, but without necessarily failing the entire PATCH operation, unless all properties of the operation are failed. 

In both the case of IPv4StaticAddresses and my case, ConfiguredSpeedGbps, the most sensible option appears to be B - that complex objects are considered atomic. This would allow the device to accept some IPv4Address objects, reject others, and return success if at least one IPv4Address stuck.

Alternatively there's option A, exactly all three IPv4Address must get applied verbatim, or nothing changes. (a single invalid SubnetMask in a single IPv4Address would cause the whole thing to fail with no effect)

Option C appears the most risky - suppose I supply a bad Address and a bad SubnetMask but a good Gateway. I'd end up with an old/unchanged Address, old/unchanged SubnetMask, new Gateway, and PATCH success.

Looking forward to this forum's input.

Thanks! So with that interpretation,
1) From spec POV, only the most atomic (indivisible) elements of a payload are considered properties
2) DSP0266 clause about partial success does apply if at least one property was successfully changed, however..
3) ..A device may reject the payload, entirely or partially, or apply properties at a less granular atomicity (complex objects) rather than individual properties properties.
4) A device ought to document what it applied and what didn't using appropriate annotations