[Css-csts] Blocking/non-blocking operations in derived procedures

[John Pietras]

CSTSWG colleagues ---
A question as occurred to me that may have been discussed in the WG at some point, but I don't recall it,.

The question is whether it is possible to change the blocking/non-blocking (B/NB) behavior of an operation in a derived procedure. The CSTS SFW states that it is the procedure that defines the B/NB behavior for each of its operations, and this is done for the procedures defined in the SFW itself.

If a service specification creates a service-original procedure or derives a procedure by adding one or more new operations, then it seems clear that the specification of that procedure must specify the B/NB behavior of the new operations (all of them in the case of a service-original procedure, the added ones in the case of the derived procedure). But can the service specification redefine the B/NB behavior of an operation that is inherited from the parent of the derived procedure?

Currently, the Guidelines and the TD-CSTS specification include a "Procedure Blocking/Non-Blocking" column in the table that identifies the operations of derived and service-original procedures (the MD-CSTS book contains no such table, since it uses the SFW procedures without derivation). The operations of the TD-CSTS Buffered Tracking Data Message Delivery procedure have the same B/NB behavior as the parent Buffered Data Message procedure, but could we change the B/NB behavior or one or more of the operations if we wanted to?

I have not been able to find this question addressed in the CSTS SFW or the Guidelines.

If we do allow the B/NB behavior to change, should such a change be somehow highlighted in the operations table - e.g., with an asterisk (*) by the designation to show that it is different from the parent operation?

If we do not allow the B/NB behavior of inherited operations to change, one might be tempted to eliminate the "Procedure Blocking/Non-Blocking" column altogether, but that would not support the addition of operations to a derived procedure or the creation of a service-original procedure. So we probably need to keep the column in the table, even if it has redundant information (in that it merely repeats the B/NB status of the existing inherited operations from the CSTS SFW).

Thanks for your thought on this.

Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20130312/dbd68b90/attachment.html