[Css-dts] SLE Monitoring Service JPL Procedure Note - Y.Doat Comments

[Yves.Doat at esa.int]

Dear Charles,

Thank you for your monitoring procedure.
I looked at it and I have a few comments.

Main comments:
   A new operation is proposed "MONITOR DATA REQUEST". The new operation you
   propose can only serve a Monitoring service purpose and cannot be generic.
   In my opinion we should extract the parameters that are generic and map it
   to one of the existing operation, i.e. THROW-EVENT.
   Note: I support the comment provided by CNES on 03.08.2005

   The operation supporting the Send Monitor Data is missing. The "Status
   Report" procedure seems to cover the need of the Monitoring message.
   Note: I support the comment provided by CNES on 03.08.2005

   Performance Data is a monitoring parameter on the QoS of its own. I don’t
   see what brings this information. In my opinion it is the role of the
   Service Management to monitor the QoS. In any case this is specific
   parameter to the proposed monitoring service and should not appear in the
   Toolkit.

   Section 1.3: In case of exception the service provider should abort the
   connection. All the proposed procedures follow the CCSDS SLE API approach.
   In case of syntax errors or semantic errors, the initiator shows a big
   behaviour problem.
   Recovery of such malfunctions might be very difficult: how to
   re-synchronise? How to deal with the next incoming messages that may have
   been issued prior to the treatment of the sent exception?

   Control procedure: The UML diagram seems very similar to the THROW-EVENT
   UML diagram. Would you have time to look at the THROW-EVENT procedure and
   identify what are the differences? Would you see a possibility to merge
   the two approaches? Will you have time to prepare the corresponding
   procedure?

Best regards

Yves
OPS-GIB
ESA/ESOC
Robert-Bosch str.5
D-64293 Darmstadt
Tel.: (+49)-6151-902288