[Css-csts] prime and secondary instances of the same procedure

[John Pietras]

Members of the CSTSWG ---
I am in the process of updating the Monitored Data CSTS White Book. You
may recall that the version that we reviewed in Heppenheim had two
different procedures derived from the Cyclic Report Procedure: the Prime
Monitor Cyclic Report Procedure and the Secondary Monitor Cyclic Report
Procedure [note - the names have been updated to reflect the name change
at Heppenheim from "Cyclic Data Delivery" to "Cyclic Report"].

The sole purpose for defining two derived procedures was the prohibition
against having prime and secondary procedures of the same type. I seem
to recall a discussion of this issue in Heppenheim, but my notes don't
contain any information about the issue and I can't find anything about
it in the official MoM written by Yves. I would like to summarize what I
thought was the discussion, and I hope that some of you can confirm that
we discussed it and add any details (especially regarding resolution)
that you might recall.

Here is how I recall the discussion going:
I explained that the only reason for the two versions of the Cyclic
Report procedure was that we needed one instance to be the prime
procedure but that there needed to be the possibility of multiple
secondary procedures, and the Toolkit restriction that there could be
only one instance of a procedure if it is prime forced me to create two
different derived procedures. Someone else in the CSTSWG then said that
perhaps the prohibition was unreasonable and should be dropped. I then
noted that if we reserve the procedure instance number "1" to be used
only by prime procedures, then it would be possible to distinguish the
single prime instance of a procedure from any other secondary instance
of that same procedure, without having to create different procedures.

As I said, I don't have the notes to support these recollections, and in
particular I don't remember if we came to any decisions. 

For the purposes of the next version of the Monitored Data CSTS White
Book, I am assuming that the approach outlined above is to be taken. 

As agreed in Heppenheim, I will use Yves' Service Profile table as the
basis for the table in section 3 (Monitored Data Cross Support Transfer
Service Composition). In the Profile Example that Yves presented in
Heppenheim (Annex A of the Heppenheim MoM), section A.2 includes an
example Service Profile table that is the basis for the table that will
appear in the XXX CSTS Composition sections of the various service
specifications. In this Service Profile table, for each procedure that
is used in the service, there are rows to designate: (a) the version of
the procedure used in the service; (b) whether the procedure is prime or
secondary; and (c) the number of instances that can appear. 

In Yves' example tables in sections A.3 and A.4, he shows a "Derived
Procedure 1" and "Private Procedure 1" (respectively) designated as
prime ("P") with "Nb of service instances" = 2. I don't remember how
this was intended to be interpreted, but clearly there can't be two
prime procedure instances. However, one interpretation that can be taken
that would be consistent with the notion of allowing both prime and
secondary instances of the same procedure would be as follows:
1 - If the "Prime/Secondary" row reads "P" (prime), then the "Nb of
instances" has to contain at least "1". If it has a number greater than
1, then it is assumed that the other instances are optional secondary
instance.
2 - If the "Prime/Secondary" row reads "S" (secondary), then the "Nb of
instances" has to contain at least "1", but whatever number has is
assumed to be the maximum number of optional secondary instances.

For the next draft of the Monitored Data CSTS White Book, I will
populate the Monitored Data Cross Support Transfer Service Composition
table according to the above interpretation unless directed otherwise.

Best regards,
John