[Moims-sc] SM&C WG Telecon

Thu Apr 11 08:05:59 UTC 2024

Hi all,

here is a short description of the comments on the M&C BB that remain to 
be discussed in WG, together with my analysis of the issues and 
proposals of answers. We will discuss them on our next meeting (which 
changed from Tuesday April 16 to Thursday April 18?), but don't hesitate 
to comment them my mail before.

*Nullable domain in some operations*

Cesar proposes to accept a null domain in Parameter. It is notably 
useful in a deployment where a provider handles a single domain.

I suggest to accept this proposal with the following terms:

  * the consumer may provide a null domain parameter, assuming that the
    provider may infer the proper domain for each of the provided keys.
    If the provider finds an ambiguity for any of the keys that it
    cannot resolve, then an Ambiguous error shall be returned.

Cesar lists a large set of operations concerned by this optimisation. I 
believe that all the operations that define a (domain, keys) set of 
parameters are concerned.

*Wildcards*

Cesar expects some operations to accept a wildcard parameter. This is an 
issue that has been raised at The Hague, and it was decided then that no 
wildcards would be permitted. May be the issue was not properly 
understood at the time, and it could be reworked. However I would limit 
the possible rework to only a subset of the operations, as some others 
would require a big change of API.

The possible operations are:

  * Parameter enableReporting & disableReporting
  * Alert enableGeneration & disableGeneration
  * Aggregation enableReporting & disableReporting

The wildcard could be requested with a null keys parameter of the 
operations. I support this option.

The operations that would require a change in API are:

  * Parameter getReportingConfiguration
  * Alert getAlertConfiguration
  * Aggregation getReportingConfiguration

I would leave those operations unchanged. Peter commented similarly on 
this specific point.

*MO Object version in subscription keys*

Cesar questions the usefulness of the alertVersion subscription key in 
the MonitorAlert operation. He assumes that the service will always 
provide updates to the latest version, and there would be no sense for a 
consumer to subscribe to an older version.

First let me explain that declaring a subscription key serves 2 
purposes. Of course it enables the consumer to subscribe to specific 
values of that key. But it also enables the provider to pass the value 
of that key in all updates. As a general pattern in the operations of 
the M&C services, I have limited as much as possible the duplication of 
data in the body of the updates and in the subscription keys. For 
example in the MonitorAlert operation, the body only holds the timestamp 
and arguments fields of the AlertEvent structure, it does not include 
the alertRef field. This field can be known from:

  * the domain from the UpdateHeader
  * the key from the alertKey subscription key
  * the version from the alertVersion subscription key

So in a purely logical reasoning I need the version subscription key to 
be able to rebuild the AlertEvent. This is true regardless of any 
intention to subscribe to that key.

That said, the actual expected usage of this version field is unclear. 
Is it possible that 2 different versions of an AlertDefinition exist in 
a single deployment, either sequentially or concurrently? Can we 
consider that the consumer is always able to infer the proper version 
when it gets an update? Depending on the answers, we could actually 
simplify the API and remove the version subscription key. And even if we 
remove it from the API, nothing prevents a specific implementation to 
add it as an additional custom key.

Two other services have a similar operation, and I believe the issue 
should be adressed also for those operations. As the context differ, the 
answer could be different. Both operations currently define a version 
subscription key, for exactly the same reason I explained above:

  * Parameter monitorValue does declare a parameterVersion subscription key
  * Aggregation monitorValue does declare an aggregationVersion
    subscription key

I am undecided on this point, as it really depends on the actual usage 
of the version field. If this use is yet unclear, I would agree with 
removing the subscription key, especially since a specific 
implementation can add it as a custom key anyway.

*Additional subscription keys*

I suggested in a comment to add validityState as an additional 
subscription key to the Parameter monitorValue operation. Peter 
commented that he does not support this, for simplicity of the first 
version of the interface. Cesar supports it.

While processing another comment from Cesar, I found that there is 
another similar question with another operation. We have defined a 
category field in the type AggregationDefinition. I checked and realized 
that this field is never referenced in any operation of the Aggregation 
service. It could be used as a subscription key in the Aggregation 
monitorValue operation, just as the category field of the 
ActionDefinition type is used as a subscription key in the Action 
monitorActionExec operation.

We should then decide for those 3 subscription keys:

  * Action category
  * Parameter validityState
  * Aggregation category

I am undecided on this point, as again it depends on the actual usage of 
those keys as filtering options. If this use is yet unclear, I would 
suggest again to remove all subscription keys, and leave specific 
implementations with the ability to add them as custom keys to 
demonstrate their actual usefulness in actual deployments.

*Name of the Action progress event types*

The Action MonitorActionExec operation requires a number of types for 
the reported events. Cesar proposes to simplify those type names.

  * ActionProgressBaseEvent → Event
  * ActionProgressStartEvent → StartEvent
  * ActionProgressExecutionEvent → ExecutionEvent
  * ActionProgressCompletionEvent → CompletionEvent

I agree with Cesar's statement that the names are complicated and I 
would support a simplification. However the types are now defined at 
area level, and I am a bit unsatisfied with names that are too generic, 
without any reference to the Action service name. I would prefer 
ActionProgressEvent, ActionStartEvent, ActionExecutionEvent, and 
ActionCompletionEvent. I could also accept ProgressEvent, StartEvent, 
ExecutionEvent, and CompletionEvent, but not Event which is too generic.

*List operation in AggregationService*

Cesar notes that providing addAggregation and removeAggregation means 
that there is a dynamic behavior of the Aggregation service. The service 
should then also provide a List operation, so that the consumer can know 
what is the current state of the service regarding the available 
Aggregations.

The answer is not straightforward. First let me detail the history on 
this point:

  * v1: we grouped all the add/remove/list operations of all the M&C
    services into a new ConfigurationManagement service
  * v2: we decided to discard this new service with the main goal of
    simplifying the specification
  * v3: we reintroduced the Aggregation add and remove operations only,
    as those are functions of PUS that are actually used
      o note that PUS defines no related list operation

With this in mind, I can see 3 solutions to choose from:

 1. stay with no list operation, assuming that only the consumer that
    called the addAggregation operation shall be able to use it
 2. stay with no list operation, assuming that any consumer willing to
    use the aggregation dynamically created by another consumer shall be
    able to retrieve its definition by an out of band mean
 3. add the list operation

I support option 1, which is a first step of interoperability. Moreover 
it leaves option 2 open, even if sharing dynamic information out of band 
is not clear yet.

Best regards,
Serge

-- 
Serge Lacourte
Directeur general
ScalAgent Distributed Technologies SA
tel. +33 4 76 29 79 81
mobile. +33 6 86 47 41 06
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20240411/724c0398/attachment.htm>