<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi all,</p>
<p>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.</p>
<p><b>Nullable domain in some operations</b></p>
<p>Cesar proposes to accept a null domain in Parameter. It is
notably useful in a deployment where a provider handles a single
domain.</p>
<p>I suggest to accept this proposal with the following terms:</p>
<ul>
<li>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.</li>
</ul>
<p>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.</p>
<p><b>Wildcards</b></p>
<p>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.</p>
<p>The possible operations are:</p>
<ul>
<li>Parameter enableReporting & disableReporting</li>
<li>Alert enableGeneration & disableGeneration</li>
<li>Aggregation enableReporting & disableReporting</li>
</ul>
<p>The wildcard could be requested with a null keys parameter of the
operations. I support this option.<br>
</p>
<p>The operations that would require a change in API are:</p>
<ul>
<li>Parameter getReportingConfiguration</li>
<li>Alert getAlertConfiguration</li>
<li>Aggregation getReportingConfiguration</li>
</ul>
<p>I would leave those operations unchanged. Peter commented
similarly on this specific point.<br>
</p>
<p><b>MO Object version in subscription keys</b></p>
<p>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.</p>
<p>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:</p>
<ul>
<li>the domain from the UpdateHeader</li>
<li>the key from the alertKey subscription key<br>
</li>
<li>the version from the alertVersion subscription key<br>
</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>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:<br>
</p>
<ul>
<li>Parameter monitorValue does declare a parameterVersion
subscription key</li>
<li>Aggregation monitorValue does declare an aggregationVersion
subscription key</li>
</ul>
<p>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.<br>
</p>
<p><b>Additional subscription keys</b></p>
<p>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.</p>
<p>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.</p>
<p>We should then decide for those 3 subscription keys:</p>
<ul>
<li>Action category</li>
<li>Parameter validityState</li>
<li>Aggregation category</li>
</ul>
<p>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.<br>
</p>
<p><b>Name of the Action progress event types</b></p>
<p>The Action MonitorActionExec operation requires a number of types
for the reported events. Cesar proposes to simplify those type
names.</p>
<ul>
<li>ActionProgressBaseEvent → Event</li>
<li>ActionProgressStartEvent → StartEvent</li>
<li>ActionProgressExecutionEvent → ExecutionEvent</li>
<li>ActionProgressCompletionEvent → CompletionEvent</li>
</ul>
<p>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. <br>
</p>
<p><b>List operation in AggregationService</b></p>
<p>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.</p>
<p>The answer is not straightforward. First let me detail the
history on this point:</p>
<ul>
<li>v1: we grouped all the add/remove/list operations of all the
M&C services into a new ConfigurationManagement service</li>
<li>v2: we decided to discard this new service with the main goal
of simplifying the specification</li>
<li>v3: we reintroduced the Aggregation add and remove operations
only, as those are functions of PUS that are actually used</li>
<ul>
<li>note that PUS defines no related list operation</li>
</ul>
</ul>
<p>With this in mind, I can see 3 solutions to choose from:</p>
<ol>
<li>stay with no list operation, assuming that only the consumer
that called the addAggregation operation shall be able to use it</li>
<li>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</li>
<li>add the list operation</li>
</ol>
<p>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.</p>
<p><br>
</p>
<p>Best regards,<br>
Serge</p>
<p></p>
<pre class="moz-signature" cols="72">--
Serge Lacourte
Directeur general
ScalAgent Distributed Technologies SA
tel. +33 4 76 29 79 81
mobile. +33 6 86 47 41 06</pre>
</body>
</html>