[Css-csts] Some questions about and comments on procedure-instance-identifier

[Yves.Doat at esa.int]

Dear John,

Thank you very much for your clarifications that are not yet covered in the
draft recommendation.
Please find below some (personnal) answers to your various items.

The Standard Operation Header (SOH) contains a
procedure-instance-identifier (Tables 4-1 and 4-2, 4.2.2.5). From CCR
17, it seems clear that the procedure instance ID is to be established
in the START invocation for each procedure and repeated in each
invocation issued under that procedure (regardless of operation type).
> I confirm that the procedure instance ID is to be established in the
> START invocation. While the pocedure name is known in advance
> (standardised name listed in the service definition), it remains to be
> agreed whether the instance ID is to be defined in advance or dynamically
> allocated.

For procedures with a START operation, this implies an error condition
if a non-START invocation is issued with a procedure-instance-identifier
not equal to any for which (a) a procedure has been already started, and
(b) the operation is valid for an-already-started procedure. What is the
proper response if such an error condition should occur:
1. Reject the invocation and keep processing? If so, then there should
be a diagnostic defined (e.g., 'unknown Procedure ID'). Should the
diagnostic be defined as part of the base set in 4.2.2.7, or as
extension for each parameter only in each procedure that includes a
START?
2. PEER-ABORT? If so, then this has to be added to the service provider
state machine definition.
> I prefer to consider a protocol violation considerring that the request
> is diverging from the service definition. This approach is simple and clear
> to specify and implement.

For procedures without a START operation (such as THROW-EVENT), what is
the significance of the procedure instance ID? Is it even possible for a
service to incorporate two or more non-START-activated procedures (e.g.,
can we conceive of a service that has one THROW-EVENT procedure and one
COP-DIRECTIVE procedure)? If these details have not already been worked
out, let me propose an approach that I think maintains maximum
flexibility for future combinations of procedures in services. I assume
that each service specification defines the number of instances of each
procedure type that are executed as part of the service.
> From the agreed approach a procedure could use any of the common
operations.
> A procedure without START could use any of the operation.
> Several instances of procedures without START could be used by a service.
In that
> case each procedure instance shall have its own procedure service instance
ID.
> For the above reasons I consider that the procedure service instance ID is
> required.

Question: are the instance identifier values (both the type and
individual ID) to be defined as part of the service specification? If
so, it makes the rules a bit simpler to state. On the other hand, if the
individual ID values is left to the implementation to set, then the
rules are more complicated to express (although they still can be
expressed). For simplicity, the following rules assume that the allowed
identifier value for each procedure instance is specified in the service
specification.
> A procedure service instance ID is made of a procedure type and an instance
ID.
> The procedure type will be standardised. The service by stating what
procedure
> is needed will have to use the standardised types.
> The instance ID could be either dynamic or defined in the service.

A. If, for a defined service, a given (non-START) operation type appears
*only* in START-activated procedures, then any invocation of that
operation type is valid only if:
   1. The invoked operation is allowed under the procedure type
identified in the invocation's procedure-instance-identifier
   2. The procedure instance referenced by the invocation's
procedure-instance-identifier is active (that is, it has already been
STARTed and has not been STOPed).
> Agreed.

B. If, for a defined service, a given (non-START) operation type appears
*only* in non-START-activated procedures, then any invocation of that
operation type is valid if the invoked operation is allowed under the
procedure type identified in the invocation's procedure-instance-identifier.
> Agreed.

C. If, for a defined service, a given (non-START) operation type may
appear in both START-activated and non-START-activated procedures, then
an invocation of that operation type is valid:
  1. If the procedure-instance-identifier in the invocation identifies a
START-activated procedure:
     a. The invoked operation is allowed under the procedure type
identified in the invocation's procedure-instance-identifier, and
     b. The procedure instance referenced by the invocation's
procedure-instance-identifier is already active.

OR

  2. If the procedure-instance-identifier in the invocation identifies a
non-START-activated procedure, the invoked operation is allowed under
the procedure type identified in the invocation's
procedure-instance-identifier.
> Agreed.

In the drafts of the DIRECTIVE operation and THROW-EVENT procedure that
I am working on, I am assuming that the service PEER-ABORTS. Please let
me know if that is an incorrect assumption.
> I understand that the service PEER-ABORTS if the initiator of the operation
> uses an undefined procedure instance ID.
> Agreed.

> I also propose to have names identifying the START-STOP and
> non-START procedures. The START-STOP procedures have a 'ready'
> and 'active' states. The non-START procedure only have one state.
> I propose to name the START-STOP procedures statefull
> (or multiple-states) procedures and the non-START procedures
> stateless procedures (or mono-state) procedures.

> Considering that the behaviour your define is generic, we shall describe it
in
> a generic part of the recommendation. Looking at the structure of the
document,
> I wonder if we shoudl not add a section listing the requirements for the
services.
> We could also envisage a dedicated recommendation addressing the rules
> for the services covering:
> 1. Procedure rules:
>    - Mandatory Association procedure,
>    -
>    - Multiple procedure instances,
>    - Service states,
>    - ...
> 2. Handling of procedure instance id;
> 3. Extension rules
> 4...

Best regards

Yves
__________________________________________________
Head Ground Infrastructure Baseband Section (OPS-GIB)
ESA/ESOC Robert-Bosch Strasse 5
D-64293 Darmstadt, Germany
Tel.: +49 (6151) 90.2288               Fax:+49 (6151) 90.3046
Internet: http://www.esa.int/
__________________________________________________