[Css-csts] Procedure and operation version numbers - continued

Yves.Doat at esa.int Yves.Doat at esa.int
Mon Apr 28 06:49:44 EDT 2008


Dear John,

In order to properly implement a procedure and associated operations , the
implementer will need to know how its extension are built, coming from the
root (definition in the Recommendation). We have to give a mechanism to
rebuilt the path.
In the case you mention the CR START is derived from the common operations,
while the CR is built from the Unbuffered data delivery.
In both cases we have to identify where does the extension come from. This
information is missing in the Heppenheim MoM and the tables defining the
number should be completed with the "father" information.
I agree with you that we will end-up with many version numbers and we may
rapidly have a chaos if not properly managed from the beginning.

You are proposing to limit the version numbering to the procedure only. In
that case we have to assume that all operations of a given procedures are
coming from the father procedure.
In the case you address (Cyclic Report), the START operation would extend the
START operation of the Unbuffered Data Delivery. Considering that the
Unbuffered Data Delivery does not extend the START operation, the implementer
would have to get the START from above the Unbuffered Data Delivery, i.e. the
START in the common operations.
My first conclusion is that this assumption would work but should be
confirmed by others in the WG.
In any case the procedure shall identify the father procedure and its
version.

We can discuss the matter on Wednesday.

Best regards

Yves DOAT
__________________________________________________
Head of the Stations and M&C Integration Section (OPS-GSI)
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/
__________________________________________________



                                                                             
             "John Pietras"                                                  
             <john.pietras at gst.                                              
             com>                                                         To 
             Sent by:                   <css-csts at mailman.ccsds.org>         
             css-csts-bounces at m                                           cc 
             ailman.ccsds.org                                                
                                                                     Subject 
                                        [Css-csts] Procedure and operation   
             07/04/2008 17:49           version numbers - continued          
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             
                                                                             




Members of the CSTSWG ---
Last week I sent an email (below) requesting confirmation of the intent
(documented in the Heppenheim MoM) to include version numbers for both
procedures and operations, including derived procedures and operations.

In thinking a bit more about this, I find myself confused as to how this
would work an whether it's useful, in particular for derived operations.
For example, the Cyclic Report (CR) procedure extends the Unbuffered
Data Delivery procedure, and also extends the baseline START operation.
According to the Heppenheim MoM, the CR START should get it's own
operation version number. Does this mean that the CR START can be used
to extend a procedure or in the creation of a new service-specific
procedure? If so, then perhaps the "CR START" should be pulled into the
Operations Section (4) of the CSTS Framework specification, and in that
case perhaps the "new" START should be given its own name and operation
type (much the same as we do for derived procedures) and not treat it as
a different version of the START.

If it's not the intent to be able to independently use a derived
operation, then each derived "version" of an operation is tied to the
procedure for which that operation is derived, and it doesn't seem
necessary to have a separate version number - it's simply (for example)
the START operation, as derived for the CR procedure. In fact, since
every operation invocation carries the procedure type identifier as part
of the procedure-instance-identifier parameter, it essentially serves as
the operation version identifier.

Please let me know if I am missing some additional meaning for or
usefulness of having each derived operation have its own version number.

Thank you.

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

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Thursday, April 03, 2008 5:07 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Procedure and operation version numbers

Members of the CSTSWG --
In Heppenheim, it was agreed that all procedures would have version
numbers assigned to them. References to this decision in the MoM from
Heppenheim are as follows:

- 3 Concepts, Section 4.4: "The procedures should as well have a version
number."

- 4 Guidelines: " A Service shall identify its profile so that with its
version number, one knows the versions of the used procedures and used
operations. Derived/refined procedures and extended operations shall
have their own version number."

- 5 Procedures: "Every procedure (including extended procedures) and
every operations (including extended operations) shall have a version
number."

- 6 Recommendation: " All procedures shall have a version number
documented in table 6-1. A specific statement is required for the
Association procedure. All operations shall have a version number
documented in table 4-1."

At least with respect to the Minutes of Meetings and telecons, this is
the lat time that versioning of CSTS procedures and operations was
mentioned. As of the v0.12 Procedures Definition, the only versions
number for any operation is the one for the BIND operation, and that
definition ties it to the version of the Recommendation in which it
appears ("The version-number parameter shall identify the version number
of the service specification that is to govern this association if the
BIND succeeds"), not an operation-specific version number. There is no
mention of procedure version numbers in the v0.12 Procedures Definition.


Can I assume that it is still the intent to add the operation and
procedure version numbers in a future (draft) version of the Procedures
Definition/Framework? Also, would it make sense to change the definition
of the instance-number parameter of the BIND operation to decouple it
from the version of the Procedures Definition/Framework and make it it's
own version, especially since the BIND operation is very unlikely to
change as the Procedures definitions evolve? (Perhaps this is what the
sentence "A specific statement is required for the Association
procedure." in the Heppenheim MoM item on procedures definition was
alluding to).

Best regards,
John




_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts





More information about the Css-csts mailing list