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

John Pietras john.pietras at gst.com
Tue Dec 19 10:33:35 EST 2006


Note - all comments and questions are with regard to the "Procedures
Definition for Cross Support Transfer Services - Draft" (hereinafter
referred to simply as "Procedures Definition") issued just prior to the
November CSTSWG telecon, plus the CCRs, etc. I realize that the draft
Procedures Definition document is undergoing update and so perhaps my
issues have already been resolved, but in case they have not here are
some things to consider. 

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). 

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. 

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. 

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. 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). 

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.
  
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.

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.

Best regards,
John

John Pietras
Global Science & Technology, Inc. (GST)
7855 Walker Drive
Suite 200
Greenbelt, Maryland, USA
20770-3239
Direct:   +1-240-542-1155
GST Main: +1-301-474-9696
Fax:      +1-301-474-5970




More information about the Css-csts mailing list