SDPi and BICEPS Mdib versioning is inconsistent

Section Number

R1007

Priority

• High: Important issue where there is major issue to be resolved. Requires discussion and debate.

Issue

R1007 requires grouping changes to the MDIB into versioned groups segmented by the report they will generate (waveform stream, metric, component, alert report, etc). This seems inconsistent with R0046 in the 10207 Corrigendum which only requires MdibVersion to increase with pm:MdDescription/@DescriptorVersion and pm:MdState/@StateVersion, which in turn are driven by R0038 that requires pm:AbstractState/@StateVersion to increment on changes to attributes or content elements. Notably it doesn't demand grouping updates by the reports generated.

The amendment in §5.2.5.6 doesn't seem sufficient to bridge the gap: "The MDIB version represents the chronological order of event occurrences within one sequence of the MDIB".

In other words Biceps appears to allow changes to, for example, a pm:NumericMetricState and a pm:BatteryState that share the same MdibVersion but SDPi does not.

Moreover, R0065 from 20701 seems to require the MdibVersion in every msg:AbstractReport arising from a remote-control command to be the same as the MdibVersion in the final msg:OperationInvokedReport. It isn't possible to meet this requirement and R1007 from SDPi when, for example a single remote control command updates a pm:NumericMetricState and a pm:VmdState.

This could lead to interoperability problems with implementations conformant to biceps but not SDPi.

Proposed Change

Suggestion 1:

• Add a new requirement to SDPi that requires the MdibVersion in the final msg:OperationInvokedReport to be equal to the MdibVersion of the last msg:AbstractReport that is sent in relation to a remote control command.
• Determine if there is a need for a consumer to know which other reports are related to updates arising from the remote control command and, if necessary, add an extension to group updates.

Anecdotally, this appears to be the approach taken by known implementations and resolves the incomplete Mdib update problem R1007 was designed to solve but remains inconsistent with biceps standards.

Suggestion 2:
Remove R1007 from SDPi and implement another solution, such as an extension that indicates the last report in an update sequence for a single MdibVersion that spans multiple msg:AbstractReport.

This could also lead to

• interoperability problems with implementations conformant to biceps (where the extension would be missing) but not SDPi,
• breaking changes to existing implementations,
• increased consumer complexity.